本文只提供實(shí)現(xiàn)思路，嘗試省錢不買三方mmp來(lái)實(shí)現(xiàn)基礎(chǔ)統(tǒng)計(jì)，并不保證數(shù)據(jù)準(zhǔn)確性，自己實(shí)現(xiàn)BI無(wú)法實(shí)現(xiàn)渠道數(shù)據(jù)排重，只能用于”節(jié)儉“（窮）的廣告主來(lái)實(shí)現(xiàn)一些簡(jiǎn)單的數(shù)據(jù)統(tǒng)計(jì)。另外這方法基本也就安卓可用，Ios我還沒研究，估計(jì)沒戲。

核心技術(shù)邏輯：

1，facebook通過deferred deeplink實(shí)現(xiàn)獲取投放時(shí)候campaign，adset，ad信息。

2，Google通過Google提供的s2s對(duì)接實(shí)現(xiàn)獲取投放時(shí)候的campaign adgroup信息。（大致可以把自己當(dāng)做一個(gè)三方類對(duì)接自己的產(chǎn)品數(shù)據(jù)）

3，通過拿到對(duì)應(yīng)的campaign信息，實(shí)現(xiàn)bi統(tǒng)計(jì)分渠道，分campaign的投放效果統(tǒng)計(jì)，以及后續(xù)行為追蹤。

解析：

如何通過deferred deeplink獲取campaign

1，所有廣告發(fā)布的時(shí)候程序記錄一下發(fā)布的campaign/adset/ad id 和各個(gè)層級(jí)的name。

2，在每個(gè)發(fā)布上去的ad里面，都帶上deeplink，并且寫入一個(gè)隨機(jī)參數(shù)，類似sourceid =123456789，保證這個(gè)sourceid唯一。

3，客戶端技術(shù)在啟動(dòng)的時(shí)候獲取到設(shè)備信息，以及這個(gè)deeplink回傳過來(lái)的sourceid，服務(wù)端保存記錄。

4，通過sourceid來(lái)查詢對(duì)應(yīng)的campaign，adset，ad基本信息，如果有必要，雙方約定好在deeplink里面增加字段就好。

通過這個(gè)邏輯，可以實(shí)現(xiàn)服務(wù)端知道哪一個(gè)設(shè)備來(lái)自于哪一個(gè)campaign的基本信息。

這里是通過API發(fā)布facebook的方式，用程序記錄和自動(dòng)生成deeplink+sourceid，但是如果你沒有條件通過api來(lái)實(shí)現(xiàn)，你也可以通過用excel拉表的方式，直接把自己的campaign name，adset name和ad name用自己可以看明白的格式，直接寫死到deeplink中，用數(shù)字編號(hào)的形式可以在未來(lái)BI中直接搜索編號(hào)來(lái)查詢自己的campaign之類。

Google獲取campaign信息，這個(gè)需要Google的直客協(xié)助，對(duì)方提供S2S的對(duì)接文檔（我不便公開了），你再申請(qǐng)MCC的dev token ，創(chuàng)建Link ID， 再讓技術(shù)按照Google提供的文檔開發(fā)接受數(shù)據(jù)的部分。

這里實(shí)現(xiàn)的流程和你直接去三方里面獲取link id比較接近，但是需要自己申請(qǐng)dev token，再申請(qǐng)API權(quán)限，這個(gè)過程最大的坑就是周期特別長(zhǎng)，即便申請(qǐng)下來(lái)后也會(huì)發(fā)現(xiàn)把自己的mcc填到申請(qǐng)linkID的地方也需要等很久才能填進(jìn)去生效，太早了直接都是報(bào)錯(cuò)。

總之按照這兩個(gè)思路是可以拿到自己安裝后的設(shè)備信息，以及對(duì)應(yīng)安裝時(shí)候的campaign，adset等信息。但是這里肯定不出意外是要有意外的：

1，可能存在一個(gè)用戶會(huì)被記錄到多次安裝，Google+facebook都會(huì)記錄他的安裝，理論上我覺得應(yīng)該有Google referreal之類實(shí)現(xiàn)分析用戶的點(diǎn)擊時(shí)間，再可以實(shí)現(xiàn)具體的最后一次點(diǎn)擊是誰(shuí)貢獻(xiàn)的來(lái)判斷到底應(yīng)該歸因給誰(shuí)（這個(gè)事情好像就是第三方在干的），但是這個(gè)環(huán)節(jié)我沒去研究，所以沒辦法給大家分析，勤奮的同學(xué)可以嘗試看看referral的文檔，理論上應(yīng)該是可以拿到。

2，重復(fù)安裝的坑，FB GG都存用戶不活躍后再次曝光，卸載重裝的人再次重裝，這個(gè)地方我們?cè)趺从涗洈?shù)據(jù)，要想做的完善基本又要考慮和三方一樣去實(shí)現(xiàn)一大堆定義類似re-install，re-engagemtn等等，這個(gè)坑不建議你跳，既然都自己開發(fā)不想掏錢給三方，干脆就別介意這點(diǎn)誤差數(shù)據(jù)，都給他算新增算了。

3，只跑FB GG可能還好，想跑跑別的渠道就只能拜拜。

之后的重要內(nèi)容就是實(shí)現(xiàn)自己的BI系統(tǒng)。

我其實(shí)最喜歡的BI系統(tǒng)還是最早appsflyer 早期版本的那套，如果我要自己開發(fā)的話，肯定會(huì)直接按照當(dāng)初AF最早版本的設(shè)計(jì)思路開發(fā)，并且把不需要的功能先都去掉，加載速度優(yōu)先，傻瓜化操作。

核心的需求點(diǎn)：

1，7天內(nèi)（或者更多時(shí)間段）分渠道的柱狀圖，也可自定時(shí)間，點(diǎn)開對(duì)應(yīng)渠道的柱狀圖位置直接展開到campaign層級(jí)數(shù)據(jù)，再點(diǎn)開到了adset層級(jí)等。

2，最簡(jiǎn)單的計(jì)算各個(gè)event在不同campaign/adset/ad中間的數(shù)據(jù)表現(xiàn)，并且通過BI展示出來(lái)數(shù)據(jù)，比例等等。

3，計(jì)算campaign各個(gè)層級(jí)的的留存信息。按照用戶留存情況計(jì)算分campaign，adset等的留存數(shù)據(jù)。

其他很多功能，考慮到大家看這個(gè)文章的通常都是搞休閑游戲+工具之類的。所以 更多功能開發(fā)就不寫了，寫了這些IAA產(chǎn)品最關(guān)心的留存+event足夠，自己設(shè)計(jì)BI的難點(diǎn)其實(shí)可能是大量數(shù)據(jù)的整理分析，存儲(chǔ)，還要保證自己算數(shù)據(jù)的時(shí)候的查詢效率等等。技術(shù)上也要同時(shí)考慮老用戶，新用戶不斷產(chǎn)生的events之類的數(shù)據(jù)統(tǒng)計(jì)，數(shù)據(jù)查詢時(shí)間長(zhǎng)后估計(jì)服務(wù)器計(jì)算量也蠻大的。

出海流量玄學(xué)研究中心，不定期分享信息流廣告優(yōu)化師投放技巧，主要內(nèi)容為海外facebook，google，TikTok ads廣告投放技巧分享，歡迎大家關(guān)注，分享內(nèi)容，也歡迎大家分享更多關(guān)于游戲出海，跨境電商廣告投放技巧。

如果有投放專業(yè)領(lǐng)域需要咨詢，請(qǐng)加知識(shí)星球提問，個(gè)人微信不答疑

長(zhǎng)按圖片加知識(shí)星球