大促背后的流量利器|手淘push升级 比你更懂你
導讀:過去的很長一段時間內,由于電商的強運營特性,手淘 App 的 Push 消息大部分時候是作為一個活動通知的通道,對重要活動進行通投引流。然而在競爭環境更加激烈和用戶滲透日趨飽和的今天,具備更加精細化的用戶運營手段和智能內容投放能力被逐漸重視起來,也成為了整個系統和產品后續優化升級的重點。
從今年開始,我們開始對手淘 Push 的平臺鏈路、技術架構和投放算法進行了大幅度的升級改造,目標是使其能夠在日常和大促中承擔起個性化營銷、用戶促活和業務導流等多種角色。
那么,經過升級改造后的整體效果如何?在這次的 618 大促中又發揮了什么樣的作用?我們在背后有那些發現和思考?本文會逐一介紹。
介紹
手淘 App 作為目前用戶數最多的幾個 App 之一,Push 天生就是一個用戶觸達量非常巨大的渠道,每天將觸達幾億的人群,是整個手機淘寶非常重要流量渠道之一。
但是實際上,我們希望 Push 消息不僅僅是一個觸達渠道和通知方式,而是能夠通過結合豐富的觸達內容、深度的用戶理解和個性化的運營分發,將其打造成一個具備用戶心智和真正懂用戶的產品,變成用戶在淘寶上的一個貼身小助手。
手淘的 Push 消息可以分為營銷類(細分為個性化、定投和通投),產品通知類,聊天 IM 類。可以從下面的產品介紹圖中找到部分相應的示例。
背景
在流量結構上,歷史上手淘 Push 投放流量經歷過從通投到定投的轉變,開始進入了精細化用戶運營的模式。算法開始介入對人群的選擇,簡單說完成了一個從人找內容到內容找人的過程。
隨著今年的升級改造,我們重點打造了更加強大的個性化在線計算引擎來進行內容投放,經過了大量的 AB 實驗和大促的檢驗之后,目前的主要流量已經從定投切換到了個性化投放,完成了從時機、內容、頻率上都完全個性化的改進。
可以從下面的圖里直觀的理解這三種投放方式的區別。其實投放模式的改進除了帶來效率的提升之外,也帶來了用戶體驗的巨大提升,除了可以減少大量沒有必要的消息推送之外,推送的內容也會和用戶更加相關。
整體架構
消息推送最基本的能力是進行內容投放。對于一般的 App 而已, Push 更多的可以理解為實現一個內容推薦和分發系統,通過優化點擊率來提高 App 的活躍度和內容的瀏覽量。但是對于手淘而已,還需要承擔一個對不同業務方進行內容投放的需求,需要做到流量的合理分配,兼顧平臺,業務方和用戶的訴求,所以手淘 Push 同時也兼具了廣告投放系統的很多特點。
如下圖,整體算法架構分為投放匹配 和 流量調控分別建設,同時我們還構造了第三個模塊智能情景投放來決定整個投放的具體時機。
流量投放匹配:本質上解決的是用戶和內容的匹配問題,我們將會從內容素材庫中選擇和用戶最相關的內容和商品,假設 f(U,X) 是對用戶 U 在投放內容 X 上的打開率預估得分,那么這個模塊將會選擇打開率預估最高的素材進行后續投放。
從系統視角上看,整個流程也分為了經典的召回+排序的部分,但是具體來說和傳統的推薦分發系統有兩個主要不同點:
1.具體的投放任務往往有一些限制和要求,比如投放量,投放目標人群和投放頻率等,所以如果我們僅僅將最優的內容分配給最活躍的用戶,就會發現在這些約束條件下這樣做通常都不是全局最優解。于是通過加入流量調控決策來對這些約束進行考慮,最終可以從全局角度進行整體優化。
2.在不同的時刻,用戶的注意力以及對內容的需要程度是不一樣的。通過對時間進行合理的預估,并觸發投放可以有效的提高內容利用效率,并且有效降低系統的負載。于是智能情景投放被引入來針對每個用戶預估他們的最優投放時間。
流量調控決策:這個模塊將會收集用戶和內容本身的Push發送情況,來滿足一些疲勞度和業務方流量保證等一系列的約束,同時也將這些約束也同樣建模到算法模型中進行優化。
整體來看, M 表示素材, U 表示用戶, MU 表示該素材對該用戶的投放情況, X 表示具體的投放內容 Item 。
最終希望投放內容的優化問題和約束條件為:
函數 h 考慮預估打開率 f(U,X) 、 U 的已發送量、 MU 的已發送量的擬合關系,函數 g 考慮 M 的已發送量的業務流量分配優化,最終通過有監督優化學習這兩個函數的最優解,使得整體的流量分配在業務流量,用戶投放疲勞度,內容多樣性和全局打開率上達到一個最優的狀態。
智能情景投放:在消息推送中除了要解決推送什么內容之外,還有一個很重要的問題是解決推送時機的問題,也就是在什么時間進行推送用戶最有可能打開,并且受到的打擾最小。傳統的通投或定投只能選擇統一的發送時間,沒有充分考慮用戶的使用情景。
在投放系統的上游,我們加入了智能情景模塊在投放時為每個用戶決定個性化的推送時間。在投放之前,智能情景模塊會去預估每個用戶最佳的的Push觸達時機,然后在這個最佳時機上去觸發內容的選擇和投放系統。
具體實現上,對于某個用戶而言,投放時間的優化問題可以抽象為不同時段Push消息的打開率預估,然后選擇最優解的優化過程。但是實際中我們不能完全暴力的求解和遍歷所有時機,并且還需要考慮不能將流量完全集中在一個時刻引發系統問題。于是最終采取的做法是結合用戶當日使用情況、疲勞情況等實時特征,會先選擇一些候選時機集合T,然后再訓練預估模型f來選擇其中的最佳時間點來作為該用戶今天的投放時間。
相比于固定投放時機或者隨機投放時間,基于智能情景投放時機的打開率效果分別可以提升10%和20%左右,有效的提高了消息的利用率。在合適的時機推送內容也做到了對用戶打擾的降低,以及降低了整體的系統負載壓力。
整體階段成果:經過為期3個月的開發和打磨,最終整個系統在618之前成功上線,在日常的投放中帶來以下幾點提升:
- 效率顯著提升:通過整體系統的改造,我們對手淘 DAU 的貢獻占比從 3 月初到現在短短幾個月時間提升了 100% ,實現了翻倍,給整個手淘的用戶活躍帶來了較大的增量。
- 實時鏈路改造:通過對離線投放的改造,所有的計算都遷移到了在線引擎,實現實時內容匹配和投放,這帶來了算法效果上超過15%的提升以及實時運營的能力支持。而對實時運營的支持,是 Push 整體能在大促發揮作用的重要基礎能力,我們將在下一節重點介紹大促中的工作。
- 消息打擾優化:通過算法來預測每條消息對于用戶的價值,我們就可以盡可能的去過濾一些對用戶價值較低的消息,在不影響整體打開效果的情況下,盡可能的降低對用戶的打擾。這個工作目前已經有了初步的成果,目前可能在打開效果盡量不降低的情況下,減少 40% 的消息發送量。
大促賦能
每年的天貓 618 大促既是一個年中重要的營銷節日,也是對年末天貓雙十一的一個預演和檢驗。對于今年的 618 大促,我們成立了專門的大促專項進行了重點支持。除了上述日常的改造提升之外,針對大促的特點和對 Push 投放的需求,也進行了相關的能力改造和升級。
大促流量保證 :對于大促的賦能關鍵點是需要具備 2 個核心能力:實時投放 + 動態目標。
業務上需要根據大促的實時情況來決定投放目標,比如大促 GMV 和流量的供給需求等。這種情況下離線算法是很難支持這種臨時的投放任務的,而經過了前期的一系列實時化改造和對大促臨時需求的調研,最終在 618 之前上線了大促機動策略功能,可以針對大促當天的臨時或者機動需求,進行創建任務、選擇投放目標和內容、開始投放的一系列實時能力。
例如,618 當天,為了進一步釋放大促潛在購買轉化,在大促期間加購未購人群上實時創建了投放任務,進行了目標人群上的個性化投放。對比的投放方式是人工選擇內容,隨機選擇內容和算法個性化選擇內容。具體的實驗方案如下圖:
下圖里給出了大促三天算法帶來的投放效率提升效果。三個任務里算法投放的打開率相比大促常規的人工通投方式都有非常明顯的提升,證明了算法在提效和實時干預上能夠較大幅度的幫助大促完成相應的業務目標。在大促的流量爭奪戰中,希望通過更加有針對性和高效的方式進行觸達,幫助用戶找到更有效的信息,同時也降低無效信息對用戶的干擾。
大促營銷內容 :眾所周知,大促對于電商用戶來說,更像一個促銷節日,所以營銷的重點一定是不一樣的。我們希望這種變化可以更加實時的捕捉和通過用戶行為動態的進行學習。
這次大促經過全行業的投放,通過數據分析,從天貓大促會場和日常投放素材的對比可以發現,大促中的用戶對高價格商品的接受度會比較高,而日常投放中的用戶需求則集中在低價格商品,而這些用戶需求的變化也可以通過實時的算法學習來捕捉,從而在投放上進行調整和變化,進一步的對大促的流量效率進行提升。
總結&展望
綜上,用一句話概括手淘 Push 的整體目標就是:在合適的時機,為用戶提供需要的內容,并且建立穩定的用戶預期和反饋機制,來形成有效的產品閉環。
未來將繼續沿著三個重要方向進行升級和優化。
1.用戶打擾和通道健康:
應用內外的 Push 功能是一個很容易被濫用,并且健康度受損之后很難事后修復的渠道。目前手淘的 Push 應用通知關閉率低于大部分內容類應用,但在發送消息的時候仍然要對通道的健康度進行關注和優化,減少消息的發送量。
2.事件觸發機制支持和端測能力結合:
除了進行營銷類的通知外,從用戶體驗上,需要將用戶真正關心的事件和用戶希望得到的通知提供給他們,成為用戶真正的貼身助手。所以后續將會結合事件觸發和端實時計算的能力還進行能力補全。
3.算法深度的探索和應用:
如之前介紹,手淘的 Push 算法融合了推薦和廣告中的算法能力,未來將進一步對更加深入的算法方向進行探索,希望能夠對用戶的狀態和推送正負反饋進行更加精準的建模,讓推送內容變得更加準確和“有用”。
原文鏈接
本文為云棲社區原創內容,未經允許不得轉載。
總結
以上是生活随笔為你收集整理的大促背后的流量利器|手淘push升级 比你更懂你的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 历时五天用 SwiftUI 做了一款 A
- 下一篇: Istio从懵圈到熟练 – 二分之一活的