由于安卓分發(fā)渠道很多，對于不同渠道需要評價轉化率的時候，就需要追蹤投放出去包的數據情況，也就是需要在上報用戶啟動和激活等環(huán)節(jié)同步上報渠道號信息

渠道號的上報如何埋點呢

以前的數據埋點都是說在用戶觸發(fā)某個交互時候，也就是說不區(qū)分渠道包，只要是指定的某個代碼邏輯被觸發(fā)就一并回調上報數據+1，但是此時要是還得考慮不同包，就變成了得在相同代碼邏輯時候要上報不同的k及對應k的值

那么就會在不同的包中打上不同的配置文件，當這個包被激活或者被啟動的時候，代碼會自動先去獲取配置文件中的id信息作為k然后在進行對應v的上報

但當app進行升級的時候，新的配置文件會將老的配置文件給覆蓋，如果是從不同第一次下載的市場去升級app那么這個新的配置文件也會被覆蓋，這樣相對于第二個市場（渠道）的貢獻就會虛高（其實這個用戶已經有了app只不過升級時候把自己偽裝成了新下載），所以要想解決這個問題，就要是的用戶第一次下載使用時候把渠道信息存到不受升級影響的設備地方。然后每一次啟動都不是從配置文件來獲取而是通過這個秘密基地獲取渠道信息，從而精確統(tǒng)計渠道數據

iOS的發(fā)行渠道則與安卓有很大的不同，除了少數越獄的機器之外，大部分用戶的App都是從 App Store下載的。iOS的“渠道”其實通常是指那些在其它App或者網頁內部，提供到AppStore的鏈接的頁面。因此，在iOS中追蹤發(fā)行渠道，主要是追蹤進入App Store相關頁面的渠道信息。

但iOS的渠道追蹤面臨著一道無法逾越的鴻溝。正因為iOS的渠道分發(fā)都有跳轉到App Store這一步，而Apple本身是不會提供太多信息給開發(fā)者，所以，對于整個流程的三個步驟：在某個渠道點擊下載鏈接并跳轉到App Store ---> App Store內下載App --->用戶激活App，這其中的第二步，開發(fā)者無法獲取相關信息，所以，沒有辦法精確地追蹤一個用戶在這三個步驟中的完整軌跡，也即沒有辦法精確地衡量渠道的具體推廣效果。同時，安卓渠道效果分析中，常見的對于不同渠道打不同包的方案，在iOS分發(fā)時也是不可行的。

通過IDFA進行追蹤：這個方案一般用在App里面打開下載鏈接這種推廣方式?；镜姆桨甘?，推廣渠道的App（例如微信），會詳細記錄哪個IDFA點擊了待推廣App（例如聚美）的鏈接（或是在微信中嵌入SDK去記錄），而聚美本身，也會記錄具體的哪個IDFA激活了聚美App，兩者都將記錄下來的IDFA上傳至指定的服務器，進行對比，即可確定下載來源。在用戶不重置系統(tǒng)，不還原廣告的情況下，這種方式精準度比較高。

通過模糊特征匹配的方式來進行追蹤：點擊下載鏈接，會跳轉到appstore頁面，這個過程會觸發(fā)一個服務端的請求，服務器來記錄這次點擊的設備信息，包括ip地址、機型等。同時，被推廣App這邊，也可以記錄用戶激活App時機器的一些基本信息，并上傳至服務器。結合下載和激活的時間差，再結合設備的IP地址和機型等信息，大概可以模糊地識別出同一個用戶先點擊了下載鏈接，再激活了App，從而確定下載渠道。這種方式的精確度較低。

通過SFSafariViewController進行追蹤：iOS

9中新增的SFSafariViewController，這個類的API允許在app內打開一個safari瀏覽器，而不是一個app內部的webview。這個app內的safari和外面系統(tǒng)的safari是同一個，共享同一個沙盒，可以操作同一個Cookie，也就是說它可以跨App與Safari實現共享Cookie。

?基于SFSafariViewController控件，當用戶在App中通過它打開渠道頁面時，我們可以將渠道信息寫入Cookie中，并設置生效時間。當用戶安裝并激活 App后，再次使用SFSafariViewController上報激活信息，同時將Cookie中的渠道信息上傳，通過匹配，便可確定下載來源。由于渠道信息保存在設備本地，因此匹配是100%準確的。

但是基于SFSafariViewController這種方式也有一定的弊端。首先，這個方案只能支持iOS9及以上版本的設備，大約占全部蘋果設備的85%左右，覆蓋了絕大部分用戶，已經具有很好的分析價值了。但對于剩余的15%的用戶，該方案無法滿足。此外，對于目前業(yè)界主流的一些推廣渠道，如微信、朋友圈，它們尚未在App中使用SFSafariViewController控件訪問網頁，因此這部分渠道也無法使用精準匹配的方案。