【实战篇】APP渠道归因最佳实践探索

作者 | 仲志成

编辑 | 华   子

APP渠道归因这个“天坑”对于业务提升有什么负面影响呢？现如今，都是通过分析数据来驱动业务改进。业务改进过程中，不论是拉新，还是促活，都少不了使用渠道。可数都不准，还分析个P、驱动个6啊！

最悲催的是：这个“坑”是大环境造成的，不是哪个机构单靠技术方案就可以360度完美解决的。

1. 如果这个应用商店是通过多个广告引流的，无法分辨具体是哪个广告；类似一个广告的多个定向条件分别效果如何，亦无法分析；只能汇总，不能细分，不能细分≈不能分析。
2. A手机通过类似茄子快传的工具，直接复制粘贴B手机APP时，A的渠道会被记录和B一样；这样归因说服力不足。

简单的说，Deep Share就是在广告和应用市场之间，通过添加一个H5获取信息，并传递给服务器和APP；然后，通过匹配让APP获得UTM，后面和网站分析工具一样，不解释。

这种方法乍看上去没有渠道包的缺点，却也有3个问题：

1. 让用户旅程多了一步，漏斗多了一层，增加了流失的可能；为了获取数据在一定程度上牺牲了从曝光到安装的转化率。
2. 用户在应用商店里的行为是个“黑盒”，不可知；导致这个方法存在匹配率或者说准确率问题。
3. 天朝有IP漂移，使问题2变得更加严重。

PS：有传言说，这种方法的准确率在15%-30%，这里提出来只是给大家一个参考，思考一下问题1，为了这种准确率牺牲转化率值得吗？另外，准确的做法似乎仍在探索中，所以我是想不清楚这个说法具体是怎么来；也许是在网站端用这个方法折腾了一番，再和网站端的标准做法做比较吧。

我清楚的记得，当年某个Google的工程师得意洋洋地说：“因为都是我们谷歌的，所以弄个AdID就很‘流氓’的都打通了，你们羡慕不来。”

你把示意图中的内容换成百度和腾讯的对应产品，也一样。他们有一套统一帐号体系，用这个统一帐号作为key，像串糖葫芦一样把各端的数据串在了一起。

这种方法只在生态圈内奏效，跳出生态圈巨头也面临解决方案1和2中的问题。举个例子，你在头条投广告到豌豆荚，用百度移动统计监测，也照样归不了因。

只要在H5能获取到User-id，就能和解决方案4有接近的效果了。关键点：

1. 必须有H5，不能像One Link那样自动跳过。
2. 在H5就让用户注册（获取User-id），并且这个注册帐号就是用户在APP中的帐号。
3. 如果用户不注册，该方法和Deep Share一样。

这样一来，APP渠道归因的关键是在H5上的User-id获取率。技术不再是问题，业务人员如何想方设法（给甜头）提高User-id获取率成为了关键。

后来，给其他人推荐这个方案时，有业务人员说：我这是摔锅，把技术该解决的问题，转嫁给了我们。关于这点我想说的是：

1. 虽然我学软件工程的，但“遇见”APP渠道归因最佳实践的时候，我是数字营销项目经理，是个做业务的；我要解决的是业务问题，技术只是其中一个手段而已，并不是全部。
2. APP渠道归因是切实落地数据驱动必不可少的一个环节，是整个企业整的事情，而不是靠哪一个部门、工种或者个人的。
3. 我经常和朋友说：什么时候用数据和office一样，是企业里每个人都必须掌握的基础技能，什么时候再说数据驱动。

本文只是对APP渠道归因最佳实践的一个探索，相信未来会有更好的方法解决这个问题。我更期待整个大环境变得更好，让这个问题根本不复存在。