起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識App用戶增長歸因方式全解析，附實操框架設計
編輯導讀：歸因分析，指的是對不同渠道的廣告的投放效果進行評估，并給出一個為什么要這么做的理由。本文作者從常見的幾種歸因分析方法出發，結合實操案例分享了App用戶增長歸因模型搭建的關鍵步驟和思考，供大家一同參考和學習。
一、需求和痛點
- 業務需求1：運營提了一個H5需求，做完H5后會找一些站外大V進行投放，希望監測到從每個大V進入H5頁面的流量如何，以及帶來多少新增用戶。
- 業務需求2：運營希望測試微信群和QQ群的拉新效果，會將同一個H5鏈接或者某個內容的鏈接發到群里，希望檢測到每個群內用戶訪問數據和新增數據。
- 業務需求3：自然新增的用戶中，希望知道這些用戶都是從哪里下載的App，以及初步分析為什么下載。
基本上關注新增用戶的運營都會提以上三個需求，三個需求的本質都是新增用戶的來源監測和動因分析。運營提出的這些需求背后都存在著一些痛點，甚至是行業痛點，簡要描述以下三條：
- 痛點1：自然新增的用戶因為不知道為何而來（動因），無法在App啟動時做精準的新用戶承接，對用戶的活躍和留存影響較大；
- 痛點2：大量投放了廣告，不知道每個渠道具體的廣告效果，也找不出最佳的投放渠道，只能靠感覺投；
- 痛點3：H5場景下獲取不到設備號，其他各種歸因方式都存在各自的缺陷，很難做到100%歸因。
二、常見歸因方式
首先需要明確下載App可以通過哪些渠道，本文將渠道分為兩個大類：
- 付費渠道：①In-App投放，②Wap投放，③短信。帶來的新增用戶定義為付費新增用戶；
- 自然渠道：自然從應用市場下載，某個H5活動頁，某個內容頁面，定制下載頁等等，非付費渠道均為自然渠道，帶來的新增用戶定義為自然新增用戶。
無論是什么渠道，最終下載App大多數都會通過應用市場，ios進到App Store，小部分安卓會通過瀏覽器直接下載安裝包（未被應用市場攔截），大部分安卓會到各自的應用商店。
1. 設備號歸因
針對付費渠道，特別是In-App投放，主要使用設備號歸因，應用在信息流廣告中。
這類歸因目前行業內已經普遍在使用，也相對比較成熟。實現方式主要從第三方App獲得用戶的移動終端的設備號，即常見的 IDFA 和 IMEI ，第三方平臺反饋給廣告主的信息會包含設備號，當用戶完成App下載激活之后，廣告主可以對用戶的設備號與第三方給到的設備號進行匹配，以此來評估投放效果以及歸因分析。
2. 渠道包歸因
渠道包歸因主要應用在安卓端，將定義好的“渠道號”寫入到APK安裝包中，然后投放到指定渠道，用戶下載和激活App后可以從安裝包中讀取到渠道號，以此來進行歸因。
但渠道包歸因存在兩個較大的弊端：其一是很容易被手機原裝的應用商店攔截，原裝應用商店為了提高下載量會識別用戶即將下載的安裝包對應到應用商店是哪個，識別到時會進行攔截，強制用戶去應用商店下載；其二是如果使用付費投放方式，渠道包歸因很容易被不良渠道方刷量，數據作弊導致真實效果無法評估。
基于以上兩個弊端，渠道包歸因主要作為自然渠道的補充歸因，很少作為付費渠道的主要歸因。
3. 剪貼板歸因
剪貼板歸因目前是Out-App場景下最有效的歸因方式，可以將唯一標識寫入剪貼板，作為H5場景無法獲取設備號的替代方案。
主要實現方式：用戶在站外點擊下載坑位，將唯一標識寫入剪貼板，用戶下載并激活App后，客戶端讀取剪貼板內容，符合規則的上報服務端（或者全部上報由大數據進行清洗），同時連帶設備信息等一并上報，用于判斷是否是新增用戶。
剪貼板的優勢在于唯一標識口令可以非常靈活，里面可以包含用戶點擊的是哪個坑位，訪問的是什么內容，用的什么瀏覽器等等，前端能夠采集到的信息都可以封裝成口令放入剪貼板。
但是剪貼板也不是萬能的，網信辦一直三聲五令禁止讀取用戶剪貼板，屬于用戶隱私信息。同時，基于安卓深度定制的機型很多禁止應用讀取剪貼板，這讓剪貼板歸因是效率有所降低，根據經驗推斷Out-App場景的歸因多種方式組合上限能夠歸因70%。即便如此，剪貼板仍然是目前設備號歸因之外最高效的歸因方式。
4. IP+UA歸因
IP+UA歸因是指用戶點擊下載坑位時，采集用戶的IP和UA（User-Agent，包含用戶的操作系統、手機型號、瀏覽器信息等等），與激活App時用戶的IP和UA進行匹配，以此達到下載歸因。
這種歸因方式屬于模糊匹配，相對于前三者沒有唯一的標識與客戶端和服務端進行通信。同時，IP在公共網絡環境下是同一個，IP和UA也很容易隨著環境發生變化，因此歸因效率最低。舉個例子：用戶在wifi環境下下載了App，但是在4G環境下才激活App，這時候IP是不一樣的，而UA很可能存在兩個完全一樣的機型，這時候就無法通過IP+UA進行歸因。
5. 小結
三、靈活歸因框架設計
1. 靈活采集，多方式歸因
針對設備號歸因的場景，目前行業內已經有非常成熟的方法，在此不再贅述，以下僅針對Out-App場景的歸因進行敘述。
為了滿足文章開篇的三個需求，需要在數據采集時候支持靈活變化，以及配合埋點上報訪問和點擊行為。因此必須在URL后面加上特定的字段用于標識不同的場景（定義為“渠道號”，渠道號可以自由定義和擴展），針對不同的場景進行投放，每個渠道號都對應各自的渠道包，用于渠道包輔助歸因。
埋點層面：比較合適的做法是從URL中取渠道號存在本地，訪問及之后的點擊行為都從本地取渠道號進行上報（同時上報IP+UA），如果后面有發現渠道號發生變化，則更新本地存的渠道號。這樣做的好處是用戶后續所有的行為都可以依據本地存儲的渠道號進行上報，結合新增歸因就可以制作出 訪問——點擊——激活 這樣的新增漏斗。
歸因層面：采用剪貼板歸因為主，渠道包歸因為輔，IP+UA歸因作最后填充的方式進行。在Out-App場景下H5無法采集到用戶的設備號，設備號歸因這條路直接堵死，剩下三種方式可以集成起來全部使用。具體流程如下：
采集：需要一個JS-SDK，用于采集用戶的IP、UA、URL的渠道字段、內容字段（活動id、內容id之類的信息）等其他信息，將這些信息匯總成一個口令放入剪貼板，同時SDK上報采集的信息到服務端。
匹配：用戶安裝并啟動App時，客戶端將剪貼板內容、用戶IP+UA、以及客戶端采集到的設備信息傳給服務端，同時通過埋點上報給大數據一份。服務端判斷是否為新增用戶（通常會使用設備首次啟動App時間進行判定，同時也會使用設備最近一次啟動App時間判定是否是召回用戶）。
判定是新增用戶，若剪貼板有口令，則記錄所有信息；若無口令，判斷是否為渠道包，若為渠道包則解析渠道信息進行記錄；若無口令且非渠道包，則將IP+UA與SDK采集的IP+UA進行匹配，定義一個時間范圍兩個IP和UA相同，認定為新增用戶。
以上的新增歸因方面其實大數據也可以進行處理和分析，但是一般大數據的實時性相對較低，采用服務端處理能夠實時確定用戶是否為新增用戶，且可知道用戶從何以及為何下載App，可以對后面客戶端的新用戶承接提供很好的基礎信息。
2. App靈活承接
剪貼板口令中往往會有內容id、活動id之類的動態信息，標識用戶是從什么地方點擊的下載坑位，這樣就能夠初步推斷出用戶的興趣偏好，打上最初的用戶標簽進行內容冷啟動。
比如用戶是從一篇鳳凰古城的游記下載的App，可以初步判斷用戶想了解更多鳳凰古城相關內容，在啟動App時可以先跳轉到當時下載App的那篇游記，并推薦一些其他關于鳳凰古城的游記，以及鳳凰古城周邊景點和古城類型景點的攻略。這些操作經過很多輪AB測實驗下來，對于用戶活躍和留存效果會遠高于什么都不做。
新增歸因提供了用戶下載App的初始動因，針對不同動因可以設計后臺配置相關的承接方式。內容類的新增可以為推薦算法提供用戶初始的標簽；活動類的新增可以在啟動App后直接跳轉到活動頁；渠道包相關可以定義特殊的承接方式，與所投放渠道相契合；IP可以提供一些本地生活相關的推薦服務……
3. 整體框架設計
結合以上內容，對整個新增歸因和App承接進行如下框架設計，可以兼容多種場景和多種業務共同使用，只要在URL的渠道字段中定義好各自的場景或者業務，相應后臺配置好對應的承接方式即可。
作者：全導，微信公眾號：零向度（lingxiangdu）
本文由 @全導 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
不錯，學習了