转自首席数据科学家

“ 来源渠道的分析是APP数据分析的基础，渠道来源监测是来源渠道分析的前提。”

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

01

—

场景概述

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

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

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

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

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

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

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

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

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

02

—

预置推广渠道

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

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

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

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

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

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

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

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

03

—

Server to Server 回传

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

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

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

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

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

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

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

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

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

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

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

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

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

04

—

第三方监测工具

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

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

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

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

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

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

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

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

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

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

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

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

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

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

05

—

手动填邀请码

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

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