App投放增长：归因模型及框架介绍

 

广告界一直流传着百货业之父约翰·沃纳梅克(John Wanamaker)的名言，“我知道广告费有一半浪费了，却不知道被浪费的是哪一半”。为什么说“不知道被浪费的哪一半”，究其原因无非就是无法衡量广告流量带来的转化效果。“流量”和“转化”一直是围绕App投放增长的两个关键词，在投放过程中，广告主经常搞不清楚 “投放的钱花到哪儿去了？哪些渠道的效果更好？哪些ROI不高？下一阶段广告预算怎么分配更合理？”等一系列的问题。

每个广告主都希望在预算有限的情况下获得最大的广告投放收益，将预算花在刀刃上，实际上这些问题都跟广告归因模型和逻辑息息相关。

因此，了解归因模型与逻辑，是每一位广告主/产品/运营的必备技能之一。

背景

归因是一件非常复杂的事情，因为一个现象的发生，背后可能有成千上万个影响因素。我们所要做的，就是通过归因找到几个最关键的因素，然后在这些关键因素上逐步提高。

归因核心要领：大胆推测，小心求证。大胆推测，就是把所有可能性及关键路径都罗列出来。小心求证，就是基于结果去验证整个链路的每一个可能性，找出可能性最大或者最具有说服力的那一个。

咱们来假设一个场景：假设我在OTT上用腾讯视频看电视剧的时候，看到了一则商品A的前贴片广告，然后在我的PC上用百度搜索了商品A的信息，点击了其付费广告后到达了商品A的详情页，了解该产品的相关信息。

第二天的早上，觉得商品A特别适合自己，又用手机浏览器进行了搜索，通过点击其付费广告，跳转到了应用市场，让我下载安装购物App。

App下载安装完成之后，我忘了打开App进行购买。晚上用手机继续追剧的时候，在爱奇艺App上看到了该商品广告，点击广告，唤醒了后续App进行激活注册。

然后在购物App内进行搜索该商品，看到了该商品在App内的搜索竞价广告，点击广告，来到商品详情页进行了下单购买。在商品A的订单详情中发现了配套商品B，最后也一起购买了。

好了，现在我们来梳理下我的这次购物旅程：OTT广告 -> PC上的付费搜索广告 -> 移动端付费搜索广告 -> 应用市场 -> 下载购物App -> 移动端OTV广告 -> 唤醒购物App -> 激活购物App -> 购物App内付费搜索广告-> 商品A下单 -> 同时购买了商品B。

整个购物旅程非常长，那么问题来了，在这种情况下要将最后的两笔订单归因给哪个广告活动呢？

同时带来的下载激活（拉新）又该归因给哪个渠道呢？接下来的这一切，就跟归因有关了。

归因，讲究”因”和”果”，我们先来分析上面的购物旅程case中的相关因和果。

因：通常指在广告投放时，用户了解到商品的触点，这些触点包括曝光、点击或者其他任何能触达用户的方式。主要回答以下问题：

• when：什么时间？
• who：什么人？
• where：在什么渠道、什么设备上？
• what：做了什么事？

果：通常指广告主通过广告投放期望给其带来转化效果的事件，例如本case中的下载激活购物App，购买广告中的商品A，以及同时购买商品B。

“因”和“果”都有了，接下来我们正式开始介绍归因的相关方法论。

用户标识

在这次购物旅程中，用户一共跨越了OTT、PC、移动端三端。在这三端上，虽然都是同一个真实用户（生物标识），但是在程序化广告投放中，我们需要通过不同的特征来标识同一个用户。

OTT

OTT（Over The Top）广告，是指基于开放互联网的视频服务，终端可以是电视机、机顶盒等等。目前OTT设备的系统主要是Android，当时也不排除Apple TV。在Android平台，OTT的设备标识主要是MAC，在TVOS（Apple），设备标识主要是IDFA。

PC

PC端广告，由于其获取不到设备相关的信息，因此用户的标识主要是IP+UA。也有通过cookie来标识用户的，但这样的需要进行cookie mapping。

Android

移动端广告，Android端常用的设备标识主要是IMEI、OAID、MAC、AndroidId，归因优先级IMEI>OAID>MAC>AndroidID。由于在Android Q版本之后，安卓系统已经不支持IMEI的获取，所以目安卓的设备号主要是基于OAID。这里提一点：不同厂商的OAID格式是不一样的，使用时需要注意。

IOS

移动端广告，IOS端常用的设备标识主要是IDFA、IDFV、CAID，归因优先级IDFA>CAID>IDFV。在IOS14之后，出于对用户隐私进一步的保护，IDFA的获取需要由用户明确授权，导致IDFA的获取率变低。各大主流媒体也同步出了应对方案，基本上都是CAID，但是集成CAID SDK的App在提交苹果审核时会被拒绝。

归因逻辑

用户标识讲清楚了，接下来我们聊聊归因逻辑。想要将“果”归到哪个“因”，归因逻辑起到了决定性作用。行业内常用的归因逻辑主要包含以下几个：

首次互动模型（first Model）

首次互动模型强调的是第一次互动对用户带来的影响，不管后续再发生任何行为，将转化结果都归因到能够建立连接的第一次互动渠道中。

但是该模型可能存在用户行为周期过长，导致预测不准确等问题，因此这种模型适合新品牌在品牌建设或产品推广初期，打造知名度。

在上述购物旅程中，通过首次互动模型逻辑，激活下单的转化会归因给“移动端付费搜索广告”。其实用户真实的首次互动发生在OTT端，但是OTT端和移动端的用户打通比较困难，如果能够打通，那么本次的转化可以归因给“OTT广告”。

最终互动模型（Last Model）

最终互动模型强调的是最后一次互动为用户带来的影响，不管前面发生任何行为，将转化结果都归因到能够建立连接的最后一次互动渠道中。

但是该模型存在的一个显著问题是误刷、盗刷。通过不断的模拟互动行为，将其他渠道的流量统一刷成自己的转化。在上述购物旅程中，通过最终互动模型逻辑，激活下单的转化会归因给“移动端OTV广告”。

所以这种模型适用于转化路径少、周期短的业务，或者说，广告目的就是引导用户购买，往往临门一脚才是最关键的。

平均分配模型（Average Model）

平均分配模型强调的是用户在整个旅程中的所有互动行为都需要被记录并分析，因此最终的转化结果应该平均归因到每一个环节。它适用于广告主期望在整个旅程内保持与用户的联系，并维持品牌认知度的公司。在这种情况下，各个渠道在客户的考虑过程中，都起到相同的促进作用。但是这种归因模式的问题在于无法区分不同渠道的效果好坏。

时间衰减模型（Time Decay Model）

时间衰退模型认可用户最终的转化受整个旅程中每一个行为影响，但是强调越接近转化的时刻的行为影响越大。该归因模型是平均分配模型的升级版。该模型适用于用户决策周期短、销售周期短的情况。比如，做短期的促销，就打了两天的广告，那么这两天的广告理应获得较高的权重。

自定义模型（Customized Model）

自定义模型强调的是可以将最终的转化效果自定义归因给转化链路上的每一个渠道，在使用时需要针对不同的渠道设置比例。该转化模型的问题在于如何针对不同的渠道设置比例，需要有强大的数据分析能力来支撑整个模型，需站在公平公正的角度，防止引发灰产。

小结

虽然每一种归因模型都有各自的优缺点，在使用时，只要选择的模型是符合业务场景的，同时针对所有渠道是公平公正的就可以，毕竟凡是参与过转化流程的渠道都是能给用户带来一定影响的。

归因窗口周期

除了归因模型，归因窗口周期同样也会影响最终的转化结果花落哪次广告投放。所谓的归因窗口周期就是指当用户发生转化时，应该往回追溯多长时间的“因”时间，这个“多长时间”就是归因窗口。不难理解，任何一次转化结果都需要往前追溯时间周期，时间周期设置的不同，所能够参与的“因”也不同。

那么这个窗口周期该设置为多长？一般来说归因窗口的正确周期应根据推广活动的目标确定，不同的推广活动，归因周期是不一样的。即使是同一个推广活动，在不同的平台进行推广，归因窗口周期也是不一样的，比如PC端和App端。这个大家可以结合各家的平均转化流程来制定不同的窗口周期。

归因方法

用户、模型、窗口周期都讲明白了，接下来我们讲讲如何将这些“因”事件和转化结果关联起来。常见的归因主要包括如下几种：

唯一设备号归因

针对In-App投放，主要使用设备号归因，前提是设备号是唯一的且在不同的场景中能够关联起来。当用户产生交互行为时，例如曝光/点击广告，广告平台获取设备的设备号，通过监测链接将设备号回传给广告主。当用户在广告主侧完成转化行为时，广告主的数据分析平台可以基于设备号来匹配用户在投放渠道上发生的广告行为，以此来衡量和归因分析不同渠道的投放效果。

IP+UA归因

IP+UA归因由于没有设备的唯一标识，因此属于模糊归因，是用来补充当获取不到设备号的一种归因方式。它的归因原理与设备号归因类似，是指用户发生广告交互时，采集用户的IP和UA（User-Agent，包含用户的操作系统、手机型号、浏览器信息等等），与转化时用户的IP和UA进行匹配，以此达到转化归因。

渠道包归因

渠道包归因主要应用场景是在安卓端，将事先定义好的“渠道号”写入到APK安装包中。

在广告投放时候，投放的下载链接是带“渠道号”的App包链接，当用户下载和激活App后可以从安装包中读取到渠道号，以此来进行归因。

这种归因方式简单，不受限于设备号的获取，但是该方式存在安装包覆盖问题：安卓手机一般都会带有系统级别的应用商店，指定“渠道号”的安装包很容易被应用商店拦截，强制用户去应用商店下载，导致最终的转化效果都被归因到了应用市场的安装包。

为了防止出现这种情况，这里就会引申出防覆盖问题，在后续文章中会有介绍，先插个眼。

Scheme归因

Scheme归因是指在媒体App内点击广告，通过scheme链接唤醒广告主目标App，此时的scheme链接带有相关的业绩参数。

当用户发生转化行为时，匹配scheme上的业绩参数，以此达到转化归因。该归因方式的使用场景在于拉活，因为其依赖用户已安装广告主推广App。

针对App内投放，PC和H5也可以引申出落地页归因，即在广告投放的落地页链接拼接相关业绩参数，这样用户在发生转化时，广告主侧也可以获取到落地页上的业绩参数进行归因。

剪贴板归因

剪贴板归因是指当用户在H5环境进行广告交互时，将本次交互行为的唯一标识写入剪贴板，后续用户发生转化时，通过读取剪贴板内容以此来进行归因。

该归因方式存在的问题是用户隐私问题，毕竟工信部一直在严查涉及用户隐私的相关操作。

小结

作为不同的归因方法，核心点主要是在于如何将“因”和“果”通过唯一标识关联起来。

这个唯一标识可以是设备相关信息，也可以渠道包信息，也可以某一次广告投放的唯一标识，只要在用户广告互动和转化发生时都可以快速采集到该唯一标识即可，采集到的唯一标识可以存储在本地，也可以存储在底层数仓。

归因框架设计

在整体方法论介绍完之后，接下来给大家讲讲归因框架的整体设计，看看一次完整的归因需要设计哪些模块。

上图基本为一次完整的广告互动到转化归因的流程，其中标注了1-6点，下面我们来拆解下这6点对应的模块。

监测模块

监测系统对应上图中的1，该模块主要通过链接的方式收集用户的互动行为，链接收集的参数取决于不同广告平台支持的宏替换参数，常规参数为：设备号、时间戳、IP+UA已经涉及广告投放的一些参数。

监测链接收到数据后，存储在底层数仓，当后续发生转化行为时，通过去数仓中匹配对应的互动行为数据。

Scheme链接

Schem链接对应上图中的2，该模块主要的功能在于唤醒App至指定页面和记录唤醒业绩参数。

当目标App被唤醒时，唤醒业绩参数被存储在本地；当用户发生转化时，通过读取本地的参数，一起下发给下游转化归因服务，基于此进行Scheme归因。

这里需要注意一点：在将业绩参数存储至本地时，需要进行参数校验，对于不合法的参数需要舍弃；同时需要结合归因逻辑，例如首次互动模型，仅需存储一次即可。

安卓打包模块

安卓打包模块对应上图中的3，该模块的作用在安卓渠道包的打包和管理，输出渠道包的APK文件。

JS-SDK模块

JS-SDK的对应上图中的5和6，该模块的作用主要是打开H5页面时，通过JS-SDK记录内容，并将相关内容写到剪贴板和cookie中。

记录的内容包含但不限于IP、UA、URL链接、唯一广告ID等。当用户打开App时，不论是激活还是唤醒，都可以读取读取对应的剪贴板内容。根据对应的内容，展示不同的内容。

活动配置模块

针对当用户打开App时，配置用户呈现的页面。可以通过关联监测链接和剪贴板内容来实现场景还原或者互动定制。

该模块比较重要，用户进入App的第一个页面直接关系到用户的转化，在这一块可以配置相关一些相关策略，展示给用户最感兴趣的内容。

比如展示用户看到的广告产品，所见即所得；针对新用户展示专区内容，提升首单可能性等…

归因模块

归因模块是整体框架中最重要的一个模块了，归因模块主要是归因策略的管理和归因结果展示。

对不同的场景可以配置不同的归因策略；将归因后的结果通过数据报表进行展示。

总结

本文从用户标识、归因逻辑、归因方法、时间窗口维度介绍了归因体系，同时给出了一个大概的归因框架设计。

 

作者：包子

来源公众号：商业化产品日常笔记