解决“App渠道统计“技术难点分析,提高效率竟变得如此简单

近期公司App开始做邀请码相关需求，在开发之余同时思考了下邀请机制这块业务是否可以优化到无感知邀请，本文即是针对邀请机制中的最常见的流程进行分析，同时对可能进行优化的方案进行比较，来实现更加快速的拉新。

难题1 ：如何进行App渠道统计？

安卓app统计流量使用，方法如下

因为getUidRxBytes(int uid)和 getUidTxbytes(int uid)包括了所有网络形式的流量,即包括WIFI和4g/3g/2g，故需要监听WIFI变化，并记录zhiWIFI过程中该uid应用使用的流量记录。

public class WifiStateReceiver extends BroadcastReceiver implements ISusoConstants {
@Override
public 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) {//如果关闭
           //结余本次wifi过程中 uid应用的 流量
       } else if (wifistate == WifiManager.WIFI_STATE_ENABLED) {
           //记录当前uid应用的流量.
       }
   }
}

难题2:App邀请机制如何实现？

后台随机生成随机码 - 邀请码进行实现统计
邀请码一般有两个用途

• 做活动时用于老用户邀请新用户注册
• 派发给各个渠道进行App推广拉新。

两种形式其实本质上都是需要获取到【“谁”邀请了“谁”注册】这个行为，才能进行下一步数据的分析处理。

难题3:Android不同商店和iOS App store 如何统计来源？

1. 安卓不同商店植入不同渠道包,达到App多渠道统计
   目前在中国大陆的安卓市场中，由于应用商店（ 小米应用市场、华为应用市场、豌豆荚、百度助手等等 ）占领，安卓包也可以不需要上架应用商店直接下载，所以 Android 渠道追踪就可以利用 “apk包差异” 这个方法进行追踪，什么个包差异呢？其实就是在打包时植入不同的渠道ID，然后将对应的包放到对应的渠道供用户进行下载，用户注册时，将包内的渠道ID上报即可：
   

这个方式比较普遍，但是只能针对 Android，数据相对精准。

2. 安卓基于应用市场/下载页面直接提供的数据
   应用市场及下载页面的数据只能给到下载量，注册量无法知晓，对于运营分析数据不够精准。

iOS 使用IDFA渠道

IDFA 的全称：Identifier for Advertisers，这是苹果专门给各广告提供商用来追踪用户而设的标识。
一般流程：

这个方法本身是投放中比较通用的iOS 方案，但是很遗憾在iOS 14中 IDFA 的机制变更导致这个方案失去了应用的精准度。
当然这个方式是无法统计到从网页跳转到 App Store 去下载这个场景的。

1. iOS 使用 SFSafariViewController 配合 cookie 进行追踪
   如果iOS App 支持的 iOS版本 >= 9.0，可以使用 SFSafariViewController 配合 cookie 方式进行来源获取。SFSafariViewController 是 iOS开发中使用到的一个类，该类可以在 App 中打开“Safari”并且获取 Safari中的 cookie 等相应信息，基于此，我们可以设计出一套方案：

这个方案可以做到一定程度上的准确，但是适用场景毕竟有限，在微信/QQ等其他App的 WKWebView/UIWebView中打开广告时，就无能为力了。

上述方案总结：

目前市面上主流的邀请渠道追踪方案，方案本身复制度不高，但是在精度和场景方面均有不足

• 没有一个方案可以使用各个场景
• 安卓和 iOS 实现无法统一，导致数据分析复杂，并且容易出错
• 各个方案对 客户端开发来说均不友好，增加了开发的复杂度
• 数据展示还需要后端进行处理后，前端拿到数据，展示在 后台管理系统里，增加了开发成本

优化方案

如何解决 App渠道统计中的技术难点，降低开发难度又能最大程度上保证数据的精准度呢？

需要分析优化后的方案：

1. 一套方案适用于 Android & iOS
2. 无论是在什么地方打开推广渠道的网页下载，或者是跳转到 应用市场下载，均能有效追踪来源
3. 数据处理简单方便
4. 数据展示友好，表和图展示
5. 降低开发复杂度，减少开发成本
6. 自己开发研究还是选择靠谱的第三方

经过自己开发和不断市场调研后，发现市面上确实有现成的第三方符合这个优化后的方案形态，并且还额外提供了一键唤醒/埋点统计等的功能。当然本着研究技术的精神，我们还是深入调研了一些第三方的方案是如何实现的（最终还是想要自己公司内部做一套类似的）。

但是遗憾的是，这套方案实现的复杂度不亚于我们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
  当然数据测试越久越准确，不过目前来看，数据精准度表现出乎意料！值得推荐一波！