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

我們最先落地的業(yè)務(wù)是在用戶增長(zhǎng)上，閑魚的用戶增長(zhǎng)業(yè)務(wù)有如下描述：

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

在年初時(shí)，我們?cè)谟脩粼鲩L(zhǎng)下做了多個(gè)實(shí)驗(yàn)，其中兩個(gè)實(shí)驗(yàn)如下：

之所以會(huì)做以上實(shí)驗(yàn)，主要還是希望用戶能在APP上多停留一會(huì)。當(dāng)用戶瀏覽時(shí)間越長(zhǎng)，就越有可能發(fā)現(xiàn)閑魚上還有很多有趣的內(nèi)容，無論是商品寶貝還是魚塘內(nèi)的帖子。從而達(dá)到吸引用戶下一次還能再回來的目的，最終帶來用戶增長(zhǎng)。我們做的實(shí)驗(yàn)上線后大部分都取得了不錯(cuò)的業(yè)務(wù)效果，但是在過程中也暴露了兩個(gè)問題：

• 研發(fā)周期長(zhǎng)。一開始，我們先用最快的實(shí)現(xiàn)方案來做，主要是為了快速驗(yàn)證規(guī)則策略的有效性，并沒有做大而全的設(shè)計(jì)，每個(gè)需求都是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)整那就更晚了。這樣算下來，一年也上不了幾個(gè)規(guī)則策略。

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

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

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

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

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

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

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

但是將上述規(guī)則套上規(guī)則引擎后，就會(huì)發(fā)現(xiàn)無法將安全的規(guī)則套上規(guī)則引擎。假設(shè)我們的詳細(xì)規(guī)則是1分鐘內(nèi)被拉黑2次，就對(duì)該用戶打上高危標(biāo)記。那么我們想一想，當(dāng)來了第一個(gè)拉黑事件后，匹配上了。然后緊接著來了第二個(gè)拉黑事件，也匹配上了。此時(shí)按照規(guī)則引擎的視角，條件已經(jīng)滿足了，可以進(jìn)行下一步操作了。但是再仔細(xì)看一看規(guī)則，我們的規(guī)則是要被不同的用戶拉黑，因?yàn)橛锌赡苁峭粋€(gè)用戶操作了多次拉黑（同時(shí)多開設(shè)備）。而規(guī)則引擎上只知道匹配到了2次拉黑事件，對(duì)規(guī)則引擎來說已經(jīng)滿足了。卻無法知道是否是不同人操作的。起根本原因是因?yàn)樵谝?guī)則引擎里，事件都是無狀態(tài)的，無法回溯去做聚合計(jì)算。

新的解決方案

針對(duì)規(guī)則引擎的局限性，重新分析和梳理了我們的實(shí)際業(yè)務(wù)場(chǎng)景。并結(jié)合了業(yè)界知名的通用的解決方案后，設(shè)計(jì)出了新的方案，定義了新的DSL。可以看到，我們的語法是類SQL的，主要有以下幾個(gè)考慮：

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

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

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

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

整體分層架構(gòu)

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

在這個(gè)分層架構(gòu)里，至上而下分別是：

• 業(yè)務(wù)應(yīng)用。在這里是我們整個(gè)系統(tǒng)的業(yè)務(wù)方，已經(jīng)在多個(gè)業(yè)務(wù)場(chǎng)景下做了落地。
• 任務(wù)投放。這里是對(duì)業(yè)務(wù)應(yīng)用層提供DSL聲明和投放的能力，能可以做簡(jiǎn)單的圈人，以及與用戶觸達(dá)模塊的關(guān)聯(lián)。
• 用戶觸達(dá)。這個(gè)模塊用于接收來EPL引擎計(jì)算的結(jié)果，根據(jù)關(guān)聯(lián)的Action來實(shí)施動(dòng)作。同時(shí)這個(gè)模塊也可以獨(dú)立對(duì)業(yè)務(wù)應(yīng)用提供服務(wù)，即各個(gè)業(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ò)請(qǐng)求和行為打點(diǎn)，再記錄到服務(wù)端日志流里。同時(shí)通過一個(gè)事實(shí)任務(wù)對(duì)事件流進(jìn)行清洗，按前面定義的格式清洗出我們想要的事件。再將清洗后的日志輸出到另一個(gè)日志流里，供EPL引擎來讀取。

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

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

用戶觸達(dá)

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

案例

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

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

結(jié)論

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

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

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

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

未來規(guī)劃

當(dāng)前整套方案還有如下幾個(gè)問題：

• 整條鏈路計(jì)算完畢平均需要5秒左右。如果放到對(duì)實(shí)時(shí)性要求更高的游戲任務(wù)場(chǎng)景下時(shí)，這就無法滿足了。假設(shè)，今天有個(gè)任務(wù)是瀏覽10個(gè)寶貝詳情。當(dāng)用戶瀏覽到第10個(gè)寶貝時(shí)，還要再等5秒才給予響應(yīng)，用戶是無法接受的。因此需要對(duì)整體性能有進(jìn)一步提升，要在毫秒級(jí)內(nèi)給出響應(yīng)。
• 閑魚的業(yè)務(wù)已經(jīng)連年保持了高增長(zhǎng)，未來可能會(huì)面對(duì)比當(dāng)下翻三番的用戶流量，如果所有計(jì)算依然全部放在云上，則對(duì)云上的算力消耗是個(gè)極大的挑戰(zhàn)。
• 目前我們的設(shè)計(jì)上，是沒有算法接入的，只有簡(jiǎn)單的圈人。而為了讓規(guī)則的投放更加精準(zhǔn)，進(jìn)而提升規(guī)則對(duì)用戶的有效性，是需要與算法結(jié)合的。

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的如何在一周内上线50个用户增长策略的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。