近期公司App開始做邀請碼相關(guān)需求，在開發(fā)之余同時思考了下邀請機制這塊業(yè)務(wù)是否可以優(yōu)化到無感知邀請，本文即是針對邀請機制中的最常見的流程進行分析，同時對可能進行優(yōu)化的方案進行比較，來實現(xiàn)更加快速的拉新。

難題1 ：如何進行App渠道統(tǒng)計？

安卓app統(tǒng)計流量使用，方法如下

因為getUidRxBytes(int uid)和 getUidTxbytes(int uid)包括了所有網(wǎng)絡(luò)形式的流量,即包括WIFI和4g/3g/2g，故需要監(jiān)聽WIFI變化，并記錄zhiWIFI過程中該uid應(yīng)用使用的流量記錄。

public class WifiStateReceiver extends BroadcastReceiver implements ISusoConstants {@Overridepublic void onReceive(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) {//如果關(guān)閉 //結(jié)余本次wifi過程中 uid應(yīng)用的 流量 } else if (wifistate == WifiManager.WIFI_STATE_ENABLED) { //記錄當前uid應(yīng)用的流量. } }}難題2:App邀請機制如何實現(xiàn)？

后臺隨機生成隨機碼 - 邀請碼進行實現(xiàn)統(tǒng)計邀請碼一般有兩個用途

做活動時用于老用戶邀請新用戶注冊派發(fā)給各個渠道進行App推廣拉新。

兩種形式其實本質(zhì)上都是需要獲取到【“誰”邀請了“誰”注冊】這個行為，才能進行下一步數(shù)據(jù)的分析處理。

難題3:Android不同商店和iOS App store 如何統(tǒng)計來源？安卓不同商店植入不同渠道包,達到App多渠道統(tǒng)計目前在中國大陸的安卓市場中，由于應(yīng)用商店（ 小米應(yīng)用市場、華為應(yīng)用市場、豌豆莢、百度助手等等 ）占領(lǐng)，安卓包也可以不需要上架應(yīng)用商店直接下載，所以 Android 渠道追蹤就可以利用 “apk包差異” 這個方法進行追蹤，什么個包差異呢？其實就是在打包時植入不同的渠道ID，然后將對應(yīng)的包放到對應(yīng)的渠道供用戶進行下載，用戶注冊時，將包內(nèi)的渠道ID上報即可：

這個方式比較普遍，但是只能針對 Android，數(shù)據(jù)相對精準。

安卓基于應(yīng)用市場/下載頁面直接提供的數(shù)據(jù)應(yīng)用市場及下載頁面的數(shù)據(jù)只能給到下載量，注冊量無法知曉，對于運營分析數(shù)據(jù)不夠精準。

iOS 使用IDFA渠道

IDFA 的全稱：Identifier for Advertisers，這是蘋果專門給各廣告提供商用來追蹤用戶而設(shè)的標識。一般流程：

這個方法本身是投放中比較通用的iOS 方案，但是很遺憾在iOS 14中 IDFA 的機制變更導(dǎo)致這個方案失去了應(yīng)用的精準度。當然這個方式是無法統(tǒng)計到從網(wǎng)頁跳轉(zhuǎn)到 App Store 去下載這個場景的。

iOS 使用 SFSafariViewController 配合 cookie 進行追蹤如果iOS App 支持的 iOS版本 >= 9.0，可以使用 SFSafariViewController 配合 cookie 方式進行來源獲取。SFSafariViewController 是 iOS開發(fā)中使用到的一個類，該類可以在 App 中打開“Safari”并且獲取 Safari中的 cookie 等相應(yīng)信息，基于此，我們可以設(shè)計出一套方案：

這個方案可以做到一定程度上的準確，但是適用場景畢竟有限，在微信/QQ等其他App的 WKWebView/UIWebView中打開廣告時，就無能為力了。

上述方案總結(jié)：

目前市面上主流的邀請渠道追蹤方案，方案本身復(fù)制度不高，但是在精度和場景方面均有不足

沒有一個方案可以使用各個場景安卓和 iOS 實現(xiàn)無法統(tǒng)一，導(dǎo)致數(shù)據(jù)分析復(fù)雜，并且容易出錯各個方案對 客戶端開發(fā)來說均不友好，增加了開發(fā)的復(fù)雜度數(shù)據(jù)展示還需要后端進行處理后，前端拿到數(shù)據(jù)，展示在 后臺管理系統(tǒng)里，增加了開發(fā)成本優(yōu)化方案

如何解決 App渠道統(tǒng)計中的技術(shù)難點，降低開發(fā)難度又能最大程度上保證數(shù)據(jù)的精準度呢？

需要分析優(yōu)化后的方案：

一套方案適用于 Android & iOS無論是在什么地方打開推廣渠道的網(wǎng)頁下載，或者是跳轉(zhuǎn)到 應(yīng)用市場下載，均能有效追蹤來源數(shù)據(jù)處理簡單方便數(shù)據(jù)展示友好，表和圖展示降低開發(fā)復(fù)雜度，減少開發(fā)成本自己開發(fā)研究還是選擇靠譜的第三方

經(jīng)過自己開發(fā)和不斷市場調(diào)研后，發(fā)現(xiàn)市面上確實有現(xiàn)成的第三方符合這個優(yōu)化后的方案形態(tài)，并且還額外提供了一鍵喚醒/埋點統(tǒng)計等的功能。當然本著研究技術(shù)的精神，我們還是深入調(diào)研了一些第三方的方案是如何實現(xiàn)的（最終還是想要自己公司內(nèi)部做一套類似的）。

但是遺憾的是，這套方案實現(xiàn)的復(fù)雜度不亞于我們App研發(fā)的復(fù)雜度。這也就意味著如果我們打算自研，那么投入的成本將會在幾十萬RMB以上，當然后期的維護成本也會隨之而來，故最終我們打算在各個第三方之間綜合選擇。

參考1：https://zhuanlan.zhihu.com/p/252894877參考2:https://blog.csdn.net/A966669/article/details/107489539參考3:https://xintu.jianshu.com/p/267d2ac0d2b3參考4:https://xintu.jianshu.com/p/ecd1794768fa

我們最終選擇的這個第三方Xinstall，完美符合了這個優(yōu)化方案：

1、一套方案適用于 Android & iOS（兩端接入的是同樣邏輯的 SDK）

支持iOS和Android以及Web三端的統(tǒng)計

Xinstall 提供完整的 javascript api，方便 Web 開發(fā)者實現(xiàn)完全自主的設(shè)計 集成步驟。使用方便，對接簡單

2、無論是在什么地方打開推廣渠道的網(wǎng)頁下載，或者是跳轉(zhuǎn)到 應(yīng)用市場下載，均能有效追蹤來源（統(tǒng)計時從打開推廣頁面 -> 打開App注冊，這中間無論經(jīng)過多少過程，甚至關(guān)機重啟，均能有效追蹤到來源）

3、數(shù)據(jù)處理盡可能簡單

4、數(shù)據(jù)展示友好

5、減少開發(fā)復(fù)雜度，減少開發(fā)成本（我們公司 iOS 和 Android 同學(xué)分別花了 12分鐘 / 8分鐘閱讀文檔完成接入）

最后

第三方實際使用后數(shù)據(jù)精準度是否達標

當然作為一個大廠，直接使用任何第三方的時候，都需要經(jīng)過一段時間的實際使用才能確定后續(xù)能否繼續(xù)采用，因此我們保留了原有的方案（上述4個方案的混合使用），與該第三方方案進行A/B線上測試，測試時長為1周。

測試結(jié)果：

第三方中捕捉了約5%原有混合方案中遺留的數(shù)據(jù)第三方中總體數(shù)據(jù)精準度達99.96%（各個渠道實際注冊數(shù)據(jù)對比的平均值），遠高于原先混合方案中的93%數(shù)據(jù)延遲幾乎為0當然數(shù)據(jù)測試越久越準確，不過目前來看，數(shù)據(jù)精準度表現(xiàn)出乎意料！值得推薦一波！