在開始之前，我們先來看看安卓的渠道統計。Google官方的應用商店Google Play在國內一直是無法使用的狀態，所以國內的安卓App分發，都是依託數十個不同的應用市場或發行渠道，如百度、360、騰訊等互聯網企業以及小米、華爲、魅族等手機生產商。對於安卓App的渠道追蹤，主要是圍繞上面這些大的渠道來進行，並且這些渠道自己一般也會提供非常詳盡和周全的數據分析給應用開發者。
iOS的發行渠道則與安卓有很大的不同，除了少數越獄的機器之外，大部分用戶的App都是從 App Store下載的。iOS的“渠道”其實通常是指那些在其它App或者網頁內部，提供到AppStore的鏈接的頁面。因此，在iOS中追蹤發行渠道，主要是追蹤進入App Store相關頁面的渠道信息。
但iOS的渠道追蹤面臨着一道無法逾越的鴻溝。正因爲iOS的渠道分發都有跳轉到App Store這一步，而Apple本身是不會提供太多信息給開發者，所以，對於整個流程的三個步驟：在某個渠道點擊下載鏈接並跳轉到App Store ---> App Store內下載App --->用戶激活App，這其中的第二步，開發者無法獲取相關信息，所以，沒有辦法精確地追蹤一個用戶在這三個步驟中的完整軌跡，也即沒有辦法精確地衡量渠道的具體推廣效果。同時，安卓渠道效果分析中，常見的對於不同渠道打不同包的方案，在iOS分發時也是不可行的。
對於iOS的困境，該如何解決呢？現在市場上大概有以下三種方式：
通過IDFA進行追蹤：這個方案一般用在App裏面打開下載鏈接這種推廣方式。基本的方案是，推廣渠道的App（例如微信），會詳細記錄哪個IDFA點擊了待推廣App（例如聚美）的鏈接（或是在微信中嵌入SDK去記錄），而聚美本身，也會記錄具體的哪個IDFA激活了聚美App，兩者都將記錄下來的IDFA上傳至指定的服務器，進行對比，即可確定下載來源。在用戶不重置系統，不還原廣告的情況下，這種方式精準度比較高。
通過模糊特徵匹配的方式來進行追蹤：點擊下載鏈接，會跳轉到appstore頁面，這個過程會觸發一個服務端的請求，服務器來記錄這次點擊的設備信息，包括ip地址、機型等。同時，被推廣App這邊，也可以記錄用戶激活App時機器的一些基本信息，並上傳至服務器。結合下載和激活的時間差，再結合設備的IP地址和機型等信息，大概可以模糊地識別出同一個用戶先點擊了下載鏈接，再激活了App，從而確定下載渠道。這種方式的精確度較低。
通過SFSafariViewController進行追蹤：iOS 9中新增的SFSafariViewController，這個類的API允許在app內打開一個safari瀏覽器，而不是一個app內部的webview。這個app內的safari和外面系統的safari是同一個，共享同一個沙盒，可以操作同一個Cookie，也就是說它可以跨App與Safari實現共享Cookie。
基於SFSafariViewController控件，當用戶在App中通過它打開渠道頁面時，我們可以將渠道信息寫入Cookie中，並設置生效時間。當用戶安裝並激活 App後，再次使用SFSafariViewController上報激活信息，同時將Cookie中的渠道信息上傳，通過匹配，便可確定下載來源。由於渠道信息保存在設備本地，因此匹配是100%準確的。
但是基於SFSafariViewController這種方式也有一定的弊端。首先，這個方案只能支持iOS9及以上版本的設備，大約佔全部蘋果設備的85%左右，覆蓋了絕大部分用戶，已經具有很好的分析價值了。但對於剩餘的15%的用戶，該方案無法滿足。此外，對於目前業界主流的一些推廣渠道，如微信、朋友圈，它們尚未在App中使用SFSafariViewController控件訪問網頁，因此這部分渠道也無法使用精準匹配的方案。
市面上的做法有的是上述三種方式單一出現，有的是兩兩組合，總之不管是通過哪種方式，這都是我們想象出來的間接的方式，只能說是儘量的去接近準確，但不能做到100%準確。在今年的4月15日，蘋果低調發布了一項重大功能，開始提供渠道來源的數據，就以往而言，蘋果僅開放有限的數據統計，很容易讓從業人員在工作遇到窘境，我們該如何統計到來源渠道。而此次推出的用戶來源統計，對 App推廣人員來說，無疑是一項重大舉措。
關於蘋果推出的這項功能，我會在另一篇文章中http://blog.csdn.net/neveraway1993/article/details/72461438，詳細介紹，歡迎大家前來探討！