有贊多平臺推廣接入與測試

作者:鳳騰

部門:業務技術 / 社交電商

一、基本概念

CPS(Cost Per Sale) 是網絡廣告中效果營銷體系中的主要形式之一,是一種以實際銷售額來計算廣告費用的廣告,它可以理解爲銷售額提成,這種廣告更多的適合購物類、導購類、網址導航類的網站,需要精準的流量才能帶來轉化。或者可以理解成商品推廣解決方案 (Commodity Promotion Solution):作爲一種電商推廣手段,其本質就是如何幫助商家有效的帶貨,商家可以是廠商、分銷商、個人賣家。而帶貨的形式可以是在朋友圈發商品信息、維護社羣關係、通過直播帶貨、在社交平臺(小紅書、微博等)發佈筆記、分銷等。

二、整體業務模式

有贊 CPS 分爲兩種模式:自營模式和 CPS 模式,每個第三方渠道可以選擇接入其中一種或者接入全部模式。

2.1 自營模式

首先,用戶在第三方渠道登錄並完成賬號綁定。其次,每一個渠道申請對應的有贊雲應用 (例如, 快手賣貨助手等),商家完成店鋪授權應用之後存儲授權狀態。最後,運營整理每個渠道禁售商品、類目等規則進行配置使得滿足規則的商品可上架到渠道售賣。買家在三方渠道訪問推廣鏈接跳轉到商詳頁,完成後續交易流程。如何授權應用?可以查看 渠道應用授權瞭解詳情。

2.2 CPS 模式

CPS 模式提供了兩個管理後臺:分傭推廣平臺 和有贊客平臺, 分別管理商家域和推廣者域。店鋪入駐分傭推廣後管理員可以進入到分傭推廣後臺通過創建推廣計劃或者團長活動來控制商品佣金率。推廣者登錄有贊客後臺可以創建推廣渠道和推廣位用來標識一次推廣並且查看推廣之後產生的效果訂單數據。三方渠道 app 會嵌入 CPS 選品組件頁面,展示在該頁面列表中的商品都必須通過對應渠道審覈規則 (包含機審以及人審),有贊客纔可以選品並將商品上架到對應渠道上售賣。具體商品審覈結果可以在多平臺賣貨助手上查看。

2.3 兩者區別

通過下面這張圖來比較二者區別: 

  1. 自營模式的接入需要外部渠道申請有贊雲應用,完成店鋪和渠道應用的綁定關係,作爲自營訂單歸因的判斷條件之一。CPS 模式需要商家去入駐分傭推廣作爲 CPS 訂單歸因判斷條件之一。

  2. 自營模式商品池其實就是當前店鋪所有商品滿足風控基礎審覈。CPS 模式對應的商品池更大,所有入駐過分傭推廣的店鋪對應商品都流入該池子,禁售規則也更多。

  3. 兩種模式都會生成推廣鏈接以及寫入點擊記錄,訂單歸因的時候 CPS 模式是按照點擊歸因。自營模式主要按照下單環境 fanstype 進行歸因。

  4. 自營模式渠道佣金按照類目設定佣金率或者渠道通用的佣金率來計算。CPS 模式佣金分爲店鋪佣金率 (或者設置的類目佣金率)、通用佣金率、定向基礎佣金率、定向單品佣金率、團長佣金率,佣金率規則較豐富。

三、技術實現

3.1 實現概覽

從推廣者推廣出去到產生效果訂單涉及佣金歸屬?佣金如何計算?整體實現概覽圖如下: 

  主要分爲幾大模塊:推廣管理、點擊跟蹤系統、訂單歸因、佣金計費分潤、訂單中心;推廣管理系統主要負責生成商品對應渠道推廣鏈接、提供佣金率查詢能力供計費系統使用以及分佣金推廣平臺活動計劃設置等。用戶訪問生成的推廣鏈接的過程中的關鍵節點會被點擊跟蹤系統記錄下來,從而爲訂單歸因系統提供歸因依據。然後,計費系統根據拿到的歸因結果 (歸屬渠道、歸屬有贊客、歸因類型等信息) 去匹配對應的計費策略,通過調用推廣管理系統獲取訂單中每個商品當前享受的佣金率從而進行商品維度佣金計算。得出計費結果後到了結算時間時調用結算中心分潤接口將佣金分給各個參與分傭對象。最後,歸因結果、計費結果、訂單狀態變更、物流狀態變更、商品信息變更等都會以消息的形式匯聚到 cps-order 訂單中心,提供訂單搜索等能力並將相關狀態變更推送給三方渠道。

3.2 歸因實現 

歸因是確定用戶在完成廣告主或營銷商設定的目標之前的一段特定時間內,在用戶旅程中所經歷的不同營銷渠道的不同接觸點對達成轉化目標的貢獻價值評估。歸因讓廣告主和營銷商可以瞭解哪些接觸點有效而哪些接觸點無效,從而對廣告進行鍼對性的改進。

用戶旅程是指用戶從瞭解品牌到完成廣告主或營銷商定義的目標 (例如購買或下載) 期間所經過的路徑。接觸點是指用戶與品牌在不用渠道上的互動(瀏覽商品、訪問店鋪、看視頻等)。廣告主和營銷商將根據用戶在用戶旅程中的不同位置(如產生意識,考慮和購買),根據不同的接觸點定製營銷方案。

3.2.1 常見歸因模型

  將功勞歸功於轉化路徑上的一個觸摸點,沒有複雜的計算,易於實現且投資最少。然而,這大大簡化了全渠道客戶旅程,並可能導致嚴重的誤解。主要有以下兩種歸因模型:最終點擊歸因模型 (又稱爲最終交互或最終接觸歸因模型),將 100% 的轉化效果歸因給最後一次點擊或流量來源; 首次點擊(又名首次交互或首次接觸)歸因模型類似於前兩個模型,只是它把用戶旅程中的 100% 的轉換效果分配給了用戶旅程中的首次點擊或引薦 (referrer)

  單點觸控的簡單性使數據分析產生了空白,而多點觸控通過在客戶旅程中增加更多步驟來彌補這一差距。主要有以下三種歸因模型:線性歸因模型會平等地對待把用戶旅程中轉化路徑上的所有接觸點,對所有接觸點分配相等的權重和比例;時間衰減歸因模型是線性模型的變形,該模型在時間上最接近轉化的接觸點,獲得的權重更高;而接觸點與轉化的距離越遠,其權重 “衰減” 就越大;數據驅動歸因模型,通過預測算法來分析數據,以確定哪些渠道、活動和關鍵字對轉換的影響最大。通過識別整個用戶旅程中經歷的步驟,增加客戶轉換的可能性,並給予發揮作用的接觸點相應的轉換功勞,該模型通常需要高質量的歷史數據;

3.2.2 有贊 CPS 歸因模型

  有贊 CPS 歸因系統選擇是單點觸控歸因模型中的最終點擊歸因模型,有以下兩點考慮。第一,多點觸控歸因模型,需要在用戶旅程中存在多個觸控點且要綜合考慮每個觸控點的權重,系統複雜度高。有贊 CPS 業務主要是針對直播推廣場景用戶旅程相對較短,只需要找準關鍵的觸控點即可。第二,對比最終點擊歸因模型和首次點擊歸因模型,認爲購買前的最後接觸點是導致用戶進行購買的關鍵轉折點。

  自營模式和 CPS 模式都是按店鋪維度進行歸因,歸因結果需要幾個關鍵信息:歸屬渠道、歸屬有贊客、歸因類型 (自營或 CPS)、歸因結果等。具體規則如下:

1)下單消息攜帶對應渠道 fanstype 字段

2)店鋪授權渠道應用

1)店鋪滿足 CPS 屬性

2)存在有效點擊;店鋪 CPS 屬性定義:店鋪入駐分傭推廣已生效或退出分傭推廣未滿 15 天

注:CPS 模式歸因優先級高於自營模式。
上述規則是最基礎的歸因規則,當然在不同歸因場景會依據基礎規則衍生出其他歸因規則。例如,按照訂單 atrps 歸因、自購省歸因規則、全站歸因等。

歸因依賴於點擊歸因系統,整體流程如下流程圖所示:

1)用戶訪問推廣鏈接,點擊系統解析鏈接後校驗簽名 (通過算法加密)、生成用戶點擊信息並寫入 cookie、發送點擊 kafka 消息,再重定向到商品詳情頁在頁面並將必要信息拼接到 url 後面

2)點擊持久化服務消費點擊 kafka 消息並將點擊寫入 Hbase 並提供查詢接口,點擊記錄包含用戶、商品、推廣與店鋪等信息。除此之外,點擊持久化服務也會消費埋點點擊消息並寫入 Hbase。埋點消息會存在少量丟失以及消息延遲並不適用於性能要求高可靠性要求高的業務,因此消費埋點消息是作爲輔助 (例如,302 點擊系統對應 kakfka 集羣宕機,這時候還可以用埋點歸因)

3)歸因系統消費下單消息,根據歸因指定字段去查詢買家最新一次點擊記錄,優先做 CPS 歸因處理。CPS 歸因會按照指定指定字段優先級陸續查詢點擊記錄進行歸因。埋點消息標識用戶的字段是段是 yzUid 和 uuid,用戶未登錄時埋點消息 yzUid 字段爲空,當埋點服務異常時會出現埋點 kafka 消息 uuid 字段爲空。點擊系統使用 atruuid(同個用戶可以有多個 atrUuid) 來標識用戶對某個推廣鏈接的點擊。

根據具體業務 CPS 歸因還衍生出三種歸因方式:自購省歸因、按照 atrps 歸因、全站歸因。前兩種不需要查詢點擊記錄:按 atrps 歸因是直接歸因爲訂單消息裏的 atrps,當流量超出系統承載能力的時候系統歸因速度變慢時將大主播直播間裏商品加上到白名單去走這種歸因方式 (目前基本沒用到)。全站歸因是跨店鋪歸因 (只針對熱賣小程序),用戶訪問店鋪 A 商品然後再訪問店鋪 B 商品,會將店鋪 A 商品的 atrps 會攜帶到店鋪 B。

當執行完 CPS 歸因的所有歸因策略,還未歸因成功的話最後執行自營歸因策略,通過訂單消息裏 fansType、platform 等字段值進行歸因同時判斷店鋪是否授權。

3.3 計費與分潤實現 

  歸因是爲了得出分傭對象有哪些,計費則是根據業務計費公式分別計算每個分傭對象該分得多少佣金,分潤是根據計費得出的結果將佣金轉到對應分傭對象的賬號裏。接下來分別介紹下有贊 CPS 的計費規則、計費流程以及佣金分潤的邏輯。

3.3.1 計費規則

  計費有幾個要素:商品佣金率、分傭對象間計費優先級、佣金池維度劃分。商家可以在分傭推廣平臺設置各種推廣活動從而設定商品佣金率,各種推廣活動有優先級順序,商品命中優先級最高活動對應佣金率 (定向單品> 定向基礎>招商團長>通用單品>店鋪類目>店鋪通用)。佣金池維度指的是總佣金被劃分成幾個小區域佣金池,每個小區域佣金池都有 n 個分傭對象,分傭對象指參與瓜分佣金池的角色有唯一的商戶號(收款賬號)。

推廣活動不僅要確定商品的佣金率還決定了有哪些分傭對象,團長有贊客參與分傭的前提是商品推廣命中招商團長活動佣金率,有贊客分享賺活動會有粉絲參與分傭。CPS 模式當前有兩個佣金維度:商品佣金和團長佣金。商品佣金池最多可包含有贊客、渠道平臺、有贊平臺、粉絲幾個分傭對象,最少可包含有贊客和有贊平臺兩個分傭對象;團長佣金域只包含了有贊平臺和團長有贊客。

 

計費的業務規則是多變的,這三個要素都有可能會進行業務擴展。如增加一個佣金維度或增加一種推廣活動類型等。

3.3.2 計費流程

  計費流程需要保證消息冪等、消息亂序時也能正確處理、歸因慢了計費重試、支付或退款消息丟失能在訂單完成時觸發走一遍計費流程。
整體計算規則分爲幾步:

3.3.3 佣金分潤

  CPS 業務的最後一部就是將佣金轉到正確的賬號,需要將計費結果告訴結算中心,讓結算去調賬。CPS 業務分潤規則如下:

佣金分潤流程主要分爲兩個階段:

四、質量保障中的挑戰

基於有贊多平臺接入的業務場景與技術實現,在多平臺測試中總結了以下幾個點,分別從推廣觸達、佣金閉環、數據同步等幾方面。

4.1 測試關注點

CPS 分傭業務是一個與資金相關的業務,點擊 -> 歸因 -> 計費→分潤, 核心鏈路的任一節點出問題,都可能導致資損。所以對各個環節都需要特別關注,歸因計費是資損核心風險點。對 CPS 此類分傭業務提取了業務測試關注點如下:

4.2 測試提效與穩定性保障

在 CPS 測試中,從商家側店鋪入駐,到創建商品,添加多平臺賣貨商品審覈,生成推廣鏈接,到推廣者第三發平臺上架售賣,再到用戶側點擊購買下單,整個鏈路非常冗長。

CPS 從最初只有埋點到後面的 302 方案也經歷了大版本重構。業務迭代較快,測試資源緊張,同時還要兼顧 CPS 整體重構。在測試過程中爲了節約重複成本,提升人效,也做了非常多的數據準備工具。

4.2.1 數據工廠

測試工具主要目的是節約人力,輔助測試提效,增長技術測試團隊通過分析測試階段重複工作與耗時,從數據準備、測試鏈路推進、問題快速定位三個角度,做了多種測試工具。

4.2.2 QA 接口自動化迴歸與線上監控

有贊當前的 QA 接口自動化主要是 testNG,多平臺賣貨從最初只有 ad-cps 整體承接到 CPS 重構拆分爲多個應用,相關的自動化 case 從一百多 case 到現在的上千 case,全量覆蓋了核心場景與接口。同時推進開發單測,增加代碼合併 maser 卡點,在提測前即可通過單測與接口自動化迴歸原有功能不受影響。

線上監控通過 Robot 自動化調度,幫助線上問題提前內部發現。同時通過消息積壓告警,歸因延遲告警燈多個方式監控線上穩定性。在直播大流量場景時可以快速發現問題,及時跟進解決。

4.2.3 監控告警與資損防控

分傭業務與資金密切相關,爲了保障商家、消費者、推廣者、三方平臺與有贊平臺等各項服務穩定,對於多平臺的資損場景,增長技術團隊擬定了全方位的防控策略。

從技術方案設計,考慮了消息延遲、亂序、重複等各種業務場景的可能,設計了實時歸因,延遲歸因支持動態延遲,定時延遲等。同時又通過離線歸因比對全量,保障歸因的準確性,在 BCP 對賬中也增加了與交易、資產等訂單比對,資金對賬,保障資損問題及時發現並自動告警。

五、未來工作

有贊多平臺接入從 2019 年以來已經陸續接入了快手、虎牙、陌陌、微博、微信視頻號…… 等 19 個平臺的接入,支持 CPS 與自營多種模式,同時 CPS 有通用、單品、定向、招商等多種不同的推廣玩法,在未來會在現有接入平臺探索更多推廣合作模式,幫助有贊商家更好的完成貨品推廣。

同時多平臺技術架構與測試會沉澱分傭業務可複用能力,實現業務快速平穩落地,支持更多複雜場景與大流量接入。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/-FVDDEN8iTHyth-qcvuvNQ