如何用算法解决流量归因问题？

本篇分享一个实用系数100000000的算法：基于埋点的来源回溯。
1. 什么是来源回溯算法？也可以称它为解决流量归因问题的算法。
流量归因是电商运营中非常重要的一步，每件商品都是从哪些广告位置卖出去的？常用来做广告投放决策，不同商品的不同运营区域决策等。
2. 为什么要做来源回溯？在数据记录非常完备的情况下，计算流量归因是非常简单的。
但真实的情况是大部分企业不具备完善的业务埋点能力，其难点在于数据集成处理，因此我们需要一套算法在已有数据基础上实现流量归因。

接下来围绕两个问题展开：
1. 流量归因分析的几大难点
2. 如何基于已有的数据质量，实现来源回溯算法？

一、流量归因分析的几大难点

1. 从APP流量分布开始
什么是APP流量分布？即在APP上每个按钮或者功能的使用人数，便于我们了解用户的使用习惯以及需要重点运营的模块，可视化呈现如下图所示：

这时候有朋友会说：“这不就是简单的数据统计group by+count嘛！”
那真实情况如何？为什么如此简单的流量分布，众多企业没有成型的数据体系？

究其原因有3个：
1> 用户行为记录（APP埋点）存在大量不标准数据：
缺少埋点，如：不同操作系统由不同开发人员实现，存在大量的不统一操作，iOS有埋点、安卓无埋点；
字段错位，如：不同版本数据埋点不统一，页面名称信息上一版本记录在page_name中，最新版本记录在screen_name中，以及同一版本不同功能页面名称记录在多个字段中；
字段层级混乱，如：访问入口的不同层级首页、活动页、商品详情页记录在同一个字段中；
2> 由于APP功能由多位产品经理设计，每个人对埋点规范的理解不同、对数据的依赖程度不同以及各个产品功能的特殊性，就可能导致数据记录的无限拓展与不规范；
3> 从需求方角度，运营人员/产品经理更多是独立负责一部分功能或业务，会更关注单一线条的纵深表现（也可能是对数据资源的调动能力受限），因此全局的流量分布需要由运营总监/产品总监/CXO来发起，清晰定义流量分布的具体点位。

如果基于这样的数据资源计算流量分布，group by之后的结果就是：数据准确性与可读性较差，无法作为决策依据。

2. 要如何解决呢？
编者在做这件事的时候，没有高深的方法，只是采用了最费力最靠谱的方式：
1> 在APP点击各个需要分析的按钮，并在草稿纸上记录下自己的点击行为；

2> 去数据库找到相应的数据记录，对每一个点位写独立的筛选条件；
3> 对比数据记录下来哪些需要自埋点、哪些采用全埋点，哪些缺少埋点，并严格筛选操作系统+版本号；
4> 对点位数据做模块定义，一类是Tab点击，另一类是Tab内按钮点击；

# R语言code参考：Tab1、Tab2、Tab3、Tab4、Tab4-客服按钮、Tab4-设置按钮
data_sensor$Tab[(data_sensor$event=='click' & data_sensor$button_area=='底部Tab' & data_sensor$button_name=='1')]<-'Tab1' data_sensor$Tab[(data_sensor$event=='click' & data_sensor$button_area=='底部Tab' & data_sensor$button_name=='2')]<-'Tab2' data_sensor$Tab[(data_sensor$event=='click' & data_sensor$button_area=='底部Tab' & data_sensor$button_name=='3')]<-'Tab3' data_sensor$Tab[(data_sensor$event=='click' & data_sensor$button_area=='底部Tab' & data_sensor$button_name=='4')]<-'Tab4'
data_sensor$button[data_sensor$event=='$AppClick' & data_sensor$`$element_content`=='客服']<-'Tab4 客服'
data_sensor$button[data_sensor$event=='Click' & data_sensor$screen_name=='我的'  & data_sensor$button_name=='设置']<-'Tab4 设置'

5> 写SQL统计各个点位的点击人数，以及相应的点击率。

这种做法有几个需要注意的细节：
a) 未确认全部系统和版本的埋点一致的，需要筛选指定的操作系统+版本号；
b) 需要与研发/产品/运营人员确认：是否存在同一版本APP，同时存在不同的产品界面情况；
c) 确认哪些是经常变改动的点位，建议做可自动更新的逻辑。

3. 回到流量归因分析的数据上，就有一些埋点记录的要求：
1> 有清晰的来源入口定义；
2> 有规范的数据来源记录（一个是有、一个是规范）。

如果没有，怎么实现呢？接着往下看。

二、如何基于已有的数据质量，实现来源回溯算法？

这是我们希望实现的数据处理结果：在数据记录中，标识用户是从APP哪个入口访问到了这个商品、以及是否下单等行为。

实现的基本逻辑是：给数据打模块标签，无标签的数据行进行逆时序回溯最近一个标签。（来源回溯之所以称为来源回溯，正是因为它采取了逆时序追踪的方法。）
具体实现步骤：
1> 获取用户全量的行为数据，导入至数据处理平台；
2> 基于APP流量分布中定义的模块，给所有可以标记的模块的数据行打标签，如图中"label"列；

3> 给没有模块标签的行计算模块，也就是对图中"label"列为空的行（如：用户点击商品23277我们是无法判断从哪里点击的），实现图中"label_2"的效果；
4> "label_2"生成逻辑：若"label"非空，则"label_2"="label"，若"label"为空，则用该用户最近的一个"label"非空值作为"label_2"；（由于行为数据的数据量非常大，写for循环的处理效率不高，coding能力就是下一个难点了。）
5> 生成新列"label_2"后，可以找几个用户的行为数据，检验回溯的标签是否正确且合理；
6> 统计各类流量归因，无论是商品详情、商品加车、活动页，还是首次访问、末次归因，一段SQL轻松实现！
结果示例：活动页A的流量来源模块数据

以上是本篇的全部内容，如有描述不清晰之处或有任何建议，欢迎留言或私信！