iOS專題|iOS14.5上Branch廣告分析的變化

iOS 14.5 及更高版本的發(fā)布，也意味著 iOS 移動(dòng)營銷面臨顛覆。為更好地服務(wù) Branch 用戶，本圖文將詳細(xì)闡述，這一變化如何影響您的 Branch 數(shù)據(jù)，以及要對(duì) Branch App 的配置進(jìn)行哪些更新。

我們先來理清今天討論的內(nèi)容會(huì)帶來什么大的影響：

• 左側(cè)展示了到目前為止您 Branch 歸因數(shù)據(jù)的樣子：單個(gè)合并數(shù)據(jù)集，其轉(zhuǎn)化記錄在所有渠道上均已去重。和任何歸因系統(tǒng)一樣，總會(huì)有一堆“未知”的轉(zhuǎn)化。該存儲(chǔ)桶有時(shí)也稱為“自然”或“未歸因”，但所有這些術(shù)語含義都相同：系統(tǒng)轉(zhuǎn)化未歸因于任何市場營銷活動(dòng)。

• 右側(cè)展示了在執(zhí)行 Apple 的新 iOS 14 隱私政策后，您 Branch 數(shù)據(jù)的樣子：在您慣?？吹降膯蝹€(gè)合并報(bào)告中，之前歸因于廣告渠道的所有轉(zhuǎn)化現(xiàn)在都將顯示為“未知”。通過 Apple 的新 SKAdNetwork 框架，您的廣告將會(huì)有一個(gè)單獨(dú)的歸因數(shù)據(jù)池。

由于 SKAdNetwork 的設(shè)計(jì)，只有當(dāng)前某些常見廣告活動(dòng)類型能提供該廣告數(shù)據(jù)。因?yàn)椴皇窃O(shè)備級(jí)別的數(shù)據(jù)，所以比往常的粒度要少得多，并且不能與任何其他營銷渠道進(jìn)行數(shù)據(jù)去重。

好在還有辦法可以在合并的去重報(bào)表中贏回一些細(xì)粒度的設(shè)備級(jí)廣告數(shù)據(jù)：您可以通過 Apple 的新 ATT 框架讓用戶授權(quán)：

我們從一開始就應(yīng)該明白：沒有一勞永逸的解決方案，一切不可能維持原樣。從 MMP 到廣告平臺(tái)，從發(fā)行商再到像類似您的廣告商，生態(tài)系統(tǒng)中的每個(gè)人都必須清楚如何應(yīng)對(duì) Apple 的變化。

iOS 14.5 發(fā)布后，iOS 廣告歸因?qū)⒏鼮閺?fù)雜。本文將介紹 Branch 產(chǎn)品更新，這些更新旨在幫您解決問題。

#您的 Branch 數(shù)據(jù)將如何變化#

我們從一個(gè)簡單的流程圖開始，該流程圖說明了哪些 Branch 客戶將受到這些變化影響： 

如果您正在使用 Branch 進(jìn)行廣告歸因，并計(jì)劃向用戶展示 ATT 提示，則這些產(chǎn)品變化會(huì)影響您。

為什么 Branch 需要更新？最關(guān)鍵的是，ATT 授權(quán)過程會(huì)帶來時(shí)間上的問題。這里是一個(gè)典型的用戶轉(zhuǎn)化過程：單擊廣告，從 App 商店下載該 app，然后打開該 app。到目前為止都不難。

接下來才會(huì)遇到問題：首次打開 app 后，Branch SDK 會(huì)被觸發(fā)，接著就該進(jìn)行安裝歸因了……但您還沒向用戶展示 ATT 授權(quán)申請(qǐng)：

在時(shí)間上會(huì)存在問題：在您獲得授權(quán)之前 (可能用戶在首次打開 app 后的某個(gè)時(shí)間才會(huì)授權(quán))，您將不會(huì)獲得 IDFA（廣告主ID），也無權(quán)歸因設(shè)備級(jí)廣告轉(zhuǎn)化。

Branch 正在研發(fā)的分析產(chǎn)品變化旨在幫助找回此流程中安裝相關(guān)的廣告歸因。我們構(gòu)建的解決方案反映了一些重要的需求，值得展開談?wù)劊?/p>

1. 新方式必須完全遵守 Apple 的 ATT 政策。我們聽說其他一些 MMP 計(jì)劃通過概率匹配在后臺(tái)“作弊”，即使沒有用戶 ATT 授權(quán)也仍舊這么做。我們認(rèn)為 Apple 會(huì)嚴(yán)厲打擊這種行為，并且我們非常重視要確?？蛻舨粫?huì)因違反政策而被 App 商店禁止。

2. Branch 不得通過更改已報(bào)告的事件來“重寫歷史記錄”。追溯數(shù)據(jù)更新會(huì)帶來問題，并使您的工作流程更加復(fù)雜。

3. Branch SDK 仍需要在 App 被首次打開時(shí)觸發(fā)。自有和自然渠道的深度鏈接和歸因都依賴于此，而這兩種渠道均不受 Apple ATT 政策的影響。

您可能還在了解這些新的復(fù)雜情況，并在思考“努力讓我的用戶授權(quán) ATT 是否值得？”

Branch 認(rèn)為，在大多數(shù)情況下是值得的。Apple 所做的更改將降低您對(duì)廣告歸因的了解。這是不可避免的，并且是移動(dòng)生態(tài)系統(tǒng)中每個(gè)廣告客戶都需要應(yīng)對(duì)的令人不快的現(xiàn)實(shí)。

您仍有兩個(gè)選擇：擁有一些 數(shù)據(jù)或什么數(shù)據(jù)也沒有。即使是有限的設(shè)備級(jí)信息，也仍然可以幫助您在廣告活動(dòng)優(yōu)化和客戶終生價(jià)值 (LTV) 等方面更好地做決策。

# 新數(shù)據(jù)流示例 #

簡而言之，這是我們所做的改變。

首先，我們正在做什么

• 我們?cè)谧粉櫫硪粋€(gè)分析事件，我們將其稱之為“二次安裝”。處理二次安裝與處理普通安裝方式相同，二次安裝時(shí)還會(huì)產(chǎn)生數(shù)據(jù)參數(shù)，從而可以進(jìn)行數(shù)據(jù)去重。用戶授權(quán) ATT 之后，二次安裝將觸發(fā)廣告驅(qū)動(dòng)的安裝。此更改將為 Branch iOS SDK 所有版本自動(dòng)更新，并且您不需要更新 SDK。

• 另外，雖然不強(qiáng)制，您也可以更新至 iOS SDK v1.39.2 +，從而可以將授權(quán)或拒絕 ATT 視為新的專門事件進(jìn)行捕捉，并上報(bào)所有事件發(fā)生時(shí) ATT 的狀態(tài)。

現(xiàn)在，我們不會(huì)做的是

• 如果用戶未授權(quán) ATT，我們便不會(huì)對(duì)廣告驅(qū)動(dòng)的安裝進(jìn)行任何形式的設(shè)備級(jí)歸因。同樣，這是為了確保我們遵守 Apple 的政策，并保護(hù)您。

• 用戶授權(quán)后，我們也不會(huì)在首次安裝事件上重寫任何日志級(jí)別的數(shù)據(jù)。這是為了讓您的數(shù)據(jù)工作流更簡化和可預(yù)測。

• 最后，我們不會(huì)為非付費(fèi)來源的授權(quán)觸發(fā)“二次安裝”，因?yàn)樵谶@種情況下，我們已經(jīng)能在用戶未授權(quán) ATT 的情況下進(jìn)行設(shè)備級(jí)歸因了。

通過實(shí)踐示例，我們能更好地了解背后的原理。這些示例演示了 iOS 14.5 及更高版本上您 Branch 數(shù)據(jù)的情況。

# 立即授權(quán)流程 #

第一個(gè)示例展示了最簡單的流程：用戶點(diǎn)擊廣告鏈接，安裝您的 app 并在安裝后立即授權(quán) ATT。在此流程中，假定用戶已經(jīng)授權(quán)了發(fā)布者 app 中的 ATT，也因此能在交易第一端獲取 IDFA（廣告主ID）：

由于用戶先前授權(quán)了 ATT，因此他們?cè)诎l(fā)布商 app 中的廣告點(diǎn)擊將包含 IDFA（廣告主ID）：

接下來，用戶安裝您的 app。此安裝事件無法歸于廣告點(diǎn)擊次數(shù)，因?yàn)橛脩羯形词跈?quán) ATT，這意味著歸因數(shù)據(jù)將“不全面”，并上報(bào)為未歸因：

在這種情況下，用戶會(huì)在安裝后立即授權(quán) ATT，然后再進(jìn)行其他 app 內(nèi)活動(dòng)。授權(quán)會(huì)觸發(fā)“二次安裝”，可將其歸因于廣告點(diǎn)擊次數(shù)：

此后用戶進(jìn)行倒漏斗轉(zhuǎn)化（例如購買）時(shí)，該轉(zhuǎn)化也可以歸因于廣告點(diǎn)擊：

現(xiàn)在，假設(shè)用戶隨后單擊了另一個(gè) Branch 鏈接，例如電子郵件鏈接。值得一提的是，在這種情況下，即使用戶已經(jīng)授權(quán) ATT 也沒必要，因?yàn)楦鶕?jù) Apple 的政策，從技術(shù)層面上看，您的電子郵件是自有渠道：

點(diǎn)擊電子郵件后，所有的轉(zhuǎn)化事件自然都將歸因于電子郵件廣告活動(dòng)，而不是廣告點(diǎn)擊。這與 iOS 14 之前的情況是一樣的：

總而言之，在這種情況下，首次安裝事件將被報(bào)告為未歸因或自然。用戶授權(quán) ATT 時(shí)觸發(fā)的“二次安裝”將正確歸因于廣告點(diǎn)擊。

在另一個(gè)符合條件的鏈接被點(diǎn)擊之前，購買之類的轉(zhuǎn)化事件將歸因于廣告點(diǎn)擊，點(diǎn)擊另一鏈接后才歸因于該后續(xù)事件：

1. Install is unattributed/ Organic.
   

2. Second install is attributed to Ad Click.

3. Purchase 1 is attributed to Ad Click.
   

4. Purchase 2 is attributed to Email Click.

# 延遲授權(quán)流程 #

現(xiàn)在，我們來看一個(gè)稍微復(fù)雜點(diǎn)的例子。在這種情況下，用戶點(diǎn)擊廣告，安裝，但一開始沒有授權(quán) ATT，直到安裝后過了一段時(shí)間才授權(quán)。如果您決定直到向用戶展示價(jià)值后再顯示 ATT 提示，從而更多用戶可能會(huì)授權(quán)，那就可能會(huì)發(fā)生這種情況。

和之前一樣，此流程假設(shè)用戶已經(jīng)授權(quán)了發(fā)布者 app 中的 ATT， 交易第一端有了 IDFA（廣告主ID）：

由于用戶先前授權(quán)了 ATT，因此他們?cè)诎l(fā)布商 app 中的廣告點(diǎn)擊將包含 IDFA（廣告主ID）：

但在這種情況下，用戶不會(huì)立即授權(quán) ATT。這意味著用戶的早期倒漏斗轉(zhuǎn)化事件也將被報(bào)告為未歸因：

用戶最終選擇授權(quán)時(shí)將觸發(fā)“二次安裝”，并將正確歸因于廣告點(diǎn)擊次數(shù)：

授權(quán)后，隨后的轉(zhuǎn)化事件也將正確歸因于廣告點(diǎn)擊：

總而言之，這種情況下的首次安裝事件將被報(bào)告為未歸因。并且直到用戶授權(quán) ATT 之前，轉(zhuǎn)化事件都將報(bào)告為未歸因。

用戶授權(quán) ATT 后，將觸發(fā)二次安裝，并將正確歸因于廣告點(diǎn)擊。之后的轉(zhuǎn)化事件也將正確歸因于廣告點(diǎn)擊。

1. Install is unattributed/ Organic.
   

2. Purchase 1 is unattributed/ Organic.

3. Second install is attributed to Ad Click.

4. Purchase 2 is attributed to Ad Click.

# Branch 產(chǎn)品變化 #

我們已經(jīng)看了一些示例用戶流，讓我們看一下整個(gè) Branch 平臺(tái)如何更新以反映原始數(shù)據(jù)。更新可分為兩大類：

1. 預(yù)匯總的報(bào)告。由于此數(shù)據(jù)是在瀏覽或請(qǐng)求時(shí)生成的，因此當(dāng)用戶在安裝后相繼授權(quán)時(shí)，Branch 可以動(dòng)態(tài)地“修復(fù)”數(shù)據(jù)。這些產(chǎn)品包括：

• Branch 操作后臺(tái)。

• 查詢 API。

2. 原始數(shù)據(jù)產(chǎn)品。這會(huì)返回日志級(jí)別的事件數(shù)據(jù)，Branch 將不會(huì)追溯重寫這些數(shù)據(jù)。但根據(jù)您的用例，您可以選擇自己執(zhí)行數(shù)據(jù)去重。我們將在本文后半部分描述執(zhí)行此操作的邏輯。我們的原始數(shù)據(jù)產(chǎn)品包括：

• Webhooks。

• 廣告平臺(tái)回傳。

• 自定義 export API。

• 數(shù)據(jù)集成。

# Branch 操作后臺(tái)+查詢 API “剛剛好能解決問題”#

好消息是，如果您像我們的許多客戶一樣，主要依靠 Branch 操作后臺(tái)和我們的查詢 API 運(yùn)作，那這兩項(xiàng)結(jié)合“剛剛好能解決問題”，您無需采取任何其他步驟。這意味著我們將自動(dòng)對(duì)首次和二次安裝事件進(jìn)行數(shù)據(jù)去重，從而保證在用戶授權(quán)后，最終數(shù)字仍是準(zhǔn)確的：

我們會(huì)自動(dòng)對(duì)首次安裝后，最多7天內(nèi)發(fā)生的“二次安裝”事件進(jìn)行數(shù)據(jù)去重。對(duì)發(fā)生在此窗口之外的二次安裝不會(huì)進(jìn)行數(shù)據(jù)去重。

需要提醒的是，如果付費(fèi)廣告驅(qū)動(dòng)的用戶從未授權(quán)，則他們將不會(huì)產(chǎn)生二次安裝數(shù)據(jù)。因此，我們將無法從未歸因的數(shù)據(jù)中刪除相關(guān)數(shù)據(jù)。

# “自然復(fù)選框” #

Branch 操作后臺(tái)的另一個(gè)功能值得特別一提：“自然復(fù)選框”。

默認(rèn)情況下，Branch 操作后臺(tái)上的大多數(shù)報(bào)告僅顯示歸因數(shù)據(jù)。這是有道理的，因?yàn)槿绻诓榭从嘘P(guān)廣告活動(dòng)效果之類的報(bào)告，通常只希望查看歸因于廣告活動(dòng)的轉(zhuǎn)化。

過去，選中“自然”復(fù)選框后，報(bào)告將顯示單獨(dú)細(xì)分的未歸因 (或“自然”) 轉(zhuǎn)化：

iOS 14.5 發(fā)布后，此功能將無法正常運(yùn)行，因?yàn)樵撐礆w因的部分里會(huì)包含付費(fèi)廣告轉(zhuǎn)化，而用戶授權(quán) ATT 尚未全部完成：

這意味著“自然”復(fù)選框在許多報(bào)告中沒有什么用，因此我們?cè)谀承┎僮骱笈_(tái)頁面上刪除了自然”復(fù)選框，以免造成混淆。

自然復(fù)選框?qū)⒃诤翁幈粍h除：

• 摘要頁面

• Journeys（網(wǎng)站向 App 引流解決方案）標(biāo)簽

• 快速鏈接標(biāo)簽

• Universal Email（通用電子郵件）標(biāo)簽

• Journeys (網(wǎng)站向 App 引流解決方案）→ 活動(dòng)標(biāo)簽 (Activity tab)

• 電子郵件→ 活動(dòng)標(biāo)簽

自然復(fù)選框在何處仍被保留：

• 摘要頁面

• 所有數(shù)據(jù)標(biāo)簽

• Universal Ads（通用廣告）標(biāo)簽

• 廣告分析→活動(dòng)標(biāo)簽

大多數(shù)客戶會(huì)使用“自然”復(fù)選框來將廣告活動(dòng)效果與非廣告活動(dòng)基準(zhǔn)作比較。作為替代方案，我們將在操作后臺(tái)報(bào)告中添加一個(gè)名為“顯示 app 總流量”的新復(fù)選框。報(bào)告中會(huì)附加展示所有流量 (歸因和未歸因) ，為效果比較提供相似的基準(zhǔn)。

# 原始數(shù)據(jù)產(chǎn)品 #

有了這些變化后，需要注意數(shù)據(jù)架構(gòu)更新：

首次安裝和二次安裝事件均會(huì)報(bào)告為安裝，并且每個(gè)事件上都有兩個(gè)新字段：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ā)生的時(shí)間 (首次安裝是安裝本身返回系統(tǒng)的時(shí)間；二次安裝是用戶授權(quán)的時(shí)間)。此外，二次安裝中的 event_timestamp 字段反映了相對(duì)應(yīng)的首次安裝發(fā)生于何時(shí)。

下表展示了廣告驅(qū)動(dòng)安裝的流程，按 Branch 產(chǎn)品細(xì)分：

# 您需要做什么 #

 若您僅使用Branch后臺(tái)

那么事情就非常簡單了：您無需做任何事，只需注意，隨著更多用戶授權(quán) app 追蹤，您的報(bào)表數(shù)據(jù)可能每天都會(huì)略有變化

若您使用查詢API提取預(yù)先匯總的數(shù)據(jù)

則需要明白，如果查詢時(shí)用戶尚未授權(quán)，則您報(bào)告里的歸因數(shù)據(jù)可能不全面。為解決這個(gè)問題，如果用戶在初次請(qǐng)求后可能授權(quán)的話，則應(yīng)從前幾天開始重新拉取數(shù)據(jù)。

例如：如果是4月15日，并且您在4月1日至14日調(diào)用查詢 API，但您的 app 可能會(huì)在安裝之后最多6天才向用戶顯示 ATT 提示，建議您在4月21日再次提取數(shù)據(jù)，以便獲得“最終版”數(shù)字。

若您使用自定義 export API

則需要注意的是，如果返回二次安裝記錄，則您數(shù)據(jù)中的某個(gè)位置已經(jīng)包含該用戶不全面 (也就是未歸因或“自然”) 的首次安裝的數(shù)據(jù)。您可以使用下述的數(shù)據(jù)去重邏輯來解決此問題。

您還應(yīng)提取安裝后七天內(nèi)的數(shù)據(jù)。這是因?yàn)?Branch 在7天后會(huì)在原始數(shù)據(jù)中對(duì)設(shè)備標(biāo)識(shí)符進(jìn)行哈希處理。

若您使用Webhook

我們建議在 Webhook 正文中包含 IDFV 字段，因?yàn)槟承?IDFA（廣告主ID）無法獲取。您還可以選擇實(shí)現(xiàn)下述數(shù)據(jù)去重邏輯。

對(duì)于廣告合作伙伴回傳和數(shù)據(jù)記成

如果設(shè)置為僅發(fā)送歸因事件，則無需做任何更改。如果配置為發(fā)送所有事件，則需要與合作伙伴一起決定轉(zhuǎn)發(fā)路徑。

若想單獨(dú)捕獲ATT授權(quán)和拒絕作為分析事件

請(qǐng)將 Branch iOS SDK 集成更新到 v1.4 或更高版本。如果您不想衡量這些專門的分析事件，而只需要“二次安裝”追蹤，那么此時(shí)就不需要更新 SDK。

# 如何刪除首次安裝和二次安裝的重復(fù)數(shù)據(jù) #

Branch 操作后臺(tái)和查詢 API 將自動(dòng)刪除重復(fù)事件，從而持續(xù)提供準(zhǔn)確報(bào)告。但如果您使用我們的原始數(shù)據(jù)產(chǎn)品 (包括 webhook、數(shù)據(jù)集成、自定義 export API，或廣告平臺(tái)回傳發(fā)送所有事件，而不僅僅是歸因安裝)，那您可能需要更新系統(tǒng)。

為此，您應(yīng)該在 API pull 或 webhook 中引用  event_timestamp 字段和其他設(shè)備標(biāo)識(shí)符 (例如 IDFV)。對(duì)兩個(gè)事件來說，這兩個(gè)字段都一樣，您可以用相應(yīng)的“二次安裝”覆蓋未歸因的“安裝”。

您還可以選擇使用 IDFV 來重新分配首次安裝和二次安裝之間的所有倒漏斗事件。