最近 公司 App 开始 做邀请码 相关 的需求 ,在开发 的同时 也思考 了下邀请 机制 这块 业务 能否 优化 为无感知 邀请 ,本文 就是 对邀请 机制 中最常见 的流程 进行 分析 ,同时 比较 可能 优化 的方案 ,以实现 更快 的更新 。
问题 一:如何 进行 App 渠道 统计 ? Androidapp通过 以下 方式 统计 流量 使用 。 由于 get Uid RxBytes(intuid )和get Uid Txb ytes(intuid )包含 所有 网络 形式 的流量 ,即包含 WIF I和4g/3g /2g ,因此 需要 对WIF I的变化 进行 监听 ,并记录 在zhiWIF I期间 uid 应用 所使用 的流量 记录
问题 二:如何 实现 App 邀请 机制 ? 背景 随机 产生 随机码 -邀请码 以实现 统计 。请帖 一般 有两种 用途 。 当老用户 邀请 新用户注册 时进行 活动 。向各渠道 分发 App 推广 拉新 。实际上 ,这两种 形式 本质 上都 需要 获取 到“谁”邀请 “谁”注册 的行为 ,才能 进行 下一步 数据的分析处理 。 问题 三:Android的不同 商店 和iOS App store 的数据来源是什么 ? Android的不同 商店 植入 不同 的渠道 包,达到 App 多渠道 统计 。 现在 ,在中国大陆 的Android市场上 ,由于 应用程序 商店 (小米应用 程序 、华为应用 程序 、豌豆荚 、百度助手 等)的占据 ,Android软件包 可以 不用 直接下载,所以 Android渠道 追踪 可以 使用 “apk软件包差异化 ”的方法 来追踪 ,那么 软件包 差异化 是什么呢? 实际上 就是 在打包 时植入 不同 的渠道 ID ,然后 把相应 的包放到 相应 的渠道 中供 用户 下载 ,用户注册 后,将包中 的渠道 ID 上报 : 这种 方法 比较 常见 ,但只适用于 Android系统 ,数据 比较 精确 。 Android基于 直接 提供 的应用市场 /下载页面 数据 。 申请 数量 和下载页面 数据 只能 给到下载量 ,注册 数量 无法 知道 ,对于 操作 分析数据不够 精确 。 使用 IDFA通道 的iOS 。 全名为 IDFA:Ad vertifier for sers ,苹果 专门 为各种 广告 提供 商业 标识 ,以跟踪 用户 。 通用 流程 : 这一 方法 本身 是在发布 时比较 一般 iOS 方案 的,但遗憾 的是IDFA在iOS 14 中的机制 更改 使这一 方案 失去了 应用 的准确性 。 这种 方式 当然 不能 通过 统计 来从网页 跳到应用程序 商店 来下载 。 使用 SF SafariViewCont roller与cookie 配合 的iOS 跟踪 。 若iOS 版本 支持 >=9.0 ,可通过 SF SafariViewCont roller与cookie 结合 使用 源代码 获取 。 SF SafariViewCont roller是iOS 开发 中使用 的一个 类,这个 类可以 在App 中打开 “Safari”,并获得 诸如 Safari中的cookie 之类 的相关信息 ,基于 此,我们可以设计 一套 : 该方案 可以 在一定 程度 上做到 精确 ,但应用场景 毕竟 有限 ,在微信/QQ 等其他 应用程序 的WKWebView/UI Web View中打开 广告 时,也无能为力 。
优化方案 如何解决 App渠道统计中的技术难点,降低开发难度又能最大程度上保证数据的精准度呢? 需要分析优化后的方案: 一套方案适用于 Android & iOS 无论是在什么地方打开推广渠道的网页下载,或者是跳转到 应用市场下载,均能有效追踪来源 数据处理简单方便 1、数据展示友好,表和图展示 2、降低开发复杂度,减少开发成本 3、自己开发研究还是选择靠谱的第三方 经过自己开发和不断市场调研后Xinstall渠道统计符合这个优化后的方案形态,并且还额外提供了一键唤醒/埋点统计等的功能。当然本着研究技术的精神,我们还是深入调研了一些第三方的方案是如何实现的(最终还是想要自己公司内部做一套类似的)。 但是遗憾的是,这套方案实现的复杂度不亚于我们App研发的复杂度。这也就意味着如果我们打算自研,那么投入的成本将会在几十万RMB以上,当然后期的维护成本也会随之而来,故最终我们打算在各个第三方之间综合选择。
微信
电话