近期公司App開始做邀請碼相關需求，在開發之餘同時思考了下邀請機制這塊業務是否可以優化到無感知邀請，本文即是針對邀請機制中的最常見的流程進行分析，同時對可能進行優化的方案進行比較，來實現更加快速的拉新。
難題1 ：如何進行App渠道統計？
安卓app統計流量使用，方法如下
因為getUidRxBytes(int uid)和 getUidTxbytes(int uid)包括了所有網絡形式的流量,即包括WIFI和4g/3g/2g，故需要監聽WIFI變化，並記錄zhiWIFI過程中該uid應用使用的流量記錄。
publicclassWifiStateReceiverextendsBroadcastReceiverimplementsISusoConstants{@OverridepublicvoidonReceive(Context context, Intent intent){if(intent.getAction().equals(WifiManager.WIFI_STATE_CHANGED_ACTION)){int wifistate = intent.getIntExtra(WifiManager.EXTRA_WIFI_STATE, WifiManager.WIFI_STATE_DISABLED);if(wifistate == WifiManager.WIFI_STATE_DISABLED){//如果關閉//結餘本次wifi過程中 uid應用的 流量}elseif(wifistate == WifiManager.WIFI_STATE_ENABLED){//記錄當前uid應用的流量.}}}
難題2:App邀請機制如何實現？
後臺隨機生成隨機碼 - 邀請碼進行實現統計邀請碼一般有兩個用處
做活動時用於老用戶邀請新用戶註冊派發給各個渠道進行App推廣拉新兩種形式其實本質上都是需要獲取到【「誰」邀請了「誰」註冊】這個行為，才能進行下一步數據的分析處理。
難題3:Android不同商店和iOS App store 如何統計來源？
安卓不同商店植入不同渠道包,達到App多渠道統計目前在中國大陸的安卓市場中，由於應用商店（ 小米應用市場、華為應用市場、豌豆莢、百度助手等等 ）佔領，安卓包也可以不需要上架應用商店直接下載，所以 Android 渠道追蹤就可以利用 「apk包差異」 這個方法進行追蹤，什麼個包差異呢？其實就是在打包時植入不同的渠道ID，然後將對應的包放到對應的渠道供用戶進行下載，用戶註冊時，將包內的渠道ID上報即可
這個方式比較普遍，但是只能針對 Android，數據相對精準。
安卓基於應用市場/下載頁面直接提供的數據應用市場及下載頁面的數據只能給到下載量，註冊量無法知曉，對於運營分析數據不夠精準。
iOS 使用IDFA渠道
IDFA的全稱：Identifier for Advertisers，這是蘋果專門給各廣告提供商用來追蹤用戶而設的標識。
一般流程：
這個方法本身是投放中比較通用的iOS 方案，但是很遺憾在iOS 14中 IDFA 的機制變更導致這個方案失去了應用的精準度。當然這個方式是無法統計到從網頁跳轉到 App Store 去下載這個場景的。
iOS 使用 SFSafariViewController配合 cookie進行追蹤如果iOS App支持的 iOS版本 >= 9.0可以使用 SFSafariViewController 配合 cookie 方式進行來源獲取SFSafariViewController 是 iOS開發中使用到的一個類，該類可以在 App 中打開「Safari」並且獲取 Safari中的 cookie 等相應信息，基於此，我們可以設計出一套方案：
這個方案可以做到一定程度上的準確，但是適用場景畢竟有限，在微信/QQ等其他App的
WKWebView/UIWebView
中打開廣告時，就無能為力了。
上述方案總結：
目前市面上主流的邀請渠道追蹤方案，方案本身複製度不高，但是在精度和場景方面均有不足
沒有一個方案可以使用各個場景安卓和 iOS 實現無法統一，導致數據分析複雜，並且容易出錯各個方案對 客戶端開發來說均不友好，增加了開發的複雜度數據展示還需要後端進行處理後，前端拿到數據，展示在 後臺管理系統裡，增加了開發成本
優化方案
如何解決 App渠道統計中的技術難點，降低開發難度又能最大程度上保證數據的精準度呢？
需要分析優化後的方案：
一套方案適用於 Android& iOS無論是在什麼地方打開推廣渠道的網頁下載，或者是跳轉到 應用市場下載，均能有效追蹤來源數據處理簡單方便數據展示友好，表和圖展示降低開發複雜度，減少開發成本自己開發研究還是選擇靠譜的第三方
經過自己開發和不斷市場調研後，發現市面上確實有現成的第三方符合這個優化後的方案形態，並且還額外提供了一鍵喚醒/埋點統計等的功能。當然本著研究技術的精神，我們還是深入調研了一些第三方的方案是如何實現的（最終還是想要自己公司內部做一套類似的）。
但是遺憾的是，這套方案實現的複雜度不亞於我們App研發的複雜度。這也就意味著如果我們打算自研，那麼投入的成本將會在幾十萬RMB以上，當然後期的維護成本也會隨之而來，故最終我們打算在各個第三方之間綜合選擇。
參考1：https://zhuanlan.zhihu.com/p/252894877參考2:https://blog.csdn.net/A966669/article/details/107489539參考3:https://www.jianshu.com/p/267d2ac0d2b3參考4:https://www.jianshu.com/p/ecd1794768fa
我們最終選擇的這個第三方Xinstall，完美符合了這個優化方案：
1、一套方案適用於 Android & iOS（兩端接入的是同樣邏輯的 SDK）
支持iOS和Android以及Web、三端的統計
Xinstall 提供完整的 javascript api，方便 Web 開發者實現完全自主的設計 集成步驟。使用方便，對接簡單
2、無論是在什麼地方打開推廣渠道的網頁下載，或者是跳轉到 應用市場下載，均能有效追蹤來源（統計時從打開推廣頁面 -> 打開App註冊，這中間無論經過多少過程，甚至關機重啟，均能有效追蹤到來源）3、數據處理儘可能簡單
4、數據展示友好
5、減少開發複雜度，減少開發成本（我們公司 iOS 和 Android 同學分別花了 12分鐘 / 8分鐘閱讀文檔完成接入）
最後
第三方實際使用後數據精準度是否達標
當然作為一個大廠，直接使用任何第三方的時候，都需要經過一段時間的實際使用才能確定後續能否繼續採用，因此我們保留了原有的方案（上述4個方案的混合使用），與該第三方方案進行A/B線上測試，測試時長為1周。
測試結果：
第三方中捕捉了約5%原有混合方案中遺留的數據第三方中總體數據精準度達99.96%（各個渠道實際註冊數據對比的平均值），遠高於原先混合方案中的93%數據延遲幾乎為0當然數據測試越久越準確，不過目前來看，數據精準度表現出乎意料！值得推薦一波！