Categories
程式開發

如何在一周內上線50個用戶增長策略


在用戶增長業務上的實驗

閒魚的用戶增長業務具有如下現狀:

  • 閒魚的賣家都是普通小賣家,而非專業的B類商家。因此無法統一組織起來參加營銷活動帶來買家活躍。這一點是與淘寶/天貓的差別。
  • 我們目前DAU已經突破到2000W,如何承接好這麼大體量的用戶,對運營同學是個很大的考驗。

為了能更好地做好用戶增長,在今年年初時,我們在用戶增長下做了多個實驗,希望提高用戶停留時長。用戶瀏覽時間越長,就越有可能發現閒魚上還有很多有趣的內容,無論是商品寶貝還是魚塘內的帖子。從而達到吸引用戶下一次還能再回來的目的,最終帶來用戶增長。其中兩個實驗如下:

如何在一周內上線50個用戶增長策略 1

如何在一周內上線50個用戶增長策略 2

我們做的實驗上線後大部分都取得了不錯的業務效果,但是在過程中也暴露了兩個問題:

  • 研發週期長。一開始,我們先用最快的實現方案來做,主要是為了快速驗證規則策略的有效性,並沒有做大而全的設計,每個需求都是case by case地寫代碼來實現。那麼從開始開發真正能到上線,很可能就是三週,主要因為客戶端發版是有窗口的。
  • 運營效率慢。因為上線慢,導致獲取業務數據後再分析效果就很晚了,然後還要根據數據再去做調整那就更晚了。這樣算下來,一年也上不了幾個規則策略。

工程化解法——基於事件流的規則引​​擎

針對上述問題,我們先做了一層業務抽象。運營先通過對用戶的各種行為進行一個分析和歸類,得出一個共同的具體的規則,再將這個規則實時地作用到用戶身上進行干預。

如何在一周內上線50個用戶增長策略 3

針對這層業務抽象,我們再做了工程化,目的就是為了提升研發效率和運營效率。這樣就有了第一個方案——基於事件流的規則引​​擎,我們認為用戶的行為是一串順序的行為事件流,使用一段簡單的事件描述DSL,再結合輸入和輸出的定義,就可以完整地定義一個規則。

如何在一周內上線50個用戶增長策略 4

以上述用戶增長的第二個實驗為例,如下圖所示的DSL即可簡單表達出來:

如何在一周內上線50個用戶增長策略 5

如何在一周內上線50個用戶增長策略 6

規則引擎的局限性

該規則引擎可以很好地解決之前用戶增長業務下的幾個策略,隨後我們進行了內部推廣,準備在閒魚C2C安全業務下也落地。在C2C安全業務上有如下描述:

如何在一周內上線50個用戶增長策略 7

在C2C安全業務上,也有一個看似是一個針對一系列行為作出的規則抽象,如下圖所示:

如何在一周內上線50個用戶增長策略 8

但是將上述規則套上規則引擎後,就會發現無法將安全的規則套上規則引擎。假設我們的詳細規則是1分鐘內被拉黑2次,就對該用戶打上高危標記。那麼我們想一想,當來了第一個拉黑事件後,匹配上了。然後緊接著來了第二個拉黑事件,也匹配上了。此時按照規則引擎的視角,條件已經滿足了,可以進行下一步操作了。但是再仔細看一看規則,我們的規則是要被不同的用戶拉黑,因為有可能是同一個用戶操作了多次拉黑(同時多開設備)。而規則引擎上只知道匹配到了2次拉黑事件,對規則引擎來說已經滿足了。卻無法知道是否是不同人操作的。其根本原因是因為在規則引擎裡,事件都是無狀態的,無法回溯去做聚合計算。

如何在一周內上線50個用戶增長策略 9

新的解決方案

針對規則引擎的局限性,重新分析和梳理了我們的實際業務場景。並結合了業界知名的通用的解決方案後,設計出了新的方案,定義了新的DSL。可以看到,我們的語法是類SQL的,主要有以下幾個考慮:

  • SQL已經是語義完備的編程語言,不用再去做額外的語法設計。
  • SQL是一門很簡單的語言,不需要花太多時間就可以掌握。
  • 我們閒魚的運營同學會寫SQL,這樣會讓上線效率更快。

如何在一周內上線50個用戶增長策略 10

如何在一周內上線50個用戶增長策略 11

新的DSL方案與之前的規則引擎相比主要有以下幾個增強:

  • 增加了條件表達式。可以支持更豐富更複雜的事件描述,也就能支撐更多的業務場景。
  • 增加了時間表達式。通過WITHIN關鍵字,定義了一個時間窗口。通過HAVING之後跟的DISTINCT等關鍵字,就可以針對時間窗口內的事件進行聚合計算。使用新的方案,就可以很好地解決上述C2C業務上的規則描述問題。
  • 擴展性強。遵循了業界標準,與具體業務的輸入和輸出無關,便於推廣。

針對之前的C2C業務上的規則描述問題,使用新方案的例子如下:

如何在一周內上線50個用戶增長策略 12

如何在一周內上線50個用戶增長策略 13

整體分層架構

基於這套用EPL(Event Programming Language)寫出的DSL,為了做好工程化,我們做瞭如下的整體分層架構。為了快速實現最小閉環驗證效果,我們選擇先基於Blink(Blink是阿里對Flink的內部優化和升級)做雲上的解析和計算引擎。

在這個分層架構裡,至上而下分別是:

  • 業務應用。在這裡是我們整個系統的業務方,已經在多個業務場景下做了落地。
  • 任務投放。這裡是對業務應用層提供DSL聲明和投放的能力,能可以做簡單的圈人,以及與用戶觸達模塊的關聯。
  • 用戶觸達。這個模塊用於接收來EPL引擎計算的結果,根據關聯的Action來實施動作。同時這個模塊也可以獨立對業務應用提供服務,即各個業務方可以擁有自己的邏輯,通過用戶觸達模塊來觸達用戶。
  • EPL引擎。目前已經實現了雲上的解析和結算。用於接收來自任務投放裡聲明的DSL,再去解析和運行在Blink上。
  • 事件採集。負責通過服務端日誌和行為打點裡採集行為事件,並歸一化地輸出給EPL引擎。

如何在一周內上線50個用戶增長策略 14

事件採集

通過切面的方式攔截所有的網絡請求和行為打點,再記錄到服務端日誌流裡。同時通過一個事實任務對事件流進行清洗,按前面定義的格式清洗出我們想要的事件。再將清洗後的日誌輸出到另一個日誌流裡,供EPL引擎來讀取。

如何在一周內上線50個用戶增長策略 15

EPL實現

由於我們採取了類SQL語法,而Calcite是業界通用的解析SQL的工具,因此我們採用Calcite並通過自定義其中的parser來解析。如果是單一事件的DSL,則會解析成Flink SQL。如果是多事件的DSL,則會解析後通過直接調用Blink的API接口的方式來實現。

如何在一周內上線50個用戶增長策略 16

用戶觸達

當EPL引擎計算出結果之後,會輸出給用戶觸達模塊。首先會進行一個Action路由,最終決策出需要由具體哪一個Action來響應,最後通過與客戶端之間的長連接將Action下發到端上。端上收到具體的Action後,會先判斷當前用戶的行為是否允許展示該Action。如果可以的話,就直接執行Action的具體內容,曝光給用戶。用戶看到這次響應後會有相應的行為,那麼這部分的行為會影響到Action路由,對這次的路由的做出一個反饋。

如何在一周內上線50個用戶增長策略 17

應用落地

新方案上線後,我們就在越來越多的業務場景裡進行了落地。這裡列舉2個例子:

如何在一周內上線50個用戶增長策略 18

如何在一周內上線50個用戶增長策略 19

如何在一周內上線50個用戶增長策略 20

在上述魚塘的例子裡,可以看出來,我們這套方案已經有了一點算法推薦的影子了。在上述租房的例子裡,由於規則過於復雜,用DSL表達起來很麻煩,所以就做成只採集4次瀏覽不同租房寶貝的規則,即觸發後,就將這裡的數據都給到租房的具體開發的業務方,這也是我們在落地過程中摸到的邊界。

結論

使用這一套完整方案,研發效率上有了很大的提升。原先通過寫代碼case by case的方式一般要4個工作日完成整個研發流程,極端情況下需要跟客戶端版本則需要2-3週的時間。現在通過寫SQL的方式一般要0.5個工作日即可上線。

此外,這套方案還有如下幾個優勢:

  • 高性能。整條鏈路計算完畢平均耗時5秒。
  • 高可靠。依託於Blink的高可靠性,承載了雙十一上億的流量。

通過在多個業務的落地實踐,我們也摸索出來這套方案的適用邊界:

  • 對實時性要求高
  • 強運營主導規則
  • 能夠用SQL表達

未來規劃

當前整套方案還有如下幾個方向可以進一步探索:

  • 整條鏈路計算完畢平均需要5秒左右。如果放到對實時性要求更高的遊戲任務場景下時,這就無法滿足了。
  • 閒魚的業務已經連年保持了高增長,未來可能會面對比當下翻三番的用戶流量,如果所有計算依然全部放在雲上,則對雲上的算力消耗是個極大的挑戰。
  • 目前我們的設計上,是沒有算法接入的,只有簡單的圈人。而為了讓規則的投放更加精準,進而提升規則對用戶的有效性,是需要與算法結合的。綜上,我們未來的規劃將會聚焦於端側實時計算能力的挖掘和算法能力的結合上。

本文轉載自公眾號閒魚技術(ID:XYtech_Alibaba)。

原文鏈接

https://mp.weixin.qq.com/s/DW43lpsfw-jyxcNuMMN3Vg