一、調研目的和說明

馬蜂窩的模式是旅游社區，即內容主要由用戶生產，同時可以互動交流，有了可觀流量之后再尋求變現。用戶量，用戶活躍度，用戶粘性是社區型產品的關鍵指標。

馬蜂窩的核心功能模塊攻略、游記、問答、點評均為上述目的服務。本文的產生出于下列原因：a. 了解旅游社區平臺的問答功能；b.日常練習產品調研；c.瀏覽馬蜂窩相關文章發現，鮮有以問答功能為主的內容。

本文從用戶-需求-場景、主要業務流程、對提問者的激勵三部分內容，對馬蜂窩問答進行產品調研。

使用馬蜂窩 iOS 8.1.6 App版本。

馬蜂窩問答界面

二、用戶、需求和場景

1. 用戶和需求

從問答角色本身，可劃分為：提問者、回答者和瀏覽者，結合旅行的特殊性，又可將提問者細分成多個維度，見下圖：

回答者維度

不同維度的旅行者都可能遇到問題，越是具體的、細節的、個性化的問題，越需要問答功能。

2. 場景舉例

筆者以一次真實使用場景為例，敘述使用馬蜂窩問答及相關功能的過程。

用戶定位
非旅游愛好者，以前很少出門，由于某種外在原因驅動，今年五一想和朋友去旅行，負責制定全部行程計劃，三月中旬開始計劃時沒有明確目的地。

使用場景

使用場景舉例

• Step 1.旅行前--確定目的地
  在線下咨詢喜歡旅行的朋友，獲得幾個候選目的地，使用馬蜂窩目的地+搜索功能瀏覽候選目的地綜合信息，權衡考慮后基本可以定出目的地。

• Step 2.旅行前--確定關鍵節點
  圍繞目的地，開始制定旅行計劃，以交通和住宿的時間為關鍵節點，搭出計劃骨架，在這個階段，主要使用攻略+搜索功能。

• Step 3.旅行前--補充內容細節
  確定骨架后，補充和完善細節內容，從這個階段開始頻繁使用問答功能，由于時間充裕，先通過搜索尋找目標問題及答案，如無法匹配，就自己提問。

• Step 4.旅行中--解決未計劃問題
  與旅行前不同，有些時候由于時間和狀態原因，旅行中不會花過多時間搜索問題，往往會直接提問。

• Step 5.旅行后--總結旅行
  能夠形成閉環的是旅行后將本地的旅行計劃整理后放到平臺上，但這點對于外在驅動的低頻旅行者來說，并不容易。

三、業務流程

問答業務流程

1. 問答數據結構化的任務放在提問流程上，填寫標題+選擇目的地均為必填項；

2. 狀態選擇：準備中/旅行中+邀請回答的功能設計是亮點，不過目前從筆者的體驗來看，選擇旅行中獲得的回復的體驗并不是太好（測試次數較少，有待繼續驗證）；

3. 問題-回答數形成規模后，可成為首頁等各個頁面的瀏覽來源之一；

四、關鍵問題：如何激勵回答者？

從上述介紹中不難看出，問答運轉的關鍵在回答的數量與質量，筆者整理發現，馬蜂窩采取了至少但不限于以下幾種產品或涉及到產品的運營方法，以激勵回答者答題。

1. 頂/收藏/評論/關注/瀏覽量展示

社交標配動作，配合消息通知，提升回答者的答題意愿，另外相關動作數據應該也是展現和排序的依據之一。

2. 邀請回答

提問流程（提問時）和問答詳情頁（提問后）都可以邀請回答，邀請對象分別為推薦答題人和好友答題人。

3. 虛擬成就和榮譽

馬蜂窩社區本身就有等級體系，但應該是出于激勵更多用戶答題的目的，問答有其專屬的認證系統。

問答認證體系

金牌回答是對高質量回答的認證，通過a.專屬標識展示；b.回答的排序依據；c.申請指路人和目的地認證時優先通過等激勵點，鼓勵社區用戶產出高質量的回答。對回答的認證可說是問答認證系統的基礎。

指路人是對人這一維度的認證，除了專屬標識展示，指路人推薦位展示等，還帶有物質激勵。

馬蜂窩數據結構的基礎是目的地，所以在對指路人的認證基礎上，還可以進行目的地認證。

金牌回答、指路人和目的地認證三者相輔相成，而整個問答認證體系和其他各種功能點其實也關聯起來了，比如邀請回答時的系統推薦。

4. 活動，如答題大賽等

問答欄目里設置活動入口，運營可不定期舉辦各種活動。

五、總結：學到什么？

問答，早在BBS和貼吧時期就已存在，即便并未以單獨的產品形態出現。

垂直領域內容/社區型產品基本上都會有問答需求，想做一個問答的MVP產品并不復雜，但需要考慮是否有相配套的挖掘和激勵回答者的產品和運營策略。

馬蜂窩有針對全社區用戶的等級體系，還有問答認證體系，還搭配有運營的動作。

以上這些如果不能跟上的話，擁有極強生命力的問答功能也可能無人問津。