干貨長文｜單一來源iOS14.5+歸因的真相：犧牲一個比特位的代價

對于移動營銷人員和廣告主來說，當前iOS14.5+端的監(jiān)測工作變得愈發(fā)復雜了。自2020年4月Apple宣布更新以來，為幫助客戶化繁為簡，各大移動監(jiān)測合作伙伴(MMP)和數(shù)據(jù)分析平臺都在緊鑼密鼓地研發(fā)解決方案。在擁抱各種變化的同時，Adjust也在努力打造新一代解決方案，幫助客戶在保護數(shù)據(jù)隱私的前提下推動增長。

我們的解決方案通過參考設備層級和SKAdNetwork(SKAN)數(shù)據(jù)，以高精準度的列表形式打造綜合報告。而市面上的另一些解決方案則采用了"一體化"或"單一來源"的方法。從本質上講，這種方法試圖估算通過SKAN框架歸因的安裝與通過App Tracking Transparency(ATT)框架歸因的安裝之間的重疊部分。這在理論上看似可行，但實際上存在重大缺陷，最重要的是，這種方法要占用整整一個比特位。?

01 一體化iOS推廣活動數(shù)據(jù)的缺陷

從理論上來說，通過估算SKAN和ATT之間的重疊安裝，就能夠看到哪些SKAN安裝已經(jīng)被ATT框架歸因了。也就是說，營銷人員可以從聚合層面上確認SKAN安裝總量=付費MMP安裝總量，從而確認兩個數(shù)據(jù)集之間的意外偏差。然而，這種排錯式流程缺乏必要的后續(xù)步驟，相當于您浪費了一個寶貴的比特位來證明數(shù)字不匹配。

02 舉例說明

1.第一個例子中，一些營銷人員會對數(shù)據(jù)抱有不切實際的希望：

時間范圍：2022年7月

MMP付費安裝：80,000

MMP自然安裝：40,000

SKAN安裝：100,000；使用比特值查看歸因狀態(tài)，有80,000次安裝返回"1"，即已經(jīng)歸因

“看到這些數(shù)字，UA經(jīng)理可能會認為所有SKAN安裝都已歸因，MMP的付費安裝數(shù)量相同，所報告的數(shù)字也沒有錯誤。但事實并非如此！”

從整體層面來看，這些數(shù)字的確對得上，但讓我們更進一步仔細檢查。假設在80,000次SKAN已歸因安裝中，有40,000次歸因給了Facebook，另外40,000次歸因至Google，推廣活動信息很少；而MMP數(shù)據(jù)顯示，F(xiàn)acebook、Google和AppLovin分別獲得了20,000次安裝歸因，還有20,000次被歸因給了某次網(wǎng)頁推廣活動(注意：當前無法通過SKAN開展網(wǎng)頁推廣活動)。雖然總量匹配，但獲得歸因的合作伙伴卻不一樣。

當然，您可以通過MMP交叉檢查歸因窗口，但因為SKAN窗口不可見，所以您無法正確比較不同數(shù)據(jù)集?？倲?shù)匹配并不意味著您離單一真實數(shù)據(jù)來源更近了一步。??

2.在第二個更常見的例子中，營銷人員則被帶入了死胡同：

時間范圍：2022年7月

MMP付費安裝：80,000

MMP自然安裝：40,000

SKAN安裝：60,000；使用比特值查看歸因狀態(tài)，有40,000次安裝返回"1"，即已經(jīng)歸因

UA經(jīng)理看到，MMP的付費安裝中僅有一半體現(xiàn)在了SKAN安裝總量中。下一步，UA經(jīng)理可以檢查"缺失"的40,000次安裝是否來自SKAN不支持的推廣活動，例如網(wǎng)頁、電子郵件、網(wǎng)絡紅人推廣等。假設MMP將50,000次安裝歸因給了各類網(wǎng)頁推廣活動，20,000次給了Google，10,000次給了Facebook。SKAN安裝被歸因至Google和Facebook，即分別為30,000。

那么應該如何統(tǒng)一這些數(shù)字呢？

SKAN缺失的40,000次安裝與來自網(wǎng)頁推廣活動的50,000次安裝不匹配。此外，SKAN和MMP的Google和Facebook歸因數(shù)字為何存在如此大的不同？從理論上來說，您可以深入了解MMP方面的歸因情況，但在SKAN中就做不到了。換言之，到此，您就走進了"死胡同"。?

“理論上說，從單一來源可以推算出的效果KPI有整體eCPI*、*CPE和ROAS，但由于數(shù)據(jù)準確性方面的固有局限性，我們非常不建議根據(jù)預估表現(xiàn)的計算結果優(yōu)化推廣活動(如暫停、終止或擴大推廣活動)。對于準確性方面的局限性，我們會在下文詳細說明?！?/p>

簡言之，單一來源模型能夠從高層面預估來自SKAN和ATT框架的iOS安裝總量，但需要付出1個比特位的代價。

03 比特位邏輯詳解

在單一來源模型中，第6個(即最高的)比特位會被指定為TRUE/FALSE標記。這也就意味著，在可用于事件映射和/或收入范圍條件的63個轉化值中，有一半不可用。用二進制形式表示如下：

每個比特位的值可以是0或1。在第一種情況下，比特值范圍為000000-111111，即十進制的0-63。也就是說，所有63個轉化值都可用于條件映射。但在第二種情況下，比特值范圍只有00000-11111，即十進制的0-31，第6個比特位變成了TRUE或1。也就是說，映射到轉化值1至31的任何事件條件都會假定沒有發(fā)生ATT歸因；類似地，映射到轉化值32-63的任何事件條件都會假定已經(jīng)發(fā)生ATT歸因。用一個比特位標記ATT歸因，設備發(fā)送的轉化值就會包含一個TRUE或FALSE，翻譯成二進制即1或0。

出于上述考慮，您就需要在轉化值方案中重復映射兩遍相同的事件條件(轉化值1-31一次，32-63再一次)，以覆蓋ATT歸因發(fā)生和未發(fā)生兩種情況。最重要的是，您花費了一半的轉化值，僅僅為了使SKAN回調中包含一個專門的轉化值，以此了解SKAN安裝是否已被ATT框架歸因。

注意，與ATT框架不同，該回調中不會顯示獲得歸因的合作伙伴。從理論上來說，您可以通過回調接收合作伙伴信息，但這需要使用更多的比特位來編入這些信息，將比特全部用完也不一定夠。

要讓這種方法站住腳，獲得"一體化"或"單一來源"數(shù)據(jù)集，就需要用到下列計算方法：

安裝總量=ATT付費安裝+ATT自然安裝+SKAN付費安裝(無ATT標記)

這個公式假定在給定時間范圍內，(帶有ATT標記的)SKAN付費安裝數(shù)量與ATT付費安裝數(shù)量相同，這是錯誤的。?

04 估算過多帶來的風險

在一個以"精準度"為支柱的生態(tài)中，單一來源等模型太過依賴估算。下面，讓我們分別列出此類模型的四個關鍵估算過程，逐一解釋其內在問題。

1.不同和未知的估算模型：安裝總量計算方法本身會假定帶有ATT標記的SKAN歸因付費安裝數(shù)量與ATT框架中歸因的付費安裝總量相同。從我們的經(jīng)驗來看，這種假定是錯誤的，原因包括以下幾點：

您的合作伙伴需要同時支持SKAN和ATT框架，數(shù)據(jù)才能匹配。但當前網(wǎng)絡紅人(influencer)和網(wǎng)頁流量無法同時支持這兩個框架。

由于未得到用戶許可，SAN可能無法在ATT框架中認領安裝。但在SKAN框架中，無論用戶是否授權，歸因都會發(fā)生，因此，同樣一部分用戶很可能會在SKAN框架中被歸因給SAN。

來自SKAN框架的交互信息有限，歸因瀑布也不夠清晰，因此，您無從得知安裝是如何歸因給特定合作伙伴的。SKAN與ATT的歸因窗口不同。

2.不同框架中的合作伙伴歸因：單一來源模型計算方法假定，如果SKAN已經(jīng)將某次安裝歸因給了特定合作伙伴，那么MMP也進行了同樣的歸因。我們已經(jīng)在上文中提到，用于確認安裝是否通過ATT框架歸因的比特值并不包含合作伙伴來源信息。我們無法驗證此信息的真?zhèn)?，因此不能?jù)此開展營銷。

當然，從總量上來看，您可以認為兩個框架的安裝數(shù)量可以相互彌補，但前提是兩個框架中的合作伙伴完全相同。這也就意味著，如果出現(xiàn)不同的合作伙伴，那么問題就會變得更加復雜?？紤]到SKAN的運作原理，上述情況并不少見。

在ATT框架中，廣告主只能開展內部營銷活動，如交叉推廣、電子郵件營銷、網(wǎng)絡紅人和移動網(wǎng)頁推廣活動等。但是，在單一來源模型中，這些安裝會帶有"TRUE"歸因標記。假設由于廣告位重疊，SKAN會將同樣的設備歸因到某個廣告渠道中，那么這些安裝就會被計入帶ATT標記的SKAN安裝。換言之，您不能認為ATT付費安裝=SKAN付費安裝(帶ATT標記)，否則，任何基于此邏輯的總體eCPI或ROAS都會有誤差。

3.安裝日期：SKAN回調中并不包含確切的時間戳，因此安裝日期也屬SKAN估算。估算基于所使用的轉化值窗口，以及回調是否包含非0轉化值。但關鍵問題在于Google與其他合作伙伴不同，SKAN時間戳并不代表其收到回調的日期，而是估算的交互日期，而這個交互時間本身已經(jīng)是Google的估算。也就是說，您需要根據(jù)Google估算的交互時間估計SKAN安裝日期，精準度堪憂。

4.隱私閾值(privacy threshold)：由于Apple的隱私閾值，單一來源計算會遇到更多的困難。SKAN發(fā)送給合作伙伴的部分回調包含null轉化值，也就是說，回調中沒有您需要的信息，也無法回答"SKAN安裝是否已在ATT框架中歸因"的問題。

在不同的合作伙伴和推廣活動中，帶null轉化值回調的占比差異很大(~10%-40%)。我們有時并無法了解為什么某個推廣活動null轉化值多，而另一個推廣活動少。只有Apple能準確回答哪些情況達到或未達到隱私閾值。對于SKAN付費安裝(不帶ATT標記)，我們無法借助倍數(shù)因子進行估算，因為隱私閾值的應用方法不夠清晰。與之前提到的一樣，任何計算都只能是"估算"。?

05 構建iOS推廣活動報告

單一來源或"一體化"iOS推廣活動數(shù)據(jù)模型包含太多估算。當前市面上旨在結合SKAN和ATT數(shù)據(jù)的諸多解決方案都建立在多層估算的基礎之上，且會犧牲掉一半的轉化值。占用一個比特位，換來的是不精確也不實用的數(shù)據(jù)——這筆交易并不劃算。

如果您希望獲得質量最高的數(shù)據(jù)來推動增長，就絕不能依賴漏洞百出的粗劣方法，如何分配預算？應該暫停或擴大哪些推廣活動？哪些推廣渠道值得重點關注？進行這一系列重要戰(zhàn)略決策時，精準實用的數(shù)據(jù)都是必不可少的。

考慮到SKAN的種種局限，Adjust推薦您采用我們的數(shù)據(jù)分析解決方案Datascape，在同一處查看所有數(shù)據(jù)。Datascape中的數(shù)據(jù)穩(wěn)扎穩(wěn)打，不走捷徑，用清晰易懂的形式呈現(xiàn)所有數(shù)據(jù)，是真正值得信賴的單一數(shù)據(jù)來源解決方案。借助Datascape的多種SKAN相關KPI，如轉化、收入和事件等，您可以打造綜合全面的SKAN報告，同時查看正常Adjust歸因數(shù)據(jù)。這是確保數(shù)據(jù)準確的最佳方法。

在復雜的iOS生態(tài)中，最有效的監(jiān)測方法是借助機器學習和預測，獲得精準eCPI、CPE和ROAS——這也正是Adjust新一代解決方案的研發(fā)方向。歸根結底，營銷人員的需求很簡單，那就是一款能清晰展示推廣活動收益的工具，并借助這一工具快速做出決策，自信地暫?；驍U大推廣活動。?