AppsFlyer：聊聊數(shù)據(jù)差異那些事兒

摘要：不同的第三方數(shù)據(jù)追蹤平臺(tái)數(shù)據(jù)有差異？別慌，可能是對(duì)比方式出現(xiàn)了問題！就讓AppsFlyer幫你一起找到原因吧!

作為全球領(lǐng)先的移動(dòng)歸因與市場分析公司的一員（說到這里自豪自豪的），常常接到小伙伴們咨詢：為什么同樣一個(gè)App，這個(gè)平臺(tái)和那個(gè)平臺(tái)的數(shù)據(jù)對(duì)不上？

首先，作為兩個(gè)不同的系統(tǒng)，如果他們承擔(dān)的職能和角色不同，擁有的數(shù)據(jù)信息不同，邏輯或設(shè)計(jì)不同，都會(huì)導(dǎo)致數(shù)據(jù)差異。所以一定范圍內(nèi)的差異是正常的正常的正常的（重要的事情說三遍）！

什么？你說知道數(shù)據(jù)會(huì)有不同，但差異驚人？！

Wait——在正式進(jìn)行調(diào)查之前，檢查以下幾點(diǎn)，你會(huì)發(fā)現(xiàn)說不定只是對(duì)比方式出了Bug

日期不同

確保兩邊數(shù)據(jù)的樣本周期是完全一致的，這不單單指選擇的日期范圍需要一致，還要注意該日期范圍內(nèi)收集的數(shù)據(jù)是否完整。

舉栗子：有的客戶先在Facebook上推廣App獲得流量，推廣一段時(shí)間后，才關(guān)聯(lián)AppsFlyer，那么AppsFlyer的數(shù)據(jù)與Facebook相比本身就是不完整的，缺失了幾天的數(shù)據(jù)，必然會(huì)出現(xiàn)差異。

數(shù)據(jù)缺失

對(duì)比數(shù)據(jù)時(shí)要確保兩邊的數(shù)據(jù)沒有缺失。

舉栗子：客戶在推廣平臺(tái)上往往會(huì)使用多個(gè)賬戶投放，在統(tǒng)計(jì)數(shù)據(jù)時(shí)可能會(huì)遺漏個(gè)別投放賬戶，從而導(dǎo)致差異。

時(shí)區(qū)差異

不同系統(tǒng)可能會(huì)使用完全不同的時(shí)區(qū)，所以盡量選擇更長的時(shí)間范圍（3到7天），來抵消時(shí)區(qū)造成的差異。

歷史樣本庫差異

我們知道，各個(gè)系統(tǒng)能獲取到的用戶數(shù)據(jù)是不同的，比如Facebook，Google做歸因只以自己系統(tǒng)的用戶庫來進(jìn)行排重處理，那么一個(gè)Facebook的老用戶，點(diǎn)擊Google廣告后產(chǎn)生的再次安裝，必然會(huì)被Google計(jì)算為新安裝，但使用AppsFlyer可以匯集各個(gè)平臺(tái)的數(shù)據(jù)，那么在全平臺(tái)的排重規(guī)則下，再次安裝是不會(huì)計(jì)算為新安裝的。

與這個(gè)邏輯相關(guān)的極端情況是，App本身已經(jīng)積累了不少老用戶，在新版本才集成AF SDK，如果沒有采取用戶錄入，那么老用戶的更新會(huì)被AF計(jì)算為新用戶。

數(shù)據(jù)來源差異

以session舉例，客戶自己BI很有可能是通過用戶登陸，或是通過服務(wù)器收到客戶端發(fā)送的某個(gè)或多個(gè)活動(dòng)來計(jì)算一次session等等，都可能與AppsFlyer的打開事件完全不同。

也常會(huì)有客戶集成了某些其他廣告追蹤的SDK，但初始化位置與AppsFlyer SDK不同，造成比較大的數(shù)據(jù)差異。

所以合理的數(shù)據(jù)對(duì)比需要建立在雙方的計(jì)算邏輯完全清楚的基礎(chǔ)之上。

樣本庫差異

舉栗子：應(yīng)用商店數(shù)據(jù)并不包含apk下載量，或?qū)Ρ葧r(shí)兩邊包含的app版本不同，都可能會(huì)造成比較大的差異。

Human error或工具顯示問題

進(jìn)行人工導(dǎo)出或分析數(shù)據(jù)時(shí)，要小心使用的工具給你設(shè)下陷阱。

常見的一個(gè)問題是，用Excel打開csv報(bào)表時(shí)，由于字符集不對(duì)導(dǎo)致顯示數(shù)據(jù)串列，統(tǒng)計(jì)出的數(shù)據(jù)自然有問題。

報(bào)表filter條件差異

使用后臺(tái)查看數(shù)據(jù)時(shí)，留意filter方面的默認(rèn)設(shè)置。

比如為了有效展示留存數(shù)據(jù)，AppsFlyer retention報(bào)表的最小分組量（Min Cohort Size）默認(rèn)是10，那么計(jì)數(shù)小于10的分組將不會(huì)顯示出來，這就會(huì)導(dǎo)致客戶發(fā)現(xiàn)利用retention查看install數(shù)據(jù)時(shí)比會(huì)其他報(bào)表少，或是不同分組設(shè)置的install數(shù)據(jù)不一致。其實(shí)這是filter不同造成的， 解決這個(gè)問題只需要將Min Cohort Size改成1即可。同樣的，其他系統(tǒng)也可能存在其他的filter設(shè)計(jì)，需要特別留意。

報(bào)表邏輯差異

不同的報(bào)表是為不同的分析目的而服務(wù)的，背后的計(jì)算邏輯可能完全不同。比如AppsFlyer的面板基本都是LTV（生命周期）數(shù)據(jù)，為方便客戶分析某天投放帶來用戶的后續(xù)質(zhì)量，進(jìn)而優(yōu)化廣告效果。而下載原始數(shù)據(jù)／Activity報(bào)表才是當(dāng)天發(fā)生的數(shù)據(jù)。我們常常遇到客戶將AppsFlyer的LTV數(shù)據(jù)與他們自己后臺(tái)的Activity數(shù)據(jù)進(jìn)行對(duì)比，差異可想而知。

安裝定義差異

我們知道AppsFlyer的安裝指的是首次打開（First open），而商店安裝實(shí)際上是下載。這兩者之間會(huì)有一定的差異。

比較tricky的情況是， Google AdWords平臺(tái)上的轉(zhuǎn)化（conversions）概念本身比較復(fù)雜，客戶在AdWords查看的conversions download 數(shù)據(jù)，可能來自不同的conversion source，比如來自Google Play的下載，或是Firebase的first open等信息，但客戶以為其采用的是AppsFlyer的數(shù)據(jù)，看起來差異就會(huì)非常大了。

所以，進(jìn)行AdWords的數(shù)據(jù)對(duì)比時(shí)一定要選擇查看conversion name，只選取AppsFlyer的first open數(shù)據(jù)來對(duì)比。

歸因窗口期差異

熟悉我們的客戶一定知道歸因回看窗口期即lookback window問題已經(jīng)是屢見不鮮了，歸因窗口期將客戶從點(diǎn)擊／查看廣告到下載打開應(yīng)用的時(shí)間定義為有效期。而實(shí)際上我們發(fā)現(xiàn)有一定比例的用戶是操作廣告后過幾天才打開應(yīng)用的。當(dāng)涉及查看歸因view through時(shí)差異會(huì)尤其明顯。比如Twitter／Facebook上View Through如果是開啟狀態(tài)，而AppsFlyer上是關(guān)閉狀態(tài)，那么可能造成比較大的差異。

說了這么多，出現(xiàn)差異怎么辦？來來來敲黑板劃重點(diǎn)！

1.將數(shù)據(jù)以不同維度劃分進(jìn)行對(duì)比

試著將數(shù)據(jù)按天/campaign/App version來對(duì)比，可以很容易發(fā)現(xiàn)差異問題的具體原因以及數(shù)據(jù)缺失等問題。

2.參考以上差異原因逐一排查

3.上傳完整信息到AppsFlyer Support調(diào)查