iOS怎樣統(tǒng)計渠道數(shù)據(jù)，一文全解析

說起 iOS 的渠道統(tǒng)計，不少人會想到蘋果官方的 App 分析功能（iTunes Connect），但實際操作中我們會發(fā)現(xiàn)，這個服務的統(tǒng)計維度還不夠全面，許多廣告主和運營人員更關心的是各個推廣渠道實際帶來的安裝量、注冊量等數(shù)據(jù)，畢竟這對渠道引流的分析價值更大。iOS的“渠道”通常是指那些在其它 App 或者網(wǎng)頁內(nèi)部，提供到達 App Store 的鏈接的頁面。因此，在 iOS 中追蹤發(fā)行渠道，主要是追蹤進入 App Store 相關頁面的渠道信息。

從技術角度來看，也就是在用戶首次下載時不僅要獲取下載來源，還要實現(xiàn)參數(shù)傳遞，簡單來說，就是用戶第一次下載后，我能得知后續(xù)的注冊、活躍、付費等操作行為?；蛘咴诖嘶A上，實現(xiàn)場景還原，幫助用戶在首次打開 App 后直接跳轉進指定頁面，而不是首頁。

方案一：蘋果官方自帶的統(tǒng)計工具 iTunes Connect

登錄 iTunes Connect ，在“App 分析”中，能很方便的查看 App 的展示次數(shù)、購買量等基礎數(shù)據(jù)，但無法獲取更加詳細的安裝量、注冊量等運營數(shù)據(jù)。

當然，往往 App 推廣的渠道會有很多同時進行，怎么對多個渠道的來源做分析呢？同樣在“App分析”的“來源”中點擊“營銷活動”，右上角有個“生成營銷活動鏈接”，進入后就能自定義給每個渠道生成對應的唯一標識。

這種方法雖然可以追蹤到多個渠道的來源，但存在以下幾個問題：

• 只有當營銷活動啟動后超過一天時間（最長72個小時）后才能顯示相關數(shù)據(jù)；
• 至少有 5 個 App 購買量歸因于此營銷活動時，營銷活動才會在“App 分析”中顯示；
• 無法兼容 Android 和 iOS企業(yè)簽名，采用不同的統(tǒng)計方法可能會讓數(shù)據(jù)統(tǒng)一性較差；
• iOS 8.0 及以上版本的用戶可以選擇是否將自己的應用使用情況的數(shù)據(jù)發(fā)送給Apple。

方案二：使用 SFSafariViewController 傳遞參數(shù)

SFSafariViewController 是 iOS 9.0 出現(xiàn)的，可以通過 Safari 對應的 cookier 傳遞參數(shù)，跨App與Safari共享數(shù)據(jù)。但是 openurl 失敗率還是很高，并且有系統(tǒng)版本、瀏覽器等限制，比如微信等第三方 App 的內(nèi)置瀏覽器就不能很好實現(xiàn)。

方案三：通過 IDFA 進行追蹤，比如 Google Analytics

常用的比如谷歌官方的 Google Analytics，它的獲取原理就是通過獲取設備的 IDFA ，來作為唯一標示符號，然后根據(jù)你的渠道來源提供數(shù)據(jù)，通過比對的方式進行渠道定位。弊端在于，用戶重置系統(tǒng)，或者關閉廣告跟蹤的話，這種方法就會失效。

蘋果設備設置里都會有一個開關用于限制廣告跟蹤：

目前用戶的隱私保護意識也在逐漸覺醒，只要用戶手握這個開關，IDFA 的統(tǒng)計誤差就始終存在。

另一方面，Google Analytics 的 iOS 安裝跟蹤功能僅適用于通過移動廣告網(wǎng)絡（例如投放應用內(nèi)廣告的AdMob）投放的廣告。也就是如果渠道是從線下掃二維碼或者web上的推廣鏈接下載是不能通過這種方法跟蹤到的，這時就需要其它工具作為補充。

方案四：通過模糊特征匹配的方式進行追蹤

用戶點擊下載鏈接，會跳轉到 App Store 里，這個過程會觸發(fā)一個服務端的請求，服務器來記錄這次點擊的設備信息，包括 ip 地址、機型等。同時，被推廣 App 這邊，也可以記錄用戶激活 App 時設備的一些基本信息，并上傳至服務器。結合下載和激活的時間差，再結合設備的 IP 地址和機型等信息，大概可以模糊地識別出同一個用戶先點擊了下載鏈接，再激活了 App，從而確定下載渠道。這種方式在面對用戶量大的渠道時，準確率就會下降不少。

方案五：采用第三方 SDK 追蹤，比如 openinstall

openinstall 基本原理：

1. 開發(fā)者在分享的 h6 頁面上集成 openinstall web sdk，發(fā)布分享鏈接時在url上動態(tài)的拼接任意的自定義參數(shù)（如推廣渠道號，邀請碼，游戲房間號等等）；
2. 當某一終端訪問該 h6 頁面時，openinstall web sdk 將同時確定該設備的個性化信息和采集自定義參數(shù)，上傳至 openinstall 服務器， 待用戶通過該 h6 頁面安裝 App 后首次打開時，使用 openinstall Android/iOS sdk 從 openinstall 服務器再取回暫存的自定義參數(shù)。

在推廣渠道相當多的情況下，通過分發(fā) h6 落地頁給不同渠道，從每個渠道來的用戶，沒有任何感知的情況下，后臺可以統(tǒng)計到他激活及注冊時的渠道 ID （甚至其他任意參數(shù)）。實際誤差是較低的，相比其他方法精準度更高。

這種方法沒有 iTunes Connect 的諸多限制，也很好的補充了 Google Analytics 不能統(tǒng)計網(wǎng)頁下載渠道的弊端，理論上可以同時生成無上限的渠道鏈接進行統(tǒng)計，由于是國內(nèi)產(chǎn)品，還能實時反饋數(shù)據(jù)情況。

總結：

我的建議是，如果自己的業(yè)務既有網(wǎng)站又有 App 的話，Google Analytics 的一系列產(chǎn)品都可以使用，畢竟都用同一種統(tǒng)計工具，可以保證數(shù)據(jù)的統(tǒng)一性，方便數(shù)據(jù)分析。

當然，從權威性來看，蘋果官方的 iTunes Connect 自然更加值得信賴，但上文提到的弊端需要適當斟酌。

兩者在使用中都可以用 openinstall 來補充弊端，如果產(chǎn)品主要是面對移動端，openinstall 甚至可以兼容安卓的統(tǒng)計，在市場運營中也能保證數(shù)據(jù)的統(tǒng)一性。