下载追踪：如何监测APP的来源渠道数据

关于流量渠道监测，我们之前分享过《流量追踪：如何通过 URL 参数进行数据采集》。文章详细介绍了如何通过 URL 中加 Tag 的方式进行渠道、媒体等投放的数据采集与区分。

今天，我们在之前文章的基础上，聊聊关于 APP 的下载具体是由哪个渠道带来的，这相关的数据是如何进行监测获取的。

01

—

APP 的下载，究竟是从哪个渠道来的，这个问题很复杂吗？是的，确实有点复杂。

通常来讲，APP 的推广流量是指向了应用市场。按照 URL 中加 Tag 的方式，到了应用市场以后，APP 的来源信息就断掉了，因为应用市场不会给 APP 提供监测脚本的服务。

这相当于，各个渠道吸引来的用户，都汇集到了应用市场，但是渠道数据传输到应用市场的时候，被应用市场给强行打断了，没有把渠道数据给到 APP 方。那 APP 自然就不知道每次用户的下载究竟是哪个渠道带来的效果了。

对于 APP 而言，想了解自己投放的 APP 广告带来的下载情况，有 4 种常见的方法：

• 预置推广渠道：不同渠道不同安装包；
  

• Server to Server：媒体将数据回传给广告主；

• 第三方监测工具：Link Tag 宏替换

• 手动填写：以邀请码的形式追踪
  

下面我们详细聊聊每种数据追踪方法的具体细节。

预置推广渠道

这个其实非常好理解，也是用得比较广泛的一种方法。

核心逻辑就是把推广渠道相关的信息固化在 APP 的安装包中。如果有 5 个推广渠道，那么就做 5 个不同的 APP 安装包，上传到对应的应用市场。这里所谓的「不同」，其实绝大部分内容都是完全一样的，只是其中的渠道信息 Channel_id 不同。

很明显，这种方法的局限性很强。

一方面，如果多个广告链接到同一个应用市场的话，就无法辨别是哪个广告带来的下载（因为一个应用市场只能上传一个 APP 安装包），而且如果 APP 安装包被直接复制到其他的推广渠道，就会增加该渠道的下载量，导致监测不准确。

另一方面，如果渠道数量过多、版本更新频繁、需要在多个平台做推广的话，这种打多个包的方式就非常消耗人工的效率了。尤其是每次发新版，需要重新给各个渠道制作新的渠道包，才能实现相应的数据统计。

当然，市面上有一些专门的打包工具，用以进行多渠道打包。但是过程仍然比较麻烦，而且管理成本较高。

另外，这种方法对 iOS 也不适用。因为 iOS 基本应用市场都是收口在 App Store 里了，不像 Android 有多个通道可供上传下载 APP：手机厂商的、第三方应用的。

虽然局限性很强，但是这种方法仍然被采用。主要原因就在于简单，不需要第三方监测工具的介入，也不受媒体投放端的制约。

Server to Server 回传

所谓的 Server to Server 回传信息，就是媒体端将点击广告的用户数据以 API 或者底表的方式，发送给 APP 推广的广告主。因此需要媒体的支持才行。

媒体回传广告主的数据都有哪些呢？

一般而言，媒体上传的主要是广告投放信息、用户身份信息（设备 ID、IMEI、IDFA 等）、行为信息（曝光、点击）等；而广告主侧，一旦该用户成功安装了 APP，那么 APP 就能获取该用户的设备 ID，结合媒体回传的数据，就能和之前的点击、曝光等事件完成归因匹配了。

回传 ID 的优点主要有两点。

第一，可以进行明细用户维度的洞察与效果分析。比如可以结合其他数据进行用户画像、可以分析投放效果等。如果不回传明细 ID，那么广告主只能看整体的大的统计数据，不能做明细的用户分析。

第二，可以进行再营销。拿到了 device ID，可以在其他的渠道继续进行投放。多次触达的用户的转化率正常情况下一定是会提升的。

其实，大部分的广告投放都不会给广告主回传 ID，一般能支持回传的媒体都是比较大的媒体平台。比如下面的巨量引擎：

这里整体的步骤包括了三步：

• 第一步：用户点击广告，头条将收集到的广告展示点击等行为通过监测链接发送给客户

• 第二步：广告主收到的信息与自己监测到的用户转化目标相关的信息进行匹配

• 第三步：将匹配成功的转化信息发送至头条的回调地址

也就是说，字节与广告主的数据交互是双向的，广告主接收到点击数据后把后续的效果数据也要回传给字节。字节用这些数据进行相关的扣费、挖掘等。

在个保法施行（具体影响查看历史文章）的大环境下，用户的数据隐私问题愈发敏感。另外，数据作为媒体的数字化资产，肯定也是不愿意将 ID 信息回流给广告主的（很容易造成用户流失，被竞争对手洗过去）。但是为了广告收入，尤其是效果类广告，还是会回传。最终就看媒体端和广告主端的博弈了。

第三方监测工具

上面的方法，是媒体和广告主直接进行数据交互。除了上文提到的优缺点外，还存在一个比较大的短板，就是需要一家家媒体接入。

比如我在百度、巨量、微博等渠道投放了广告，如果是采取上述的方式，需要广告主分别收集不同媒体的数据，分别开发，这就效率有些低了。而通过第三方监测工具，能比较高效解决该问题。

总体而言，媒体投放端和广告主都是将数据传送给了第三方工具，由第三方工具进行专门的数据匹配工作。如下图：

这里的技术产品过程比较好玩，咱们详细来聊一聊。

我相信很多朋友在微信或者其他 APP 中点击广告，如果下载的话，都会遇到个这种流程：

上图是在百度中搜索某关键词，在曹操出行的官网中点击「立即体验」后，跳转到了图三的页面，几秒后会自动跳转到 App Store。

大家有没有一个疑惑：为啥有图三这个环节，直接点击官网中的 button，跳转到 App Store 进行下载不好吗？是技术上实现不了吗？

技术上还真的能实现，因为本质上就是一个 URL 的链接跳转。那为啥各个 APP 下载的时候，基本都会有这么个中间页呢？答案就是为了数据追踪。

上文中也提到了，所有指向 App Store 的链接后，用户下载了 APP 以后，App Store 并不会把来源告诉 APP 广告主，因此做不了来源的追踪。而广告主投放的媒体渠道可能有很多，都和第三方监测平台进行打通，也是不现实的，但是可以通过一个集成了 SDK 的 H5 页面作为跳板，收集渠道数据，上传到第三方的服务器，然后与广告主端 APP 中的数据进行匹配，则可以实现渠道的溯源。

因此，广告主在每个渠道投放的链接跳转是相同的（都是到中间页），但是链接参数 tag 不同，可以区分来源渠道，并且可以通过该中间页收集设备 ID 信息。然后通过 URL 链接的跳转技术，跳转到应用市场。

详细的产品流程示意图如下：

对于已安装 APP 的 H5，会直接拉起 APP。

另外，第三方监测平台会提供链接生成、渠道管理、效果统计分析等一系列的服务，如下示例：

另外，由于第三方监测工具是采集了各个媒体的数据，因此可以基于比较全面的用户行为数据，进行一定的归因逻辑，而且相对而言比较中立。

手动填邀请码

最后，还有一种能追踪来源的方式，就是在下载 APP 以后，让用户手动填写邀请码。

这种是肯定可以获取到该用户的来源的。不过一般适用于群体推广，不合适大规模广告投放情况下。毕竟用户不会主动填写来源信息，只有在激励的情况下，才有动力。

好了，关于 APP 下载如何进行数据追踪，就分享这些内容吧~欢迎加我微信交流。