iOS 14.5 及更高版本的發(fā)布,也意味著 iOS 移動營銷面臨顛覆。為更好地服務 Branch 用戶,本圖文將詳細闡述,這一變化如何影響您的 Branch 數據,以及要對 Branch App 的配置進行哪些更新。
我們先來理清今天討論的內容會帶來什么大的影響:
左側展示了到目前為止您 Branch 歸因數據的樣子:單個合并數據集,其轉化記錄在所有渠道上均已去重。和任何歸因系統(tǒng)一樣,總會有一堆“未知”的轉化。該存儲桶有時也稱為“自然”或“未歸因”,但所有這些術語含義都相同:系統(tǒng)轉化未歸因于任何市場營銷活動。
右側展示了在執(zhí)行 Apple 的新 iOS 14 隱私政策后,您 Branch 數據的樣子:在您慣??吹降膯蝹€合并報告中,之前歸因于廣告渠道的所有轉化現在都將顯示為“未知”。通過 Apple 的新 SKAdNetwork 框架,您的廣告將會有一個單獨的歸因數據池。
由于 SKAdNetwork 的設計,只有當前某些常見廣告活動類型能提供該廣告數據。因為不是設備級別的數據,所以比往常的粒度要少得多,并且不能與任何其他營銷渠道進行數據去重。
好在還有辦法可以在合并的去重報表中贏回一些細粒度的設備級廣告數據:您可以通過 Apple 的新 ATT 框架讓用戶授權:
我們從一開始就應該明白:沒有一勞永逸的解決方案,一切不可能維持原樣。從 MMP 到廣告平臺,從發(fā)行商再到像類似您的廣告商,生態(tài)系統(tǒng)中的每個人都必須清楚如何應對 Apple 的變化。
iOS 14.5 發(fā)布后,iOS 廣告歸因將更為復雜。本文將介紹 Branch 產品更新,這些更新旨在幫您解決問題。
#您的 Branch 數據將如何變化#
我們從一個簡單的流程圖開始,該流程圖說明了哪些 Branch 客戶將受到這些變化影響:
如果您正在使用 Branch 進行廣告歸因,并計劃向用戶展示 ATT 提示,則這些產品變化會影響您。
為什么 Branch 需要更新?最關鍵的是,ATT 授權過程會帶來時間上的問題。這里是一個典型的用戶轉化過程:單擊廣告,從 App 商店下載該 app,然后打開該 app。到目前為止都不難。
接下來才會遇到問題:首次打開 app 后,Branch SDK 會被觸發(fā),接著就該進行安裝歸因了……但您還沒向用戶展示 ATT 授權申請:
在時間上會存在問題:在您獲得授權之前 (可能用戶在首次打開 app 后的某個時間才會授權),您將不會獲得 IDFA(廣告主ID),也無權歸因設備級廣告轉化。
Branch 正在研發(fā)的分析產品變化旨在幫助找回此流程中安裝相關的廣告歸因。我們構建的解決方案反映了一些重要的需求,值得展開談談:
新方式必須完全遵守 Apple 的 ATT 政策。我們聽說其他一些 MMP 計劃通過概率匹配在后臺“作弊”,即使沒有用戶 ATT 授權也仍舊這么做。我們認為 Apple 會嚴厲打擊這種行為,并且我們非常重視要確??蛻舨粫蜻`反政策而被 App 商店禁止。
Branch 不得通過更改已報告的事件來“重寫歷史記錄”。追溯數據更新會帶來問題,并使您的工作流程更加復雜。
Branch SDK 仍需要在 App 被首次打開時觸發(fā)。自有和自然渠道的深度鏈接和歸因都依賴于此,而這兩種渠道均不受 Apple ATT 政策的影響。
您可能還在了解這些新的復雜情況,并在思考“努力讓我的用戶授權 ATT 是否值得?”
Branch 認為,在大多數情況下是值得的。Apple 所做的更改將降低您對廣告歸因的了解。這是不可避免的,并且是移動生態(tài)系統(tǒng)中每個廣告客戶都需要應對的令人不快的現實。
您仍有兩個選擇:擁有一些 數據或什么數據也沒有。即使是有限的設備級信息,也仍然可以幫助您在廣告活動優(yōu)化和客戶終生價值 (LTV) 等方面更好地做決策。
# 新數據流示例 #
簡而言之,這是我們所做的改變。
首先,我們正在做什么
我們在追蹤另一個分析事件,我們將其稱之為“二次安裝”。處理二次安裝與處理普通安裝方式相同,二次安裝時還會產生數據參數,從而可以進行數據去重。用戶授權 ATT 之后,二次安裝將觸發(fā)廣告驅動的安裝。此更改將為 Branch iOS SDK 所有版本自動更新,并且您不需要更新 SDK。
另外,雖然不強制,您也可以更新至 iOS SDK v1.39.2 +,從而可以將授權或拒絕 ATT 視為新的專門事件進行捕捉,并上報所有事件發(fā)生時 ATT 的狀態(tài)。
現在,我們不會做的是
如果用戶未授權 ATT,我們便不會對廣告驅動的安裝進行任何形式的設備級歸因。同樣,這是為了確保我們遵守 Apple 的政策,并保護您。
用戶授權后,我們也不會在首次安裝事件上重寫任何日志級別的數據。這是為了讓您的數據工作流更簡化和可預測。
最后,我們不會為非付費來源的授權觸發(fā)“二次安裝”,因為在這種情況下,我們已經能在用戶未授權 ATT 的情況下進行設備級歸因了。
通過實踐示例,我們能更好地了解背后的原理。這些示例演示了 iOS 14.5 及更高版本上您 Branch 數據的情況。
# 立即授權流程 #
第一個示例展示了最簡單的流程:用戶點擊廣告鏈接,安裝您的 app 并在安裝后立即授權 ATT。在此流程中,假定用戶已經授權了發(fā)布者 app 中的 ATT,也因此能在交易第一端獲取 IDFA(廣告主ID):
由于用戶先前授權了 ATT,因此他們在發(fā)布商 app 中的廣告點擊將包含 IDFA(廣告主ID):
接下來,用戶安裝您的 app。此安裝事件無法歸于廣告點擊次數,因為用戶尚未授權 ATT,這意味著歸因數據將“不全面”,并上報為未歸因:
在這種情況下,用戶會在安裝后立即授權 ATT,然后再進行其他 app 內活動。授權會觸發(fā)“二次安裝”,可將其歸因于廣告點擊次數:
此后用戶進行倒漏斗轉化(例如購買)時,該轉化也可以歸因于廣告點擊:
現在,假設用戶隨后單擊了另一個 Branch 鏈接,例如電子郵件鏈接。值得一提的是,在這種情況下,即使用戶已經授權 ATT 也沒必要,因為根據 Apple 的政策,從技術層面上看,您的電子郵件是自有渠道:
點擊電子郵件后,所有的轉化事件自然都將歸因于電子郵件廣告活動,而不是廣告點擊。這與 iOS 14 之前的情況是一樣的:
總而言之,在這種情況下,首次安裝事件將被報告為未歸因或自然。用戶授權 ATT 時觸發(fā)的“二次安裝”將正確歸因于廣告點擊。
在另一個符合條件的鏈接被點擊之前,購買之類的轉化事件將歸因于廣告點擊,點擊另一鏈接后才歸因于該后續(xù)事件:
Install is unattributed/ Organic.
Second install is attributed to Ad Click.
Purchase 1 is attributed to Ad Click.
Purchase 2 is attributed to Email Click.
# 延遲授權流程 #
現在,我們來看一個稍微復雜點的例子。在這種情況下,用戶點擊廣告,安裝,但一開始沒有授權 ATT,直到安裝后過了一段時間才授權。如果您決定直到向用戶展示價值后再顯示 ATT 提示,從而更多用戶可能會授權,那就可能會發(fā)生這種情況。
和之前一樣,此流程假設用戶已經授權了發(fā)布者 app 中的 ATT, 交易第一端有了 IDFA(廣告主ID):
由于用戶先前授權了 ATT,因此他們在發(fā)布商 app 中的廣告點擊將包含 IDFA(廣告主ID):
但在這種情況下,用戶不會立即授權 ATT。這意味著用戶的早期倒漏斗轉化事件也將被報告為未歸因:
用戶最終選擇授權時將觸發(fā)“二次安裝”,并將正確歸因于廣告點擊次數:
授權后,隨后的轉化事件也將正確歸因于廣告點擊:
總而言之,這種情況下的首次安裝事件將被報告為未歸因。并且直到用戶授權 ATT 之前,轉化事件都將報告為未歸因。
用戶授權 ATT 后,將觸發(fā)二次安裝,并將正確歸因于廣告點擊。之后的轉化事件也將正確歸因于廣告點擊。
Install is unattributed/ Organic.
Purchase 1 is unattributed/ Organic.
Second install is attributed to Ad Click.
Purchase 2 is attributed to Ad Click.
# Branch 產品變化 #
我們已經看了一些示例用戶流,讓我們看一下整個 Branch 平臺如何更新以反映原始數據。更新可分為兩大類:
1. 預匯總的報告。由于此數據是在瀏覽或請求時生成的,因此當用戶在安裝后相繼授權時,Branch 可以動態(tài)地“修復”數據。這些產品包括:
Branch 操作后臺。
查詢 API。
2. 原始數據產品。這會返回日志級別的事件數據,Branch 將不會追溯重寫這些數據。但根據您的用例,您可以選擇自己執(zhí)行數據去重。我們將在本文后半部分描述執(zhí)行此操作的邏輯。我們的原始數據產品包括:
Webhooks。
廣告平臺回傳。
自定義 export API。
數據集成。
# Branch 操作后臺+查詢 API “剛剛好能解決問題”#
好消息是,如果您像我們的許多客戶一樣,主要依靠 Branch 操作后臺和我們的查詢 API 運作,那這兩項結合“剛剛好能解決問題”,您無需采取任何其他步驟。這意味著我們將自動對首次和二次安裝事件進行數據去重,從而保證在用戶授權后,最終數字仍是準確的:
我們會自動對首次安裝后,最多7天內發(fā)生的“二次安裝”事件進行數據去重。對發(fā)生在此窗口之外的二次安裝不會進行數據去重。
需要提醒的是,如果付費廣告驅動的用戶從未授權,則他們將不會產生二次安裝數據。因此,我們將無法從未歸因的數據中刪除相關數據。
# “自然復選框” #
Branch 操作后臺的另一個功能值得特別一提:“自然復選框”。
默認情況下,Branch 操作后臺上的大多數報告僅顯示歸因數據。這是有道理的,因為如果您正在查看有關廣告活動效果之類的報告,通常只希望查看歸因于廣告活動的轉化。
過去,選中“自然”復選框后,報告將顯示單獨細分的未歸因 (或“自然”) 轉化:
iOS 14.5 發(fā)布后,此功能將無法正常運行,因為該未歸因的部分里會包含付費廣告轉化,而用戶授權 ATT 尚未全部完成:
這意味著“自然”復選框在許多報告中沒有什么用,因此我們在某些操作后臺頁面上刪除了自然”復選框,以免造成混淆。
自然復選框將在何處被刪除:
摘要頁面
Journeys(網站向 App 引流解決方案)標簽
快速鏈接標簽
Universal Email(通用電子郵件)標簽
Journeys (網站向 App 引流解決方案)→ 活動標簽 (Activity tab)
電子郵件→ 活動標簽
自然復選框在何處仍被保留:
摘要頁面
所有數據標簽
Universal Ads(通用廣告)標簽
廣告分析→活動標簽
大多數客戶會使用“自然”復選框來將廣告活動效果與非廣告活動基準作比較。作為替代方案,我們將在操作后臺報告中添加一個名為“顯示 app 總流量”的新復選框。報告中會附加展示所有流量 (歸因和未歸因) ,為效果比較提供相似的基準。
# 原始數據產品 #
有了這些變化后,需要注意數據架構更新:
首次安裝和二次安裝事件均會報告為安裝,并且每個事件上都有兩個新字段:user_data_opted_in 和 days_from_install_to_opt_in 。
user_data_opted_in 字段反映用戶授權 ATT 的狀態(tài),首次安裝為 false,二次安裝為 true。days_from_install_to_opt_in 字段反映首次和二次安裝事件之間間隔的天數。
timestamp 字段反映各事件發(fā)生的時間 (首次安裝是安裝本身返回系統(tǒng)的時間;二次安裝是用戶授權的時間)。此外,二次安裝中的 event_timestamp 字段反映了相對應的首次安裝發(fā)生于何時。
下表展示了廣告驅動安裝的流程,按 Branch 產品細分:
# 您需要做什么 #
若您僅使用Branch后臺
那么事情就非常簡單了:您無需做任何事,只需注意,隨著更多用戶授權 app 追蹤,您的報表數據可能每天都會略有變化
若您使用查詢API提取預先匯總的數據
則需要明白,如果查詢時用戶尚未授權,則您報告里的歸因數據可能不全面。為解決這個問題,如果用戶在初次請求后可能授權的話,則應從前幾天開始重新拉取數據。
例如:如果是4月15日,并且您在4月1日至14日調用查詢 API,但您的 app 可能會在安裝之后最多6天才向用戶顯示 ATT 提示,建議您在4月21日再次提取數據,以便獲得“最終版”數字。
若您使用自定義 export API
則需要注意的是,如果返回二次安裝記錄,則您數據中的某個位置已經包含該用戶不全面 (也就是未歸因或“自然”) 的首次安裝的數據。您可以使用下述的數據去重邏輯來解決此問題。
您還應提取安裝后七天內的數據。這是因為 Branch 在7天后會在原始數據中對設備標識符進行哈希處理。
若您使用Webhook
我們建議在 Webhook 正文中包含 IDFV 字段,因為某些 IDFA(廣告主ID)無法獲取。您還可以選擇實現下述數據去重邏輯。
對于廣告合作伙伴回傳和數據記成
如果設置為僅發(fā)送歸因事件,則無需做任何更改。如果配置為發(fā)送所有事件,則需要與合作伙伴一起決定轉發(fā)路徑。
若想單獨捕獲ATT授權和拒絕作為分析事件
請將 Branch iOS SDK 集成更新到 v1.4 或更高版本。如果您不想衡量這些專門的分析事件,而只需要“二次安裝”追蹤,那么此時就不需要更新 SDK。
# 如何刪除首次安裝和二次安裝的重復數據 #
Branch 操作后臺和查詢 API 將自動刪除重復事件,從而持續(xù)提供準確報告。但如果您使用我們的原始數據產品 (包括 webhook、數據集成、自定義 export API,或廣告平臺回傳發(fā)送所有事件,而不僅僅是歸因安裝),那您可能需要更新系統(tǒng)。
為此,您應該在 API pull 或 webhook 中引用 event_timestamp 字段和其他設備標識符 (例如 IDFV)。對兩個事件來說,這兩個字段都一樣,您可以用相應的“二次安裝”覆蓋未歸因的“安裝”。
您還可以選擇使用 IDFV 來重新分配首次安裝和二次安裝之間的所有倒漏斗事件。