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