每日最新頭條.有趣資訊

美團點評:如何用技術驅動用戶高速增長

作者丨張傑

近日,在極客邦科技舉辦的 QCon 北京 2019 上,美團點評高級技術專家張傑為大家分享了技術如何助力美團點評實現用戶增長的經驗。

1

提 綱

用戶增長的背景和目標

大眾點評全鏈路激勵系統

激勵系統重心:用戶行為和用戶任務系統

激勵系統的高可用實踐

2

用戶增長的背景和目標

Nike 創始人 Phil Knight 曾經說過:“If you are not growing , then you are dying”(不再增長,就在死亡),企業增長是一個永恆的話題。在互聯網紅利消退的今天,單純依靠製造一款產品,然後反覆行銷來驅動的商業模式已經失去市場,而以數據指引方向,實驗驅動運營的“增長黑客式”模式顯示出其強勁的實力;

企業的用戶增長策略在不同時期會聚焦在 AARRR 模型的不同階段,發力用戶留存 (Rentention) 對於大眾點評尤為重要。建立用戶成長激勵體系是提升留存的重要抓手。

所謂用戶成長激勵體系,就是平台通過激勵的方式讓用戶在產品使用過程中的不同階段達到不同的狀態。行前的時候引導用戶去看點評、看攻略,形成決策;行中的時候去排隊點菜買單;行後的時候去寫點評幫助更多人。

建立這個成長體系很有意義:首先它影響了用戶獲取成本和平台的收入,這裡的收入不僅僅指現金的收入,對於大眾點評而言,用戶貢獻的點評、攻略等內容也是寶貴的收入。用戶成長激勵體系將用戶由大眾點評的輕度使用者漸漸引導為深度使用者和內容貢獻者,逐漸攤平初期公司在拉新時的成本,從而提升平台收入。其次用戶成長激勵體系鼓勵用戶做分享和傳播,公司組建了非常優秀的本地化運營團隊在重點城市運營 VIP 用戶,這些 VIP 用戶在本地的傳播和擴散作用非常明顯,帶動了更多人來使用大眾點評,貢獻優質內容。

技術上如何助力用戶增長、搭建成長激勵體系呢?我們打造了一套全面覆蓋大眾點評 APP 用戶場景的技術系統。

3

全鏈路激勵系統

全鏈路激勵系統的搭建,需要滿足成長激勵理論中的三個訴求:建模型、搭通道、促成長:

建模型指系統要搭建數據模型指導決策,比如平台要搭建用戶生命周期模型、用戶漏鬥模型、用戶價值模型等等;

搭通道指系統要搭建用戶成長和用戶觸達的通道,比如關鍵頁面的紅點和彈窗;

促成長指系統要能承載多種維度的運營策略,推動用戶向其高生命周期階段演進。

全鏈路激勵系統一站式解決了四個視角的痛點:第一個是用戶視角,用戶可以順暢的在點評 APP 內領取任務,取得激勵;第二個是開發視角,開發不需要自己管理任務的生命周期,只需要實現系統的幾個擴展點就可以進行任務綁定、任務推薦、任務讀取進度和任務狀態更新;第三個是運營視角,運營在系統後台可以做可視化運營,動態圈選目標用戶,實時查看用戶完成的任務量和任務進度;最後一個是平台管理員視角,系統採用多租戶模式管理租戶,為不同的租戶設置子系統權限。

系統採用廣義分層的架構實現,在業務服務域主要提供全鏈路激勵的解決方案,這一層以任務引擎為核心,結合算法模型組織業務。整個解決方案會調用多種領域服務,如觸達服務、投放服務等,每個領域服務開放自己的一套高內聚的服務接口;從數據流轉的角度看系統,數據在業務服務域和領域服務域中流轉,通過離線、實時、近實時等方式反饋算法模型、生成數據報表。

這套全鏈路激勵系統涉及多個核心子系統:用戶行為系統、投放系統、任務系統和獎勵系統。我們這裡重點介紹下用戶行為系統和任務系統。

用戶行為系統

用戶行為的定義

4W1H 定義用戶行為:是誰(WHO)、在哪裡裡(WHERE)、是什麽(WHAT)、什麽時間(WHEN)、行為的屬性(HOW)。我們的用戶行為系統,不僅包括用戶標準行為(用戶在產品上的操作記錄),還包括了用戶的非標準行為,比如“用戶在首頁停留 5 秒”、“瀏覽了某個特定的業務元素”等極具業務定製的行為或者任何標準或者非標準行為的自由組合。

用戶行為接入

分三步走,第一步是流量上報,集團通過統一打點框架,將通用行為按策略打點上報,對於實時性要求高的行為或者定製化的業務行為,我們採用做輕行為日誌上報的方式,單獨為其開放 MAPI 接口進行上報;第二步將流入的行為數據在 storm 集群中做一層粗分揀,並將分揀好之後的數據會按照業務維度分發給消息集群。用戶全量的行為數量巨大,處理和存儲全量用戶行為顯然性價比較低,於是我們在流量網關中隻攔截系統關注的核心行為。與此同時系統還對標準的用戶行為做了擴展,比如集團打點上報了一個瀏覽商戶行為,而全鏈路激勵系統需要“VIP 用戶瀏覽美食商戶行為”、“用戶瀏覽五星商戶行為”。為了實現如上需求,系統通過在流量網關中設置監聽器,動態插入規則表達式的方式實現;行為數據緊接著按照策略分發到不同 Topic 的消息集群中,比如將數量最大的瀏覽行為單獨分配 Topic,重要的寫點評行為單獨分配 Topic。第三步數據流入 UAS-Core 做精細處理和數據持久化。

業務行為擴展

分揀好之後的用戶行為數據會在 UAS-Core 裡做進一步業務處理。比如針對用戶緯度會做噪音過濾、業務轉換、數據統計和冪等控制。以噪音過濾為例,噪音過濾算法識別出來很多爬蟲流量,它會被當做噪音過濾掉,就不佔用存儲資源了;之後系統把用戶產生的行為從存儲裡撈出來,按照時間線排序,再壓縮放進去。最後再經過一層業務擴展層,業務把邏輯作為插件拆入到 Server container 中實現。

行為數據存儲

系統採用離線和實時融合的方式進行數據存儲。比如業務需要提供一位用戶 30 天內的瀏覽行為數據,實時數據存 5 天,離線數據以 28 天的時間窗口不停滾動,通過大數據作業的方式存在 Hive 裡面。接口調用時做實時融合,給業務方使用。

整體設計

用戶任務引擎

用戶行為搭建完成之後,就給整個全鏈路激勵的核心系統:任務系統打造了良好的基礎。用戶任務引擎不僅僅指用戶顯式領取的任務處理,還包括如用戶等級升級之類的隱式任務的生命周期管理。

IFTTT 式的任務模式

下圖左側是一個極簡模型:數據分析結果顯示我們的某些目標用戶缺少標簽數據,需要用完善個人資料的方法填補這個空白,於是系統會推送“完善個人資料任務”任務給用戶。當用戶在個人資料頁填寫完幾個關鍵信息之後,系統判定任務完成,並且發放給用戶 30 積分。整個任務的流轉過程本質使用的是 IFTTT 思想。IFTTT 是”if this then that“的簡稱,本意是想把互聯網上的所有應用鏈接起來,我們的全鏈路激勵系統裡借鑒了這個思想,希望把用戶行為鏈接起來,比如說"if 用戶寫了一條點評",”then 該用戶貢獻值增加,並且得到一張一百元的代金券“。

豐富的子任務管理

系統不僅能組織簡單模型,更擅長於處理複雜的子任務模型。任務是由子任務組成的,從任務邏輯視角來看,任務是樹型結構,父節點的任務含義要包括子節點的任務含義,當子結點任務完成時父節點的任務也要被標記完成;從運營視角來看,每個任務是各自的組裡的,分組採用專家規則方式由運營手動乾預,不同的分組會影響如推薦、投放等模塊。最後從子任務關係的視角來說,一個任務可以由多個子任務組成,如圖所示,用戶在並聯的完成”寫一條點評“、”上傳視頻“、”簽到“任意一個任務之後,再按照順序串聯的完成”瀏覽 3 條點評頭條“,”瀏覽好友動態,”拉 10 位好友到 517 吃貨節活動“之後,才算完成整個任務;用戶完成一個複雜的任務成本是比較高的,於是任務引擎支持分步發獎,通過讀取運營人員配置的”step“信息,在完成幾個子任務後用戶即可收到小獎勵,最終完成整個任務時收到通關大獎。在工程實踐上面我們重寫了一個 Google 的表達式引擎去做實現子任務管理。

多用戶維度融合

靈活的任務模型和子任務管理解決了任務維度的複雜性,而用戶維度的複雜性仍然是一大難題。用戶按照使用大眾點評的終端分為 PC 端用戶、小程序端用和 APP 端用戶;用戶按照登錄態分為登錄用戶和非登錄用戶;用戶如果持有多個設備,我們還要區分是不是老用戶換機或者其他場景。用戶在 PC 端開始了一個任務,在 APP 上完成了剩下的任務怎麽算?激勵該發放給誰?用戶在登錄狀態下和非登錄狀態下的任務如何統計?這些都需要全鏈路激勵系統在用戶維度上做不小的工作。我們通過”多用戶緯度融合策略“解決這些問題。例如一位用戶在未登錄狀態下領取了任務,並且做了一部分子任務,之後該用戶登錄了。這時候系統會識別出該用戶為目標用戶,觸發以設備緯度向用戶緯度融合的策略:用戶登錄的時刻,產生融合點,平台首先用算法猜一下這個是不是它的主設備?發現是主設備的時候會做畫像融合,將用戶畫像和設備畫像融合;用戶在登陸情況下做了一些行為,平台會把他設備上做的行為和用戶緯度做的行為都撈出來按照時序重排,並且把這些行為做事件重放,重新刷新任務的狀態機;如果這個時候用戶的任務要完成了,那就再次猜一下這個設備是不是主設備,判定是不是要發一張大額的獎勵;如果是主設備並且符合風控要求,發放大額獎勵,如果發現不是主設備會給他發一個兜底獎勵,並且會對這張獎勵做染色,方便風控團隊在將來他使用這張券的時候會做風控處理。

智能仲裁解決任務衝突

最後,在解決了複雜任務模型和複雜用戶維度之後,全鏈路激勵系統又面臨一個由於任務數量激增遇到的現實問題。大家都知道普魯托原則,又叫 20/80 原則。大眾點評 80% 的任務引導是承接在 20% 關鍵頁面上的,這時就會出現很多衝突的場景。那系統是如何解決用戶任務當中的任務衝突呢?我們引入了智能仲裁解決方案。我們首先了解一下仲裁場景,也就是在什麽情況下需要仲裁:

同一頁面場景同一模塊的不同業務仲裁。比如對於商戶頁的寫點評模塊,點評平台想引導這個用戶寫點評要發放”寶箱“,垂直業務想要引導用戶寫帶圖點評,發放 200 積分,這時候就產生衝突了。

同一頁面場景多用戶行為仲裁。商戶頁一次性出十幾個引導,既要引導用戶收藏、又要引導用戶去預訂,很多彈窗和氣泡彈出,這種用戶體驗是絕對不允許的,也是仲裁的場景。

多頁面場景同一用戶行為仲裁。比如我們可以在首頁加號處引導用戶寫點評,在商戶頁也有寫點評的引導,同一個用戶行為引導了多次並發放多個獎勵,顯然性價比不高。

其次我們了解一下仲裁點,也就是仲裁的時機:對於同一時刻發生的用戶標準我們才進行仲裁操作。最後在技術上是如何實現仲裁的:

基於專家規則:對於業務的配額或者臨時要舉辦的活動,採用專家規則的方式進行配置,在特定時間段內生效,常見的方式如配置優先級、互斥分組等。

基於算法:對於非規則類的行為,實時用算法乾預是技術實現的正確方向。算法的選用要符合當前的業務目標,比如我們的目標是要任務點擊的 UVCTR 最高,還是以行為產生的用戶價值量最大為目標。

4

激勵系統的高可用實踐

最後,全鏈路激勵系統覆蓋了大眾點評的大量用戶場景,可用性要求很高。我們在系統搭建的過程中做了很多的工作。

系統高可用方面:主要依賴公司提供的中間件和熔斷降級措施,集群 QPS 過高之後的彈性擴容;RPC 中間件的智能負載均衡;降級組件的熔斷策略、多機房切換等。

業務高可用方面:我們做的最重要的抽象就是任務分級:如寫點評等寫操作我們認為很重要,並且用戶重做的成本非常高,就把其設定為高級別的任務;如瀏覽信息等用戶重做成本低的任務,就把其設定為低級別的任務;平台識別出來任務分級之後,在故障感知時會實時監控它的發放量、歷史同期的完成量、以及業務庫存。在故障處理時對低級別的任務先降級甚至丟棄,對高級別的故障做額外的回補和處理。

5

寫在最後的話

用戶成長其實和增長一樣是一個比較大的概念。我們不僅在線上有完善的全鏈路激勵系統,在線下我們也做了很多事情:本地化運營團隊在線下運營社群活動,每年舉辦 VIP 年終盛典,大家一起評選達人,歡度節日;公司和會員共同發起公益計劃,幫助邊遠山區的孩子生活的更好。用戶在成長的同時我們也在一同成長。

最後引用一句大家耳熟能詳的名言:“唯有愛和美食不可辜負”,祝大家”Eat Better,Live Better“。

點個在看少個 bug

獲得更多的PTT最新消息
按讚加入粉絲團