App用户增长归因方式全解析，附实操框架设计

人人都是产品经理 • 4年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

编辑导读：归因分析，指的是对不同渠道的广告的投放效果进行评估，并给出一个为什么要这么做的理由。本文作者从常见的几种归因分析方法出发，结合实操案例分享了App用户增长归因模型搭建的关键步骤和思考，供大家一同参考和学习。

一、需求和痛点

业务需求1：运营提了一个H5需求，做完H5后会找一些站外大V进行投放，希望监测到从每个大V进入H5页面的流量如何，以及带来多少新增用户。
业务需求2：运营希望测试微信群和QQ群的拉新效果，会将同一个H5链接或者某个内容的链接发到群里，希望检测到每个群内用户访问数据和新增数据。
业务需求3：自然新增的用户中，希望知道这些用户都是从哪里下载的App，以及初步分析为什么下载。

基本上关注新增用户的运营都会提以上三个需求，三个需求的本质都是新增用户的来源监测和动因分析。运营提出的这些需求背后都存在着一些痛点，甚至是行业痛点，简要描述以下三条：

痛点1：自然新增的用户因为不知道为何而来（动因），无法在App启动时做精准的新用户承接，对用户的活跃和留存影响较大；
痛点2：大量投放了广告，不知道每个渠道具体的广告效果，也找不出最佳的投放渠道，只能靠感觉投；
痛点3：H5场景下获取不到设备号，其他各种归因方式都存在各自的缺陷，很难做到100%归因。

二、常见归因方式

首先需要明确下载App可以通过哪些渠道，本文将渠道分为两个大类：

付费渠道：①In-App投放，②Wap投放，③短信。带来的新增用户定义为付费新增用户；
自然渠道：自然从应用市场下载，某个H5活动页，某个内容页面，定制下载页等等，非付费渠道均为自然渠道，带来的新增用户定义为自然新增用户。

无论是什么渠道，最终下载App大多数都会通过应用市场，ios进到App Store，小部分安卓会通过浏览器直接下载安装包（未被应用市场拦截），大部分安卓会到各自的应用商店。

App用户增长归因方式全解析，附实操框架设计

1. 设备号归因

针对付费渠道，特别是In-App投放，主要使用设备号归因，应用在信息流广告中。

这类归因目前行业内已经普遍在使用，也相对比较成熟。实现方式主要从第三方App获得用户的移动终端的设备号，即常见的 IDFA 和 IMEI ，第三方平台反馈给广告主的信息会包含设备号，当用户完成App下载激活之后，广告主可以对用户的设备号与第三方给到的设备号进行匹配，以此来评估投放效果以及归因分析。

App用户增长归因方式全解析，附实操框架设计

2. 渠道包归因

渠道包归因主要应用在安卓端，将定义好的“渠道号”写入到APK安装包中，然后投放到指定渠道，用户下载和激活App后可以从安装包中读取到渠道号，以此来进行归因。

但渠道包归因存在两个较大的弊端： 其一是很容易被手机原装的应用商店拦截， 原装应用商店为了提高下载量会识别用户即将下载的安装包对应到应用商店是哪个，识别到时会进行拦截，强制用户去应用商店下载；其二是如果使用付费投放方式， 渠道包归因很容易被不良渠道方刷量， 数据作弊导致真实效果无法评估。

基于以上两个弊端，渠道包归因主要作为自然渠道的补充归因，很少作为付费渠道的主要归因。

3. 剪贴板归因

剪贴板归因目前是Out-App场景下最有效的归因方式，可以将唯一标识写入剪贴板，作为H5场景无法获取设备号的替代方案。

主要实现方式：用户在站外点击下载坑位，将唯一标识写入剪贴板，用户下载并激活App后，客户端读取剪贴板内容，符合规则的上报服务端（或者全部上报由大数据进行清洗），同时连带设备信息等一并上报，用于判断是否是新增用户。

剪贴板的优势在于唯一标识口令可以非常灵活，里面可以包含用户点击的是哪个坑位，访问的是什么内容，用的什么浏览器等等，前端能够采集到的信息都可以封装成口令放入剪贴板。

但是剪贴板也不是万能的，网信办一直三声五令禁止读取用户剪贴板，属于用户隐私信息。同时，基于安卓深度定制的机型很多禁止应用读取剪贴板，这让剪贴板归因是效率有所降低，根据经验推断Out-App场景的归因多种方式组合上限能够归因70%。即便如此，剪贴板仍然是目前设备号归因之外最高效的归因方式。

4. IP+UA归因

IP+UA归因是指用户点击下载坑位时，采集用户的IP和UA（User-Agent，包含用户的操作系统、手机型号、浏览器信息等等），与激活App时用户的IP和UA进行匹配，以此达到下载归因。

这种归因方式属于模糊匹配，相对于前三者没有唯一的标识与客户端和服务端进行通信。同时，IP在公共网络环境下是同一个，IP和UA也很容易随着环境发生变化，因此归因效率最低。举个例子：用户在wifi环境下下载了App，但是在4G环境下才激活App，这时候IP是不一样的，而UA很可能存在两个完全一样的机型，这时候就无法通过IP+UA进行归因。

5. 小结

三、灵活归因框架设计

1. 灵活采集，多方式归因

针对设备号归因的场景，目前行业内已经有非常成熟的方法，在此不再赘述，以下仅针对Out-App场景的归因进行叙述。

为了满足文章开篇的三个需求，需要在数据采集时候支持灵活变化，以及配合埋点上报访问和点击行为。因此必须在URL后面加上特定的字段用于标识不同的场景（定义为“渠道号”，渠道号可以自由定义和扩展），针对不同的场景进行投放，每个渠道号都对应各自的渠道包，用于渠道包辅助归因。

埋点层面： 比较合适的做法是从URL中取渠道号存在本地，访问及之后的点击行为都从本地取渠道号进行上报（同时上报IP+UA），如果后面有发现渠道号发生变化，则更新本地存的渠道号。这样做的好处是用户后续所有的行为都可以依据本地存储的渠道号进行上报，结合新增归因就可以制作出访问——点击——激活这样的新增漏斗。

归因层面： 采用剪贴板归因为主，渠道包归因为辅，IP+UA归因作最后填充的方式进行。在Out-App场景下H5无法采集到用户的设备号，设备号归因这条路直接堵死，剩下三种方式可以集成起来全部使用。具体流程如下：

采集：需要一个JS-SDK，用于采集用户的IP、UA、URL的渠道字段、内容字段（活动id、内容id之类的信息）等其他信息，将这些信息汇总成一个口令放入剪贴板，同时SDK上报采集的信息到服务端。

匹配：用户安装并启动App时，客户端将剪贴板内容、用户IP+UA、以及客户端采集到的设备信息传给服务端，同时通过埋点上报给大数据一份。服务端判断是否为新增用户（通常会使用设备首次启动App时间进行判定，同时也会使用设备最近一次启动App时间判定是否是召回用户）。

判定是新增用户，若剪贴板有口令，则记录所有信息；若无口令，判断是否为渠道包，若为渠道包则解析渠道信息进行记录；若无口令且非渠道包，则将IP+UA与SDK采集的IP+UA进行匹配，定义一个时间范围两个IP和UA相同，认定为新增用户。