01

電商歸因目的

對于電商平臺來說，當流量進入時，我們需要引導(dǎo)其完成購買任務(wù)，以實現(xiàn)流量價值最大化，在互聯(lián)網(wǎng)紅利消耗殆盡之時，流量會越來越貴，我們需要精細化運營每一份流量。

我們在做各種banner活動、Feed流推薦優(yōu)化、活動頁等進行效果評估，無法知道該位置最終產(chǎn)生了多少收益，也就很難針對該位置進行有效的改進。

如果進行單因數(shù)AB測試進行改版的效果評估，那也會存在如下2個問題：

單因素變量控制并不容易做到完全可控，如果產(chǎn)品處在增長期，產(chǎn)品增長本身就是一個影響因子，很容易忽略此類因素的影響。

評估方式低效，如果 2 天內(nèi)只控制 1 個坑位變動，那么評估 20 個坑位內(nèi)容改變就需要 40 天時間，這樣的效率任何企業(yè)都無法接受。

因此，我們希望用數(shù)據(jù)分析中歸因的方式解決坑位運營中評估的問題。

我們引入電商坑位歸因的概念，把每一筆的成交都歸給轉(zhuǎn)化路徑中不同的坑位。根據(jù)坑位的曝光轉(zhuǎn)化價值來評判坑位的好與壞。把寶貴的流量盡可能都引導(dǎo)到轉(zhuǎn)化率更高的坑位，以此達到精細化運營的效果。當然有了這個坑位價值評判的機制后各個坑位的改版也能準確的評估，真正做到了數(shù)據(jù)驅(qū)動增長。

02

歸因類型簡介

首次觸點模型：多個「待歸因事件」對同一個「目標轉(zhuǎn)化事件」作出貢獻時，認為第一個「待歸因事件」功勞為 100%。

末次觸點歸因：

多個「待歸因事件」對同一個「目標轉(zhuǎn)化事件」作出貢獻時，認為最后一個「待歸因事件」功勞為 100%。

線性歸因：

多個「待歸因事件」對同一個「目標轉(zhuǎn)化事件」作出貢獻時，認為每個「待歸因事件」平均分配此次功勞。

位置歸因：

多個「待歸因事件」對同一個「目標轉(zhuǎn)化事件」作出貢獻時，認為第一個和最后一個「待歸因事件」各占 40% 功勞，其余「待歸因事件」平分剩余的 20% 功勞。

時間衰減歸因：多個「待歸因事件」對同一個「目標轉(zhuǎn)化事件」作出貢獻時，認為越靠近「目標轉(zhuǎn)化事件」做出的貢獻越大。

對于電商平臺來說，末次觸點歸因是比較適合電商站內(nèi)銷售歸因的。雖然用末次觸點歸因?qū)崿F(xiàn)方案上比簡單，但是直接將價值100%歸因給購買或者轉(zhuǎn)化之前最后一次接觸的渠道，而完全不考慮整個過程中消費者到底接觸過多少個觸點。轉(zhuǎn)化之前發(fā)生了太多的事情，該模型完全忽視了漏斗上層和中層部分的行為對轉(zhuǎn)化的影響。

因此我們公司融合首次觸點歸因和末次觸點歸因，計算用戶進入一級流量入口后再到完成的完整購物鏈接行為。一級流量流入的定義為：各個入口之間無法進行跳轉(zhuǎn)，只能通過切換tab進行跳轉(zhuǎn)或者返回初始位置后重新點擊進入。這樣我們就可以基于購物的完整鏈接的最外層進行銷售歸因，并且也能知道用戶購物的完整路徑，同時保證銷售歸因后各個入口坑位的銷售額之和等于當日的銷售額。

使用這種融合歸因方式，也可能知道中間步驟的轉(zhuǎn)化率。比如活動會場頁和商品詳情頁的相關(guān)推薦，雖然對電商平臺整體進行銷售歸因時，不會計算活動會場頁各個模型的銷售，也不會計算商品詳情頁的相關(guān)推薦。

但是由于我們記錄了用戶進入一級流量入口后的詳細路徑，因此我們單獨研究活動會場頁和商品詳情頁的效率時，也是可以計算得到各個模塊的銷售來進行對比分析。但是切記不能和一級流量入口的銷售混合在一起看，這樣會導(dǎo)致銷售歸因發(fā)生重復(fù)。

03

電商歸因?qū)崿F(xiàn)方案

對于電商歸因我們進行了三個方面的歸因，包括：曝光歸因、點擊歸因、銷售歸因。即歸因出所有的商品曝光來自哪里，所有的商品點擊來自哪里，所有的銷售來自哪里。這樣就可以追蹤各個流量入口的曝光鏈路歸因指標。比如各個流量入口的商品曝光點擊率、商品點擊支付率、商品曝光價值等等核心監(jiān)控指標來評價各個流量入口的效率。

電商歸因準確的前提是埋點日志的完整性，因為我們是通過需要歸因的事件往前找到用戶的購買路徑，這樣的好出是大大減少計算量，也基本解決的歸因的問題。因此用戶行為日志的完整記錄才能真實還原用戶的購買路徑，否則就可能導(dǎo)致歸因出錯，最終造成錯誤的評價數(shù)據(jù)。

首先需要在埋點體系中引入PageId的概念，PageId的作用是每當用戶產(chǎn)生一次跳轉(zhuǎn)行為進入一個新頁面時，為這個頁面賦予一個新的PageId；而當用戶點擊返回時，不會產(chǎn)生新的PageId。PageId是越靠近的當前時間的頁面瀏覽的行為越大，且不會重復(fù)，類似于自增ID的實現(xiàn)邏輯。PageId的實現(xiàn)當然是寫入埋點SDK當中，這樣保證所有的埋點事件都帶上PageId，并且也無需開發(fā)同步每次單獨寫邏輯。

然后根據(jù)埋點日志去還原用戶的行為路徑，全程都可以僅僅使用SQL邏輯就能計算完成。

首先要確定所有要歸因的end事件（末端事件），包括商品曝光、商品點擊、商品加購成功（加購后可以通過server的訂單表判斷用戶是否完成了付款，也達到了銷售的歸因目的）。

然后在確定所有歸因head事件（首端事件），即之前就定義的好的各個一級流量入口。

我們平臺比較特殊，是工具類App同時擁有電商業(yè)務(wù)，這樣一級流量入口會比較多，但是可以枚舉完成的，不僅僅包括常規(guī)電商App的流量入口，還可以在各個工具頁面嵌入電商入口，這樣復(fù)雜性要強于一般的電商App。

我們的埋點日志都會記錄用戶發(fā)生各個行為的本地時間，用end事件時間去找最接近的這個時間的head事件，直接用SQL的left jon關(guān)聯(lián)日志表就能完成計算。

這樣在首尾2段時間內(nèi)的所有埋點日志行為就是我們需要日志。

然后篩選出這些日志中的所有點擊事件，過濾掉其他無效事件。

再對所有剩下的日志進行排序，按照本地時間排序，這樣就得到了一條完整的用戶有效行為的路徑記錄。

對于這部分數(shù)據(jù)我們就可以進行存儲使用了，這部分數(shù)據(jù)為歸因后用戶完整鏈路記錄數(shù)據(jù)。

再基于PageId過濾掉同個頁面相同PageId的事件，保留本地時間最晚的那一條事件記錄。

這樣就得到了用戶進入一級流量入口后真正進行末端事件的有效路勁。

這部分數(shù)據(jù)也需要存儲記錄，并且這個部分真正歸因完成的用戶行為路徑，此時的得到各個一級流量入口就行歸因得到此末端事件的來源。

通過這樣計算后就了解各個一級流量入口的商品曝光點擊情況，也能知道銷售情況。

利用這些數(shù)據(jù)就能衡量各個流量入口的效率情況，也同樣也可以中間承載頁面的效率如何。

就能幫助產(chǎn)品運營更好的改善各個功能以及迭代各式各樣的活動。

用戶進行一次加購的路徑還原

通過上述方法的計算，我們最終得到的用戶加過鏈路步驟為：【1，2，9，10，11】，并且入口事件【1】就此次加購事件的歸因來源。

另外再來舉個商品詳情頁相關(guān)推薦的例子，下圖所示的用戶行為最終得到的鏈路步驟為：【1，2，9，10，11，12】，由于我們是完整保留用戶的路徑，因此我也只能這次加購事件不僅來源于1，也有一部分功能功能來于11，也就是商品詳情頁的推薦，因此我們也能計算出商品詳情頁的推薦效率如何，后續(xù)算法團隊迭代模型時也能根據(jù)這個數(shù)據(jù)來衡量優(yōu)化的好與壞。

04

總結(jié)

通過以上方案得到電商歸因模型數(shù)據(jù)，可以大大提高運營同學的運營效率，不再是盲人過河實的憑感覺去優(yōu)化各個坑位和活動，已經(jīng)可以通過數(shù)據(jù)清晰公平的判斷運營每一次迭代的結(jié)果。

但是僅僅根據(jù)坑位歸因決定坑位價值，容易出現(xiàn)短期偏見，即追求短期利益，比如在一款內(nèi)容產(chǎn)品中鑲嵌一些游戲元素，可以讓用戶停留更久、數(shù)據(jù)表現(xiàn)更好。但從長期來看，這種行為破壞了整個產(chǎn)品的價值定位，因為內(nèi)容產(chǎn)品原本提供的是內(nèi)容并不是游戲，產(chǎn)品也不并是為了追求用戶停留時長而是為了實現(xiàn)價值。這是兩者都存在的短期偏見。

因此不能僅僅根據(jù)坑位歸因后的銷售轉(zhuǎn)化價值來評價坑位，還需要綜合考慮產(chǎn)品價值定位、戰(zhàn)略發(fā)展等因素，才能圍繞長期目標進行健康發(fā)展。

責任編輯：haq