歸因情況調研

0 評論 7537 瀏覽 22 收藏 13 分鐘

編輯導語:我們在開始進行廣告投放前,常常需要做歸因情況的調研,了解并區分不同的歸因情況,有助于我們更加精準地進行投放。作者詳細介紹了幾種歸因情況以及如何使用歸因數據,一起來看下吧。

一、背景和意義

歸因是與廣告主做結算的必經過程,包括兩個內容:

  • 這個激活是來自于誰( ST / FB / Google / … )的?
  • 這個激活的產生應該歸功給哪個前置接觸點。

主要結算都依賴于 AppsFlyer 的歸因支撐,了解清楚歸因信息有助于我們:

  • 對情況進行監控,以使得我們可以科學的發現問題、分析問題和解決問題;
  • 對投放策略有更精準的認知,為精細化投放策略打造基礎。

在實際的投放過程中,我們有 2 種投放方式:

  • 點擊廣告后,跳轉 GP,用戶自主從 GP 下載安裝包;
  • 點擊廣告后,直接下載 apk 安裝包。

二、結論

跳轉 GP,使用 Referrer 歸因方式,直接 apk 下載,使用預裝歸因方式,正常情況下,不會存在被搶歸因問題;(當廣告主有大量外部投放時,在既定 last-click 歸因模型下,不能認為是我們的轉化)

跳轉 GP 的情況下,AppsFlyer 采用 last-click 歸因,可以歸因到具體廣告位的點擊;預裝的情況下,AppsFlyer 無法歸因到具體的前序行為,僅能通過神策上報是否安裝完成,與激活有一些口徑差距;

如果第二次激活距離第一次激活超過 90 天,則會被記錄為新用戶;

歸因明細數據,可作用于:

  • 精準的廣告漏斗分析和監控;
  • CVR 預估模塊的輸入。

三、歸因邏輯

1. 激活來自誰?

Appsflyer 上:

  • 跳轉 GP 下載,采用的是 referrer 方式歸因;
  • apk 方式,采用的是預裝歸因;
  • 極少量的來自于 Actionbar 和 Speeddial 的量,采用概率歸因。

從當前信息來看,無論是 referrer 歸因還是預裝歸因,如果實施合理,鏈路正常,都不會存在被搶歸因的可能。

Referrer 方式歸因:

當你點擊帶有 UTM 參數的鏈接跳轉到 Google Play 商店中下載時,Google Play 商店應用會在你的應用安裝期間向應用廣播一條 INSTALL_REFERRER Intent。

如果你達到 Google Play 商店頁面的鏈接中有 referrer 參數,此 Intent 就會包含這個參數的值,也就是UTM的信息被應用下載的時候就被傳遞到 APP 里面去了,APP 一打開就會上傳。

預裝方式歸因:

渠道包的具體實現方式就是開發者為每一個渠道生成一個渠道安裝包,不同渠道包用不同的 Channel ID (渠道標識)來標識,這個id一直跟app綁定;當用戶下載了 App 之后,ID會隨相關的數據發送回來,從而實現渠道的識別。

概率模型歸因:

在 AppsFlyer 數據中,存在小部分(3 天 23 個)歸因為概率歸因,其有個共性,即 site_id 取值僅為 2 個:

‘immersive_apk_Actionbar’,‘immersive_apk_Speeddial’。

如何被搶歸因?

(1)Click Spamming

Click Spamming,也叫 Click Stuffing 或 Click Flood,中文名叫點擊欺詐、點擊泛濫、點擊填塞、大點擊、預點擊、撞庫。

做法是偽造海量廣告的曝光或點擊,等到用戶真安裝之后,在 Last Click 歸因原則下,如點擊后N天內安裝的都算成帶來點擊的渠道,將其他渠道或者是自然量歸因搶到自己的渠道中來。

這種方式的作弊成本最低,但隱蔽性很差。

(2)Click Injection

Click Injection 、中文名點擊劫持、點擊注入、小點擊, 是當前安卓應用系統最猖獗的作弊手法,雖然谷歌最新的 Google Install Referrer API 供點擊引薦時間、應用安裝開始的時間,可以有效避免點擊劫持,但是基于 Google Play,國內無緣。

做法是弊者利用的是安卓操作系統上的廣播接收器(broadcast),由于安卓設備上的所有應用都可以配置廣播接收器(包括最常見的 Google Referrer 廣播)來收聽系統廣播的信息—包括接收裝置上其他新安裝的信息。

如你手機中流氓 APP 或惡意插件監聽到你正在安裝一個 APP,于是乎同時捏造一個假的點擊上報。也就相當于宣告當前的安裝是由于這個假點擊所產生的,而如果這個用戶確實安裝了該APP,根據 Last Click 規則監測工具就會認定這個應用是由這個渠道帶來的。如下示例:

  • 時間:22:55:57——用戶在渠道 A 在點擊下載 APP,觸發監測平臺的監測鏈接,記錄到點擊前的數據
  • 時間:22:55:59——用戶被重定向到應用商店
  • 時間:22:57:26——監測平臺在收到了渠道 B 的點擊
  • 時間:22:59:00——應用程序的第一次打開發生

在這個過程中,用戶第一次打開應用,根據 Last Click 原則,這次轉化歸功于渠道 B。

這種方式實現難度更大,更精準,隱蔽性更強。

IOS 不存在,因為 IOS 不存在類似安卓的廣播機制,但是還是可以收集IDFA去主動發送去撞庫,就是上一種情況。

應對方法:基于 Google Play 的 Referral API 可以獲得安裝完成的時間戳和第一次打開的時間戳,可以用于判斷。

(3)Installation hijacking

中文叫安裝劫持、渠道包劫持。

做法主要是利用在不同應用市場或推廣渠道的渠道包在打包時會通過渠道 ID 區分來源的原理,在用戶想要安裝APP時對用戶發出不安全提示,引導用戶前往自己的應用市場,在用戶在不知情的狀態下改變渠道包的來源,從而讓自己應用商店或渠道獲取新用戶。

當用戶在瀏覽器中下載了一個 App,準備安裝的時候,突然畫面跳出對話框,提示基于病毒或是其他安全因素,建議用戶從手機廠商的「官方渠道」下載 App,一旦用戶選擇同意,用戶會跳轉至手機廠商的「官方渠道」下載。

這意味著手機廠商已經劫持了此次安裝。這里手機廠商利用自己在系統權限上的優勢做的小動作。

下面是對對正常轉化和安裝劫持的兩個示例:

① 正常轉化

用戶點擊媒體渠道 A 的廣告,然后立即下載應用或跳轉到媒體渠道指定的國內第三方應用商店 A下載。在監測平臺中,會記錄到以下歸因數據:

  • 媒體渠道 :媒體渠道 A
  • Install app store :媒體渠道指定的國內第三方應用商店 A

② 安裝劫持

用戶點擊媒體渠道A的廣告。在啟動下載時,設備上會彈出一個警告窗口,提示用戶從設備制造商的應用商店下載應用程序。如果用戶同意,用戶會跳轉至制造商的第三方應用商店B下載。在監測平臺中,會記錄到以下歸因數據:

  • 媒體渠道 :媒體渠道 A
  • Install app store :設備制造商的應用商店 B

2. 激活來自哪個行為?

上圖為示例的用戶旅程圖:

下方為用戶行為,AppsFlyer 以激活(安裝后首次啟動)為最終結算口徑;卸載重裝是否算新的,以其重裝行為是否在首次激活的歸因觀察窗口內來判斷;上方由 3 個主要的歸因窗口組成:(對應的激活,來自哪個行為)。

  • 瀏覽歸因窗口——一般不采用此種歸因方式;
  • 點擊歸因窗口——默認設置窗口是 7 天,當前 KA 廣告主中,TT 是 2 天,Kwai 是 7 天,選用的應該是 last-click 歸因(即將激活歸因到時間上最近的一次點擊);
  • 再歸因窗口——默認是 90 天,廣告主一般不會修改,也即安裝 90 天后,但卸載了的用戶,再推安裝是可以計入的。

3. 卸載重裝是怎么處理的?

用戶安裝后卸載再安裝的情況下,如果第二次安裝距離第一次超過 90 天,則會被記錄為新用戶。

4. 歸因數據的使用

激活的明細數據,可以在 AppsFlyer 上下載得到,可以通過 gaid 來對應每個激活的詳細歸因信息,但預裝無法歸因到具體的點擊。

通過對數據的解析使用,一是gaid -> 設備ID 映射;二是激活數據與點擊行為的關聯,可以供 2 項應用:

  1. 精準的廣告漏斗分析和監控;
  2. CVR 預估模塊的輸入。

參考資料:

  • AppsFlyer 歸因
  • FB 歸因
  • Google 歸因
  • APP來源追蹤方式(歸因)——Android篇
  • 揭秘點擊注入劫持安裝:Google Install Referrer API影響評估

 

作者:Tom,現深圳大宇無限數據產品經理,專注數據治理與商業化;“數據人創作者聯盟”成員

本文由@一個數據人的自留地 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自pexels,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!