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

核心技術邏輯：

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

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

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

解析：

如何通過deferred deeplink獲取campaign

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

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

3，客戶端技術在啟動的時候獲取到設備信息，以及這個deeplink回傳過來的sourceid，服務端保存記錄。

4，通過sourceid來查詢對應的campaign，adset，ad基本信息，如果有必要，雙方約定好在deeplink里面增加字段就好。

通過這個邏輯，可以實現(xiàn)服務端知道哪一個設備來自于哪一個campaign的基本信息。

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

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

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

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

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

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

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

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

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

核心的需求點：

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

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

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

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

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

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

長按圖片加知識星球