引言

閑魚是一個C2C平臺，提高賣家活躍度不僅有利于成交的提升，對于用戶增長也有積極意義。而其中的關鍵點就在于其成交的效率。而個人賣家由于其專業程度不如專業賣家，成交效率往往并不高。我們希望可以實現兩個提升：
能幫助賣家提高其成交效率。

可以快速的接入新的場景。

通過對線上數據進行分析，我們發現一些有趣的現象，比如：使用真人頭像的賣家，會有更多的用戶訪問其主頁或商品(潛在的流量來源)；回復積極的賣家更易成交；距離越近/信息越豐富的商品也更易售出。

賣家行為閉環

賣家活躍度最大的核心點在于是否能成交，所以我們以成交為抓手來提高賣家的在線活躍度。根據前面的觀察，賣家行為可以影響其成交，這些影響有的顯而易見，有的則沒那么明顯，基于這個我們做了一些嘗試。

基于賣家行為的嘗試

賣家的目的一定是成交，所以我們以成交轉化為目的，基于線上的算法模型做了一輪模擬，模擬基于兩個關鍵指標

• 在線狀態。當前用戶在線狀態以及距離上一次在線時長。
• 詢單回復統計。用戶在過去半小時的詢單回復情況。

算法模型在這里不做涉及，因為有更專業的算法同學來完成，在這里我們只解決工程側的問題。首先我們定義了用戶在閑魚上的行為4要素：1）when。2）where。3）what。4）who。when和where定義賣家的時間和空間緯度，what刻畫了行為本身，who則是對于行為主體人的表達。

另一方面賣家行為描述起來很簡單，但是要正確識別卻并不簡單。比如一個完整的賣家回復行為需要做如下拆解

買家基于商品和賣家創建對話。

買家基于對話給賣家發送消息。

賣家基于對話回復買家消息。

上面三個行為必須滿足約束：1）時間有序。2）行為2可以重復發生。3）行為1，2，3之間可能存在干擾(自動回復，安全提醒等)。基于此我們選擇用CEP來做復雜事件模型匹配，選型上對比輕量/靈活性/使用成本上綜合對比了Siddhi以及flink cep，最終選擇Siddhi來作為前期的cep計算引擎。

以上是算法基于兩個指標的模擬結果，數據因為安全原因進行了脫敏。縱軸越大表示成交越多。橫軸表示基于用戶在線狀態&回復行為的多維特征。從模擬結果上可以看到在線狀態&回復積極的賣家更容易促成成交，這從一個方面說明賣家的行為確實會潛在的影響其成交效率。

構造完整閉環

前面的分析結果說明我們的收益是正向的，但是這遠遠不夠。首先面臨的就是賣家如何知道哪些行為可以有助成交？賣家如何去感知這些行為帶來的正向收益？

前面說到我們的核心抓手是促成交，所以核心思想是構造上面這樣一個完整的閉環來培養穩定的賣家心智，幫助其快速成交。

我們最核心的路徑是賣家引導->賣家行為->產生收益->感知收益。圍繞著這個核心路徑，分別設計了活動，任務，數據采集三大模塊。

• 活動關聯若干任務，對賣家進行引導。
• 任務用于規范賣家行為。
• 數據用于賣家行為識別。

在整個實現過程中我們遵循兩個原則

• 模塊間互相解耦。實現過程中依賴了很多外部系統，明確彼此的邊界，做到最小耦合。
• 模塊內單一職責。整個系統的核心是數據流。越簡單越穩定，3我們希望降低維護成本，減少風險。

我們希望可以達到兩個目的：1）能幫助賣家提高其成交效率。2）可以快速的接入新的場景。總體實現架構如下

活動

活動引導賣家去進行對應的操作，并給出相應的利益點，負責

• 活動元數據管理。
• 對上層提供查詢服務。
• 從底層數據同步通道同步活動信息。
• 容災計算。雖然同步通道會將任務同步至活動，但是當底層通道出現異常時需要有機制保證可以同步從任務粒度實時計算出活動數據，容災計算啟動時系統整體性能降低。

任務

任務用來定義我們鼓勵的賣家行為，解決以下問題

• 元數據管理。包括任務定義及其任務完成之后的回調。

  • 任務定義。定義任務基本要素。
  • 回調。任務完成之后執行，任務執行結果同步在這里完成。
• 任務初始化。數據均產自若干三方系統，主要來源于三部分：1）算法模型產出。2）數據分析。3）買家反饋。
• 三方系統。用一套標準的交互協議實現解耦。

• 數據一致性。任務模塊涉及到多方的讀寫，需要保證數據的最終一致性。

  • 任務初始化/更新/任務查詢分別組合成單向數據流，數據流彼此之間使用條件更新來保證數據的一致性。效果類似于樂觀鎖，但是整個系統不會因為并發寫問題而導致性能瓶頸。

數據同步通道

同步通道根據活動元數據將任務粒度的數據同步至活動粒度，支持全量/增量兩種同步模式。

• 增量：實時同步任務數據。任務初始化/賣家完成任務。

• 全量：全量一般在新增活動/活動規則變更時觸發。需要解決

  • 分布式任務分發。分布式完成全量任務。
  • 操作冪等。操作可以重復，但不影響最終結果。
  • 全量增量彼此隔離，不影響在線服務。

數據層

數據層需要收斂賣家的行為數據。業務復雜度的差異導致其數據來源多樣化：1）標準化的數據來源于閑魚自研的Omega體系。2）差異化的數據來源多樣化，包括日志采集/MQ消息/持久化存儲設施。

前面提到閑魚賣家行為的4要素，數據收斂之后首先要做的就是將這些數據歸一化，映射成標準行為數據。由于數據量級和復雜度的差異，最終我們根據行為數據復雜度的不同，采用不同的方式完成識別

• 實時流計算。簡單事件(聚合/關聯等統計數據)匹配使用實時流計算來完成。資源消耗低，但缺乏靈活性，一些復雜事件雖然也能完成，但是代碼復雜度高，不利于維護。
• CEP引擎。復雜事件采用CEP引擎做跨事件的模式匹配。功能靈活，可讀性強，但是資源消耗高。
• 持久化。帶狀態的數據需要持久化，用于接下來的匹配計算。

其他

除去前面提到的三大模塊之外，我們還補充了

• 收益感知。為了加強賣家利益點的感知，在外圍添加了收益感知模塊，從三方在線系統回流數據作為活動效果的展示，刺激賣家行為，我們認為這有助于賣家心智的培養與增強。
• 人群圈選。用于活動信息觸達賣家。
• 服務層。規范和端上的協議，提供渲染模版，活動查詢，action配置等功能。

匹配計算。

效果

當前已經落地了關聯同款，基于賣家行為(在線狀態指標&回復數據統計)的流量分配模型,真人頭像等場景。
基于賣家行為的流量分配分桶測試數據顯示，成交轉化有3個百分點的提升；目前新場景接入不需要開發介入，只需要運營挖掘出了關鍵行為數據，就能快速地在系統中落地上線。
匹配計算。

未來規劃

用戶行為引導閉環歸根結底是一個不斷反饋，背后的邏輯是我們需要去更好的理解用戶，用戶是誰，怎么去刻畫用戶的行為還有很多有待深挖的點。
賣家理解離不開行為數據的支撐。我們需要更完善的用戶行為數據及特征向量作為底層的基礎設施。

有了完善的用戶行為特征庫，如何挖掘出對賣家更有價值的行為點加以引導，這些價值往往充滿了差異性，需要結合個性化。

目前的收益反饋機制還較為簡單，增加賣家對行為利益點的感知，有助于培養成熟穩定的賣家心智。

理解賣家只是第一步，電商領域無論是C2C還是C2B，都在講導購，個性化。這種個性化可以將流量的價值最大化，但是其中也充滿了不確定性，這時候確定性的賣家理解就可以更好的幫助到我們，去做流量匹配，做賣家運營。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的为了帮助卖家成交，闲鱼工程师做了些什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。