本文长度为1870字,预估阅读时间5分钟。
引言:作者结合丰富实战工作经验,亲笔撰文分享了在APP渠道归因中监测厂商的4种常见解决方案。
作者 | 仲志成
编辑 | 华 子
APP渠道归因之痛
APP分析与网站分析最大的不同之处在于:在网站端完成渠道归因那是轻松简单加愉快,但APP的渠道归因却是个巨大无比的坑。这个坑有多大呢?有专门做APP渠道归因的公司,做到被巨头收购,成为巨头数据分析产品家族的一份子。
APP渠道归因这个“天坑”对于业务提升有什么负面影响呢?现如今,都是通过分析数据来驱动业务改进。业务改进过程中,不论是拉新,还是促活,都少不了使用渠道。可数都不准,还分析个P、驱动个6啊!
最悲催的是:这个“坑”是大环境造成的,不是哪个机构单靠技术方案就可以360度完美解决的。
监测厂商的4种常见解决方案
解决方案1:渠道包
给每个应用商店做一个渠道标记,称为“渠道包”。从该应用商店下载并激活的APP和用户的后续转化行为,全部归属于这个渠道。这种方法至少有两个缺陷:
解决方案2:Deep Share
Deep Share概念的文字特别绕,咱们直接上图。
简单的说,Deep Share就是在广告和应用市场之间,通过添加一个H5获取信息,并传递给服务器和APP;然后,通过匹配让APP获得UTM,后面和网站分析工具一样,不解释。
这种方法乍看上去没有渠道包的缺点,却也有3个问题:
PS:有传言说,这种方法的准确率在15%-30%,这里提出来只是给大家一个参考,思考一下问题1,为了这种准确率牺牲转化率值得吗?另外,准确的做法似乎仍在探索中,所以我是想不清楚这个说法具体是怎么来;也许是在网站端用这个方法折腾了一番,再和网站端的标准做法做比较吧。
解决方案3:One Link
为了方便大多数人理解,我就简单粗暴的说:One Link和Deep Share的唯一区别就是:H5那步是全自动的,这样就没有Deep Share的问题1了,所以从曝光到安装的转化率会略高一点点。但在其它方面并没有什么差别。
解决方案4:生态圈
谷歌、百度、腾讯等巨头,可以在自己的生态圈内,实现近乎完美的APP渠道归因。示意图如下:
我清楚的记得,当年某个Google的工程师得意洋洋地说:“因为都是我们谷歌的,所以弄个AdID就很‘流氓’的都打通了,你们羡慕不来。”
你把示意图中的内容换成百度和腾讯的对应产品,也一样。他们有一套统一帐号体系,用这个统一帐号作为key,像串糖葫芦一样把各端的数据串在了一起。
这种方法只在生态圈内奏效,跳出生态圈巨头也面临解决方案1和2中的问题。举个例子,你在头条投广告到豌豆荚,用百度移动统计监测,也照样归不了因。
APP渠道归因最佳实践探索
简单的说,APP渠道归因最佳实践 = Deep Share + User-id,示意图如下:
只要在H5能获取到User-id,就能和解决方案4有接近的效果了。关键点:
这样一来,APP渠道归因的关键是在H5上的User-id获取率。技术不再是问题,业务人员如何想方设法(给甜头)提高User-id获取率成为了关键。
后记
第一次,使用这个办法实现近乎完美的APP渠道归因,完全是个偶然。当时,我在数字营销代运营公司,客户是个靠电话销售驱动的公司。下载APP是那个H5 活动页的次要目标,主要目标是获取销售线索(用表单获得电话号码)。结果莫名其妙的体验了APP渠道归因的最佳实践,完全是“瞎猫碰上死耗子”。
后来,给其他人推荐这个方案时,有业务人员说:我这是摔锅,把技术该解决的问题,转嫁给了我们。关于这点我想说的是:
本文只是对APP渠道归因最佳实践的一个探索,相信未来会有更好的方法解决这个问题。我更期待整个大环境变得更好,让这个问题根本不复存在。