数据分析模型—归因分析_技术分析

本篇讲述归因分析在实际业务中的应用及实现方法，主要讲解「渠道归因」和「运营位归因」的「单值传递归因」、「多值记录集合归因」、「时序还原归因」以及「路径还原归因」几个方法。

01 了解归因分析

随着互联网技术和业务的发展，广告投放相关的业务也随之兴起。那么广告投放的效果评估也就随之而来。

首先，广告的投放一般都是收费模式，所以选中的渠道商的好坏直接和自己的利益挂钩。于是，「归因分析」便最早应用在了广告投放行业。（归因分析能最先应用在广告行业还有一个原因，就是广告的目标是单一的。比如：无论多少个渠道商，最后推的都是同一款 App；但是若将在产品内部的运营位进行归因，就需要考虑这个广告位和商品是否有关系。）

举个例子：一款 App，投放了三个推广渠道，最后 App 通过某个渠道商完成了下载。此时，我们需要对这三个渠道商对本次下载的贡献能力进行一个评估。这时，就用到了归因分析。

02 渠道归因（站外归因）

渠道归因是目前市面上比较广泛的归因应用场景。

图中举例说明了一个渠道归因的大致流程和思路：用户分别浏览了「Youtube」「Google」和「Facebook」后下载了 App，通过归因分析来计算三个广告的贡献。

03 运营位归因（站内归因）

随着渠道归因的普及，从业人员逐渐认可了归因的计算方法和功劳的分配方案，虽然模型的不同会导致计算结果存在一定偏差，但是这些都在可接受的范围内。

后来，随着产品的复杂化、公司部门的事业部、业务线的划分。产品内部的运营位逐渐被广告化，于是运营位的归因需求逐渐被暴露出来。

接下来，我们来说一下运营位归因的演进历史。

1. 传递式单值归因

传递式单值归因是归因分析由渠道转向运营位时，采用的简单转化方案。当然这个方案，至今还在被一些公司沿用。该方案的优势：逻辑清晰、实现简单；劣势是：无法匹配稍微复杂的运营场景。

图中举例说明了一个传递式单值归因的大致流程和思路，由于技术的原因，在记录广告时，使用的是替换的策略——即每次只记录前一个广告，当出现新的广告则替换前一个广告名称，直到成单转化，记录在订单上。

用户分别浏览了「广告 A」「广告 B」和「广告 C」后购买了「商品 C」，通过记录最近一次广告运营位，来进行归因，计算运营位的贡献。

在互联网初期，人们的业务模式都比较简单、使用流程也很单一，使用前篇讲解的「单值传递归因」完全够用。

但是某一天，人们发现自己 App ，已经不再是简简单单的「广告 → 商品 →购买」路径，又多出来了很多其他的路径。比如：「搜索 → 商品 → 购买」、「推荐 → 商品 → 购买」或者「推送 → 商品 → 购买」，甚至是「红包 → 商品 → 购买」时，我们会发现，原来的那套逻辑，有一些过时了。

解决问题的办法也很简单，就是将原来的一个值，变为记录多个值。那么，我们就来推演一下后续每个版本的归因分析的实现的思路和计算方法。

2. 场景

我们假设一个场景，接下来三个模型的演绎都使用该场景进行还原。

首先，用户来到了一款电商类 App，打开首页，看到的是顶栏「搜索」「头部广告」腰部的「推荐商品」，其中「头部广告」是一个主广告，点击进去分为两个「分会场 A」和「分会场 B」的子广告，「推荐商品」动态计算，展示您最可能购买的商品。

接下来，一个用户开始使用我们的 App，行为如下：

进入首页，先行搜索，在列表页看到了商品 A运营数据分析模型，浏览了商品 A 的详情，觉得不错，但是并未购买；从详情页返回到首页，看到头部广告，点击进入到主会场页面；在主会场页面，看到分会场 A 和分会场 B，点击进入分会场 A，再次看到商品 A，点击再次查看商品 A 详情；页面返回到主会场页面，进入分会场 B，在分会场 B 中浏览了商品 B 的商品详情；直接退出到了首页，发现推荐位在推荐商品 A，进入再次查看商品 A 的详细信息；看到了推荐的评语，下定决心，购买了商品 A。

最终，我们想看每个运营位，对用户购买商品 A 这个决策带来的贡献。

3. 多值记录集合归因

由于业务变得复杂、来源增多，那么最简单的方式，就是由原来单值的记录形式变为多值。

再解决额外引入的几个问题，分别是：

为了避免无穷无尽的记录广告，以及将不属于这个商品的广告记录在这次购买中，需要引入一个重置的机制运营数据分析模型，比较简单的重置就是：App 冷启动、访问回首页和发生后支付就进行重置。记录下了广告的集合并完成了数据的采集，后期需要再进行逻辑的运算，来给每个广告位分配功劳。