本篇講述歸因分析在實際業務中的應用及實現方法，主要講解「渠道歸因」和「運營位歸因」的「單值傳遞歸因」、「多值記錄集合歸因」、「時序還原歸因」以及「路徑還原歸因」幾個方法。
01 了解歸因分析隨著網際網路技術和業務的發展，廣告投放相關的業務也隨之興起。那麼廣告投放的效果評估也就隨之而來。
首先，廣告的投放一般都是收費模式，所以選中的渠道商的好壞直接和自己的利益掛鈎。於是，「歸因分析」便最早應用在了廣告投放行業。（歸因分析能最先應用在廣告行業還有一個原因，就是廣告的目標是單一的。比如：無論多少個渠道商，最後推的都是同一款 App；但是若將在產品內部的運營位進行歸因，就需要考慮這個廣告位和商品是否有關係。）
舉個例子：一款 App，投放了三個推廣渠道，最後 App 通過某個渠道商完成了下載。此時，我們需要對這三個渠道商對本次下載的貢獻能力進行一個評估。這時，就用到了歸因分析。
02 渠道歸因（站外歸因）渠道歸因是目前市面上比較廣泛的歸因應用場景。
圖中舉例說明了一個渠道歸因的大致流程和思路：用戶分別瀏覽了「Youtube」「Google」和「Facebook」後下載了 App，通過歸因分析來計算三個廣告的貢獻。
點擊放大圖片查看
03 運營位歸因（站內歸因）隨著渠道歸因的普及，從業人員逐漸認可了歸因的計算方法和功勞的分配方案，雖然模型的不同會導致計算結果存在一定偏差，但是這些都在可接受的範圍內。
後來，隨著產品的複雜化、公司部門的事業部、業務線的劃分。產品內部的運營位逐漸被廣告化，於是運營位的歸因需求逐漸被暴露出來。
接下來，我們來說一下運營位歸因的演進歷史。
1. 傳遞式單值歸因傳遞式單值歸因是歸因分析由渠道轉向運營位時，採用的簡單轉化方案。當然這個方案，至今還在被一些公司沿用。該方案的優勢：邏輯清晰、實現簡單；劣勢是：無法匹配稍微複雜的運營場景。
圖中舉例說明了一個傳遞式單值歸因的大致流程和思路，由於技術的原因，在記錄廣告時，使用的是替換的策略——即每次只記錄前一個廣告，當出現新的廣告則替換前一個廣告名稱，直到成單轉化，記錄在訂單上。
用戶分別瀏覽了「廣告 A」「廣告 B」和「廣告 C」後購買了「商品 C」，通過記錄最近一次廣告運營位，來進行歸因，計算運營位的貢獻。
點擊放大圖片查看
在網際網路初期，人們的業務模式都比較簡單、使用流程也很單一，使用前篇講解的「單值傳遞歸因」完全夠用。
但是某一天，人們發現自己 App ，已經不再是簡簡單單的「廣告 → 商品 →購買」路徑，又多出來了很多其他的路徑。比如：「搜索 → 商品 → 購買」、「推薦 → 商品 → 購買」或者「推送 → 商品 → 購買」，甚至是「紅包 → 商品 → 購買」時，我們會發現，原來的那套邏輯，有一些過時了。
解決問題的辦法也很簡單，就是將原來的一個值，變為記錄多個值。那麼，我們就來推演一下後續每個版本的歸因分析的實現的思路和計算方法。
2. 場景我們假設一個場景，接下來三個模型的演繹都使用該場景進行還原。
首先，用戶來到了一款電商類 App，打開首頁，看到的是頂欄「搜索」「頭部廣告」腰部的「推薦商品」，其中「頭部廣告」是一個主廣告，點擊進去分為兩個「分會場 A」和「分會場 B」的子廣告，「推薦商品」動態計算，展示您最可能購買的商品。
接下來，一個用戶開始使用我們的 App，行為如下：
進入首頁，先行搜索，在列表頁看到了商品 A，瀏覽了商品 A 的詳情，覺得不錯，但是並未購買；從詳情頁返回到首頁，看到頭部廣告，點擊進入到主會場頁面；在主會場頁面，看到分會場 A 和分會場 B，點擊進入分會場 A，再次看到商品 A，點擊再次查看商品 A 詳情；頁面返回到主會場頁面，進入分會場 B，在分會場 B 中瀏覽了商品 B 的商品詳情；直接退出到了首頁，發現推薦位在推薦商品 A，進入再次查看商品 A 的詳細信息；看到了推薦的評語，下定決心，購買了商品 A。最終，我們想看每個運營位，對用戶購買商品 A 這個決策帶來的貢獻。
由於業務變得複雜、來源增多，那麼最簡單的方式，就是由原來單值的記錄形式變為多值。
再解決額外引入的幾個問題，分別是：
為了避免無窮無盡的記錄廣告，以及將不屬於這個商品的廣告記錄在這次購買中，需要引入一個重置的機制，比較簡單的重置就是：App 冷啟動、訪問回首頁和發生後支付就進行重置。記錄下了廣告的集合併完成了數據的採集，後期需要再進行邏輯的運算，來給每個廣告位分配功勞。4. 時序還原歸因在我們看了多值集合歸因的推演之後，可以很明顯的發現其中的問題：重置機制實在是太坑了，回到一次首頁之後，全部的努力就白費了。
那麼，有沒有更好的辦法來解決這個問題呢？
實際上，我們從根本上來思考這個事情，我們想探索的是「廣告」和「成單」之間的關係，那麼這層關係是依靠什麼進行關聯的呢？很簡單，是依賴這個商品關聯。
那麼，我們再將這個邏輯抽象一層的話，這整個行為中最為緊密的關鍵節點是什麼？
——我認為是：點了廣告，所以讓你看到了這個商品，因為看到了這個商品，所以你才產生衝動購買了這個商品；那麼轉化為抽象的描述就是：廣告 → 曝光 → 轉化
那麼，新的問題來了，我如何去探索這個關係呢？
別忘了，人的行為發生是有先後順序的，於是我們嘗試通過時間序列來還原用戶當時的場景，再根據曝光→轉化，來跳過一些和轉化無關的廣告位。（演繹圖需從購買商品為起點看起）
5. 路徑還原歸因從上面的時序還原的歸因模型中，可以看到：已經可以比較好的解決問題了。但是，距離完美，還是差那麼一步。就是類似於「主從廣告」這種廣告結構時，不能很好的進行還原，兩個有關聯的廣告相鄰時，也不能很好的進行關係的計算。
解決辦法也是有的，我們需要再引入一個維度：時間的維度可以表明事情的發生順序，再引入路徑的維度，就可以更加準確的還原事情的流向。
像「頭部部廣告 → 廣告 A → 廣告 B → 廣告 A」的這種情景，通過路徑可以還原出一個樹形結構，即「頭部廣告是廣告 A 和廣告 B 的父節點」，自然幾個廣告的關係也就出來了。（演繹圖需從購買商品為起點看起）
04 總結本文章幫大家梳理了一下歸因分析的一些思想，類似於歸因分析這種和業務貼合特別緊密的分析模型，是會隨著業務形態的變化而逐漸優化和改變的。
目前大部分的歸因分析都在應用「單值」或「集合」的形式進行記錄，極少數使用「時序還原」的形式，因為這個計算量太大了，而且需要引入一些標準化的埋點才可以做。當然，「路徑還原」就更少了，因為他是在「時序還原」的基礎上又提升了一檔難度，需要再額外記錄頁面的前項地址，來進行路徑的還原。
最後，希望大家可以在了解了歸因分析的前世今生和未來後，可以了解的是結合自身業務情況進行數據的推導和演繹的能力，而不是將一個模型一成不變的進行套用。
作者：宋宋，神策數據產品經理。
本文由@請叫我宋宋 原創發布於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash, 基於CC0協議。
收藏已收藏 | {{ postmeta.bookmark }} 點讚已贊 | {{ postmeta.postlike }}