如何在一週內上線50個用戶增加策略

在閒魚用戶增加業務上的實驗

咱們最早落地的業務是在用戶增加上，閒魚的用戶增加業務有以下描述：

• 閒魚的賣家都是普通小賣家，而非專業的B類商家。所以沒法統一組織起來參加營銷活動帶來買家活躍。
• 咱們目前DAU已經突破到2000W，如何承接好這麼大致量的用戶，對運營同窗是個很大的考驗。

在年初時，咱們在用戶增加下作了多個實驗，其中兩個實驗以下：

之因此會作以上實驗，主要仍是但願用戶能在APP上多停留一會。當用戶瀏覽時間越長，就越有可能發現閒魚上還有不少有趣的內容，不管是商品寶貝仍是魚塘內的帖子。從而達到吸引用戶下一次還能再回來的目的，最終帶來用戶增加。咱們作的實驗上線後大部分都取得了不錯的業務效果，可是在過程當中也暴露了兩個問題：

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

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

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

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

以上述用戶增加的第二個實驗爲例，以下圖所示的DSL便可簡單表達出來：

規則引擎的侷限性

該規則引擎能夠很好地解決以前用戶增加業務下的幾個策略，隨後咱們進行了內部推廣，準備在閒魚C2C安全業務下也落地。在C2C安全業務上有以下描述：

在C2C安全業務上，也有一個看似是一個針對一系列行爲做出的規則抽象，以下圖所示：

可是將上述規則套上規則引擎後，就會發現沒法將安全的規則套上規則引擎。假設咱們的詳細規則是1分鐘內被拉黑2次，就對該用戶打上高危標記。那麼咱們想想，當來了第一個拉黑事件後，匹配上了。而後緊接着來了第二個拉黑事件，也匹配上了。此時按照規則引擎的視角，條件已經知足了，能夠進行下一步操做了。可是再仔細看一看規則，咱們的規則是要被不一樣的用戶拉黑，由於有多是同一個用戶操做了屢次拉黑（同時多開設備）。而規則引擎上只知道匹配到了2次拉黑事件，對規則引擎來講已經知足了。卻沒法知道是不是不一樣人操做的。起根本緣由是由於在規則引擎裏，事件都是無狀態的，沒法回溯去作聚合計算。

新的解決方案

針對規則引擎的侷限性，從新分析和梳理了咱們的實際業務場景。並結合了業界知名的通用的解決方案後，設計出了新的方案，定義了新的DSL。能夠看到，咱們的語法是類SQL的，主要有如下幾個考慮：

• SQL已是語義完備的編程語言，不用再去作額外的語法設計。
• SQL是一門很簡單的語言，不須要花太多時間就能夠掌握。
• 咱們閒魚的運營同窗會寫SQL，這樣會讓上線效率更快。

新的DSL方案與以前的規則引擎相比主要有如下幾個加強：

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

針對以前的C2C業務上的規則描述問題，使用新方案的例子以下：

總體分層架構

基於這套用EPL（Event Programming Language）寫出的DSL，爲了作好工程化，咱們作了以下的總體分層架構。爲了快速實現最小閉環驗證效果，咱們選擇先基於Blink（Blink是阿里對Flink的內部優化和升級）作雲上的解析和計算引擎。

在這個分層架構裏，至上而下分別是：

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

事件採集

經過切面的方式攔截全部的網絡請求和行爲打點，再記錄到服務端日誌流裏。同時經過一個事實任務對事件流進行清洗，按前面定義的格式清洗出咱們想要的事件。再將清洗後的日誌輸出到另外一個日誌流裏，供EPL引擎來讀取。

EPL實現

因爲咱們採起了類SQL語法，而Calcite是業界通用的解析SQL的工具，所以咱們採用Calcite並經過自定義其中的parser來解析。若是是單一事件的DSL，則會解析成Flink SQL。若是是多事件的DSL，則會解析後經過直接調用Blink的API接口的方式來實現。

用戶觸達

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

案例

新方案上線後，咱們就在愈來愈多的業務場景裏進行了落地。這裏列舉2個例子：

在上述魚塘的例子裏，能夠看出來，咱們這套方案已經有了一點算法推薦的影子了。在上述租房的例子裏，因爲規則過於複雜，用DSL表達起來很麻煩，因此就作成只採集4次瀏覽不一樣租房寶貝的規則，即觸發後，就將這裏的數據都給到租房的具體開發的業務方，這也是咱們在落地過程當中摸到的邊界。

結論

使用這一套完整方案，研發效率上有了很大的提高。原先經過寫代碼case by case的方式通常要4個工做日完成整個研發流程，極端狀況下須要跟客戶端版本則須要2-3周的時間。如今經過寫SQL的方式通常要0.5個工做日便可上線。此外，這套方案還有以下幾個優點：

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

經過在多個業務的落地實踐，咱們也摸索出來這套方案的適用邊界：

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

將來規劃

當前整套方案還有以下幾個問題：

• 整條鏈路計算完畢平均須要5秒左右。若是放到對實時性要求更高的遊戲任務場景下時，這就沒法知足了。假設，今天有個任務是瀏覽10個寶貝詳情。當用戶瀏覽到第10個寶貝時，還要再等5秒纔給予響應，用戶是沒法接受的。所以須要對總體性能有進一步提高，要在毫秒級內給出響應。
• 閒魚的業務已經連年保持了高增加，將來可能會面對比當下翻三番的用戶流量，若是全部計算依然所有放在雲上，則對雲上的算力消耗是個極大的挑戰。
• 目前咱們的設計上，是沒有算法接入的，只有簡單的圈人。而爲了讓規則的投放更加精準，進而提高規則對用戶的有效性，是須要與算法結合的。

所以綜上，咱們將來的規劃將會聚焦於端側實時計算能力的挖掘和算法能力的結合上。

---

本文做者：閒魚技術-蘭昊

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。