App渠道来源追踪方案全面分析(iOS/Android/鸿蒙)

一、App 渠道来源追踪概述

渠道来源统计/追踪,其原理都可以称之为归因,归因是用于判断用户在什么原因、什么时间、什么场景下载了 App,以及打通他们在激活 App 后进行的一系列操作(比如注册、付费、加购等)。

渠道来源追踪的实现场景:

我们以某 App 推广为例,渠道 A、B、C 分别对应三个不同的 web 网页,三个 web 网页访问时采用同样的重定向操作,都可以跳转到该 App 的应用商店,并将三个 web 页面投放到不同的推广渠道,比如:

  • 添加到不同的三篇文章中,将三篇文章转发到各个平台引导下载,用户通过哪篇文章下载的,都能追踪到其效果。
  • 分发给不同的推广团队,团队不管是拿去地推也好,活动拉新也好,都能分析到各自拉新引流带来的贡献程度。
  • 转化成二维码,将生成的二维码贴在售卖产品的包装上,分销于不同的店铺,用户在哪里买的产品,那么就是从该产品引导下载安装的 App。

具体的流程如下:

  1. 用户通过点击链接或者扫码访问,会先跳转访问一个 web 网页,web
    网页加载时,会将当前用户设备的部分所需信息,比如设备唯一标识、系统版本等上传给服务器。
  2. 与此同时,页面也会重定向跳转至应用市场,用户在应用市场下载安装该 App。
  3. 安装成功后,用户首次启动 App。
  4. App 在启动时,会自动获取当前用户设备的信息,比如设备唯一标识、系统版本等上传给服务器。
  5. 服务器将第 1 步接收到的设备信息与第 4步发过来的设备信息进行对比,如果能匹配得上,则表明这次安装时由对应渠道链接引导安装的,如果匹配不到,则默认为是自然流量安装。

理论上以上方案是可行的,但是实际操作时面临的难题却非常多,比如:H5 渠道推广是获取不到设备号的,并且由于 iOS 和安卓多轮迭代,在 web 端实际上已经无法获取过多的设备唯一标识,只能用一些模糊匹配,比如获取设备的 IP、UA、手机型号等,但这些标识都是会变化的。

Android 方法限制:

**IMEI:**国际移动设备标识码,曾经最靠谱的 IMEI,在 Android 10 后禁止获取。

**Android ID:**一种半永久标识符,缺点是系统重置或刷机后会发生变化。并且在 Android 8.0 以后,签名不同的 App 所获取的 Android ID 是不一样的,而如果在 CPI 广告等场景下,就需要唯一标识一台设备,此方案也就不那么有效。

**OAID:**匿名设备标识符,移动安全联盟用于替代 IMEI 的方案,目前只有华为、小米、OPPO、vivo、中兴、努比亚、魅族、联想、三星等设备厂商在逐步支持,缺点是一些旧版本设备没有更新,并且不仅需要第三方工具能够支持,还需要广告投放平台能够支持回传 ID 信息才有效。

iOS 方法限制:

**IDFA:**属于 iOS 的设备号,是唯一标识号,但苹果一直在对 IDFA 做各种使用限制,iOS 10 提供了 Limit Ad Tracking,用户可以在设备设置里主动关闭 IDFA,误差就基于有多少用户关闭了这个按钮。iOS14 以后,App 在访问用户设备的 IDFA 之前,会弹出授权框给用户,必须获取用户授权才能使用,增加了用户拒绝的风险,以后 IDFA 方案准确度会更低。

**iTunes Connect App 分析:**苹果官方统计功能。只需要在 iTunes Connect"App 分析"的"来源"中点击"营销活动",右上角有个"生成营销活动链接",进入后就能自定义设置对应的唯一标识,给每个渠道生成专属的渠道链接。将生成的活动链接,用于实际用途中,当访问该链接跳转的 AppStore,则便会统计到具体的营销活动中。

但缺点也很多,比如:

1、只有当营销活动启动后超过一天时间(最长 72 个小时)后才能显示相关数据;

2、至少有 5 个 App 安装量(需要 5 个不同的 appID,首次下载该 App)归因于此营销活动时,营销活动才会在"App 分析"中显示;

3、iOS 8.0 及以上版本的用户可以选择是否将自己的应用使用情况的数据发送给 Apple;

4、iTunes Connect 的统计无法同时兼容 Android 和 iOS,采用不同的统计方法可能会让数据统一性较差。

5、只做下载统计,后续 App 打开以及用户在 App 内的操作行为,就无法获取。

方案实现:

想通过 web 端进行归因统计,最主要的点在于如何获取设备的唯一标识,安卓常用的 ID 有 IMEI、Android ID 等,iOS 则是 IDFA,这些在网页端目前都存在大量限制,所以只能通过获取其他信息,进行加密规则,产生一个唯一标识。

目前 web 端能够获得的设备信息包括:设备指纹,屏幕宽高、设备像素比、操作系统、操作系统版本、IP 和时间戳等。

这些信息信息只能在小范围推广,比如面向个人用户时区分一定程度的不同设备,但是真正做大范围推广时,由于同类型设备较多,准确率会大大下降。

二、接入第三方工具

自己捣鼓方案存在太多不确定性,比如方案精准度不够,而且沉没成本和维护成本都不是一般公司能承担的。参考国内一些专精渠道来源追踪的第三方公司,按照年收费标准大概一个月几百块,优点是精准度高(方案比较成熟),稳定性较强(有 24 小时的更新和维护),也适用于 App 端(iOS/android/鸿蒙)和 web 端,还适用于多种开发框架。

接入第三方工具的话,App 端和 web 端都需要接入相应的 SDK,用于传递参数、统计 App 的行为等分析。

这里以集成 openinstall 为例实现步骤:

1、在 openinstall 开发者平台创建应用,每个应用会默认生成唯一的 AppKey。

2、App 端(iOS/android/Harmony)SDK 集成。

由于 openinstall 采用零配置方案,并自动生成集成代码,开发者只需根据集成文档按步骤点击下一步,几分钟便可完成 SDK 集成。

3、测试阶段上传 ipa/apk 包,正式使用时配置应用市场的下载链接即可,上传安装包时,会自动读取应用的基础信息,比如包名等,上传完成就可以在线模拟测试,体验完整的 App 安装/拉起流程,待对外正式发布时,配置相应的应用市场地址即可。

4、在线测试

集成完毕并上传 apk/ipa 安装包后,可先使用 openinstall 提供的在线测试功能,确保 App 安装后能正确还原输入的动态参数,能正常的拉起 App。

5、Web SDK 集成

经过在线测试确认 sdk 集成正确的情况下, 开发人员可以开始在 web 分享页/渠道页上集成 openinstall web api,同样只需简单的复制粘贴即可。

6、添加渠道

将已经集成 web SDK 的公司网页添加到 H5 渠道管理这里,填写自定义 URL 的落地页,添加完成就生成一个渠道管理项,通过打开链接或者扫描二维码下载,就能实现渠道统计了。

在 App 启动安装时将自动获得渠道相关参数信息,可以通过接口发送给我们的服务器绑定渠道,做数据统计分析。

采用 openinstall 的 SDK,在 Web 端的归因统计数据更为准确,经过测试验证,同一台设备,通过不同的渠道链接或者 Web 网页链接访问并下载的 App,他们对该设备的唯一标识是一样的,即使切换无线网络和移动数据。

openinstall 基本原理

openinstall 的核心价值在于,帮助 Android/iOS 开发者精确的获取 App 每一次安装的分享(或推广)来源。

大致原理如下:

如今想要自建渠道来源追踪方案是比较困难的,毕竟移动端系统割裂程度大,隐私保护政策也是三天两头在调整,导致各种标识和方法经常迭代,自行打造一套高准确度的方案成本太高,如果预算充足可以采用第三方工具来一步到位,不必重复造轮子。

相关推荐
SuperHeroWu78 分钟前
【HarmonyOS】鸿蒙应用唤起系统相机拍照
华为·harmonyos·系统相机·photo·startability·camerapicker
恋猫de小郭12 分钟前
IntelliJ IDEA 2024.3 K2 模式已发布稳定版,Android Studio Meerkat 预览也正式支持
android·android studio
emperinter14 分钟前
WordCloudStudio Now Supports AliPay for Subscriptions !
人工智能·macos·ios·信息可视化·中文分词
stone519514 分钟前
鸿蒙系统ubuntu开发环境搭建
c语言·ubuntu·华为·嵌入式·harmonyos
AirDroid_cn2 小时前
iPhone或iPad接收的文件怎么找?怎样删除?
ios·iphone·ipad·文件传输
找藉口是失败者的习惯4 小时前
Jetpack Compose 如何布局解析
android·xml·ui
Swift社区8 小时前
在 Swift 中实现字符串分割问题:以字典中的单词构造句子
开发语言·ios·swift
#摩斯先生8 小时前
Swift从0开始学习 对象和类 day3
ios·xcode·swift
没头脑的ht8 小时前
Swift内存访问冲突
开发语言·ios·swift
#摩斯先生8 小时前
Swift从0开始学习 并发性 day4
ios·xcode·swift