如何在一周內(nèi)上線50個用戶增長策略

導(dǎo)讀：年初的一個晨會上，用戶增長負(fù)責(zé)人湘翁問我說：一個周內(nèi)上線50個增長策略，技術(shù)兄弟們能做到么？

在用戶增長業(yè)務(wù)上的實(shí)驗(yàn)

閑魚的用戶增長業(yè)務(wù)具有如下現(xiàn)狀：

• 閑魚的賣家都是普通小賣家，而非專業(yè)的B類商家。因此無法統(tǒng)一組織起來參加營銷活動帶來買家活躍。這一點(diǎn)是與淘寶／天貓的差別。
• 我們目前DAU已經(jīng)突破到2000W，如何承接好這么大體量的用戶，對運(yùn)營同學(xué)是個很大的考驗(yàn)。

為了能更好地做好用戶增長，在今年年初時，我們在用戶增長下做了多個實(shí)驗(yàn)，希望提高用戶停留時長。用戶瀏覽時間越長，就越有可能發(fā)現(xiàn)閑魚上還有很多有趣的內(nèi)容，無論是商品寶貝還是魚塘內(nèi)的帖子。

從而達(dá)到吸引用戶下一次還能再回來的目的，最終帶來用戶增長。其中兩個實(shí)驗(yàn)如下：

我們做的實(shí)驗(yàn)上線后大部分都取得了不錯的業(yè)務(wù)效果，但是在過程中也暴露了兩個問題：

• 研發(fā)周期長。一開始，我們先用最快的實(shí)現(xiàn)方案來做，主要是為了快速驗(yàn)證規(guī)則策略的有效性，并沒有做大而全的設(shè)計(jì)，每個需求都是case by case地寫代碼來實(shí)現(xiàn)。那么從開始開發(fā)真正能到上線，很可能就是三周，主要因?yàn)榭蛻舳税l(fā)版是有窗口的。
• 運(yùn)營效率慢。因?yàn)樯暇€慢，導(dǎo)致獲取業(yè)務(wù)數(shù)據(jù)后再分析效果就很晚了，然后還要根據(jù)數(shù)據(jù)再去做調(diào)整那就更晚了。這樣算下來，一年也上不了幾個規(guī)則策略。

工程化解法——基于事件流的規(guī)則引擎

針對上述問題，我們先做了一層業(yè)務(wù)抽象。運(yùn)營先通過對用戶的各種行為進(jìn)行一個分析和歸類，得出一個共同的具體的規(guī)則，再將這個規(guī)則實(shí)時地作用到用戶身上進(jìn)行干預(yù)。

針對這層業(yè)務(wù)抽象，我們再做了工程化，目的就是為了提升研發(fā)效率和運(yùn)營效率。這樣就有了第一個方案——基于事件流的規(guī)則引擎，我們認(rèn)為用戶的行為是一串順序的行為事件流，使用一段簡單的事件描述DSL，再結(jié)合輸入和輸出的定義，就可以完整地定義一個規(guī)則。

以上述用戶增長的第二個實(shí)驗(yàn)為例，如下圖所示的DSL即可簡單表達(dá)出來：

規(guī)則引擎的局限性

該規(guī)則引擎可以很好地解決之前用戶增長業(yè)務(wù)下的幾個策略，隨后我們進(jìn)行了內(nèi)部推廣，準(zhǔn)備在閑魚C2C安全業(yè)務(wù)下也落地。在C2C安全業(yè)務(wù)上有如下描述：

在C2C安全業(yè)務(wù)上，也有一個看似是一個針對一系列行為作出的規(guī)則抽象，如下圖所示：

但是將上述規(guī)則套上規(guī)則引擎后，就會發(fā)現(xiàn)無法將安全的規(guī)則套上規(guī)則引擎。假設(shè)我們的詳細(xì)規(guī)則是1分鐘內(nèi)被拉黑2次，就對該用戶打上高危標(biāo)記。

那么我們想一想，當(dāng)來了第一個拉黑事件后，匹配上了。然后緊接著來了第二個拉黑事件，也匹配上了。此時按照規(guī)則引擎的視角，條件已經(jīng)滿足了，可以進(jìn)行下一步操作了。

但是再仔細(xì)看一看規(guī)則，我們的規(guī)則是要被不同的用戶拉黑，因?yàn)橛锌赡苁峭粋€用戶操作了多次拉黑（同時多開設(shè)備）。而規(guī)則引擎上只知道匹配到了2次拉黑事件，對規(guī)則引擎來說已經(jīng)滿足了。卻無法知道是否是不同人操作的。

其根本原因是因?yàn)樵谝?guī)則引擎里，事件都是無狀態(tài)的，無法回溯去做聚合計(jì)算。

新的解決方案針對規(guī)則引擎的局限性，重新分析和梳理了我們的實(shí)際業(yè)務(wù)場景。并結(jié)合了業(yè)界知名的通用的解決方案后，設(shè)計(jì)出了新的方案，定義了新的DSL?？梢钥吹剑覀兊恼Z法是類SQL的，主要有以下幾個考慮：

• SQL已經(jīng)是語義完備的編程語言，不用再去做額外的語法設(shè)計(jì)。
• SQL是一門很簡單的語言，不需要花太多時間就可以掌握。
• 我們閑魚的運(yùn)營同學(xué)會寫SQL，這樣會讓上線效率更快。

新的DSL方案與之前的規(guī)則引擎相比主要有以下幾個增強(qiáng)：

• 增加了條件表達(dá)式。可以支持更豐富更復(fù)雜的事件描述，也就能支撐更多的業(yè)務(wù)場景。
• 增加了時間表達(dá)式。通過WITHIN關(guān)鍵字，定義了一個時間窗口。通過HAVING之后跟的DISTINCT等關(guān)鍵字，就可以針對時間窗口內(nèi)的事件進(jìn)行聚合計(jì)算。使用新的方案，就可以很好地解決上述C2C業(yè)務(wù)上的規(guī)則描述問題。
• 擴(kuò)展性強(qiáng)。遵循了業(yè)界標(biāo)準(zhǔn)，與具體業(yè)務(wù)的輸入和輸出無關(guān)，便于推廣。

針對之前的C2C業(yè)務(wù)上的規(guī)則描述問題，使用新方案的例子如下：

整體分層架構(gòu)

基于這套用EPL（Event Programming Language）寫出的DSL，為了做好工程化，我們做了如下的整體分層架構(gòu)。為了快速實(shí)現(xiàn)最小閉環(huán)驗(yàn)證效果，我們選擇先基于Blink（Blink是阿里對Flink的內(nèi)部優(yōu)化和升級）做云上的解析和計(jì)算引擎。在這個分層架構(gòu)里，至上而下分別是：

• 業(yè)務(wù)應(yīng)用。在這里是我們整個系統(tǒng)的業(yè)務(wù)方，已經(jīng)在多個業(yè)務(wù)場景下做了落地。
• 任務(wù)投放。這里是對業(yè)務(wù)應(yīng)用層提供DSL聲明和投放的能力，能可以做簡單的圈人，以及與用戶觸達(dá)模塊的關(guān)聯(lián)。
• 用戶觸達(dá)。這個模塊用于接收來EPL引擎計(jì)算的結(jié)果，根據(jù)關(guān)聯(lián)的Action來實(shí)施動作。同時這個模塊也可以獨(dú)立對業(yè)務(wù)應(yīng)用提供服務(wù)，即各個業(yè)務(wù)方可以擁有自己的邏輯，通過用戶觸達(dá)模塊來觸達(dá)用戶。
• EPL引擎。目前已經(jīng)實(shí)現(xiàn)了云上的解析和結(jié)算。用于接收來自任務(wù)投放里聲明的DSL，再去解析和運(yùn)行在Blink上。
• 事件采集。負(fù)責(zé)通過服務(wù)端日志和行為打點(diǎn)里采集行為事件，并歸一化地輸出給EPL引擎。

事件采集通過切面的方式攔截所有的網(wǎng)絡(luò)請求和行為打點(diǎn)，再記錄到服務(wù)端日志流里。同時通過一個事實(shí)任務(wù)對事件流進(jìn)行清洗，按前面定義的格式清洗出我們想要的事件。再將清洗后的日志輸出到另一個日志流里，供EPL引擎來讀取。

EPL實(shí)現(xiàn)

由于我們采取了類SQL語法，而Calcite是業(yè)界通用的解析SQL的工具，因此我們采用Calcite并通過自定義其中的parser來解析。如果是單一事件的DSL，則會解析成Flink SQL。如果是多事件的DSL，則會解析后通過直接調(diào)用Blink的API接口的方式來實(shí)現(xiàn)。

用戶觸達(dá)

當(dāng)EPL引擎計(jì)算出結(jié)果之后，會輸出給用戶觸達(dá)模塊。首先會進(jìn)行一個Action路由，最終決策出需要由具體哪一個Action來響應(yīng)，最后通過與客戶端之間的長連接將Action下發(fā)到端上。端上收到具體的Action后，會先判斷當(dāng)前用戶的行為是否允許展示該Action。如果可以的話，就直接執(zhí)行Action的具體內(nèi)容，曝光給用戶。用戶看到這次響應(yīng)后會有相應(yīng)的行為，那么這部分的行為會影響到Action路由，對這次的路由的做出一個反饋。

應(yīng)用落地新方案上線后，我們就在越來越多的業(yè)務(wù)場景里進(jìn)行了落地。這里列舉2個例子：

在上述魚塘的例子里，可以看出來，我們這套方案已經(jīng)有了一點(diǎn)算法推薦的影子了。在上述租房的例子里，由于規(guī)則過于復(fù)雜，用DSL表達(dá)起來很麻煩，所以就做成只采集4次瀏覽不同租房寶貝的規(guī)則，即觸發(fā)后，就將這里的數(shù)據(jù)都給到租房的具體開發(fā)的業(yè)務(wù)方，這也是我們在落地過程中摸到的邊界。

結(jié)論使用這一套完整方案，研發(fā)效率上有了很大的提升。原先通過寫代碼case by case的方式一般要4個工作日完成整個研發(fā)流程，極端情況下需要跟客戶端版本則需要2-3周的時間。現(xiàn)在通過寫SQL的方式一般要0.5個工作日即可上線。此外，這套方案還有如下幾個優(yōu)勢：

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

通過在多個業(yè)務(wù)的落地實(shí)踐，我們也摸索出來這套方案的適用邊界：

• 對實(shí)時性要求高
• 強(qiáng)運(yùn)營主導(dǎo)規(guī)則
• 能夠用SQL表達(dá)

未來規(guī)劃當(dāng)前整套方案還有如下幾個方向可以進(jìn)一步探索：

• 整條鏈路計(jì)算完畢平均需要5秒左右。如果放到對實(shí)時性要求更高的游戲任務(wù)場景下時，這就無法滿足了。
• 閑魚的業(yè)務(wù)已經(jīng)連年保持了高增長，未來可能會面對比當(dāng)下翻三番的用戶流量，如果所有計(jì)算依然全部放在云上，則對云上的算力消耗是個極大的挑戰(zhàn)。
• 目前我們的設(shè)計(jì)上，是沒有算法接入的，只有簡單的圈人。而為了讓規(guī)則的投放更加精準(zhǔn)，進(jìn)而提升規(guī)則對用戶的有效性，是需要與算法結(jié)合的。

綜上，我們未來的規(guī)劃將會聚焦于端側(cè)實(shí)時計(jì)算能力的挖掘和算法能力的結(jié)合上。

文：蘭昊 @閑魚技術(shù)

特別提示：關(guān)注本專欄，別錯過行業(yè)干貨！

首席增長官CGO薦讀增長黑客：

• 《?小紅書筆記排名，KOL種草，評論點(diǎn)贊收藏?》
• 《用戶增長、獲客的4條干貨》
• 《從《硅谷增長黑客實(shí)戰(zhàn)筆記》看社群運(yùn)營》

更多精彩，關(guān)注：增長黑客（GrowthHK.cn）

增長黑客（Growth Hacker）是依靠技術(shù)和數(shù)據(jù)來達(dá)成各種營銷目標(biāo)的新型團(tuán)隊(duì)角色。從單線思維者時常忽略的角度和高度，梳理整合產(chǎn)品發(fā)展的因素，實(shí)現(xiàn)低成本甚至零成本帶來的有效增長