干货电商归因模型技术方案

Posted 2021-09-07 艾华丰

作者介绍

@杭州阿坤

母婴电商行业数据分析师兼数据产品经理；

致力于研究电商行业的数据驱动增长，

以及数据产品从0到1的搭建；

“数据人创作者联盟”成员，“最佳创作奖”获得者。

 

01 电商归因目的

对于电商平台来说，当流量进入时，我们需要引导其完成购买任务，以实现流量价值最大化，在互联网红利消耗殆尽之时，流量会越来越贵，我们需要精细化运营每一份流量。

 

我们在做各种banner活动、Feed流推荐优化、活动页等进行效果评估，无法知道该位置最终产生了多少收益，也就很难针对该位置进行有效的改进。

 

如果进行单因数AB测试进行改版的效果评估，那也会存在如下2个问题：

1. 单因素变量控制并不容易做到完全可控，如果产品处在增长期，产品增长本身就是一个影响因子，很容易忽略此类因素的影响。

2. 评估方式低效，如果 2 天内只控制 1 个坑位变动，那么评估 20 个坑位内容改变就需要 40 天时间，这样的效率任何企业都无法接受。

 

因此，我们希望用数据分析中归因的方式解决坑位运营中评估的问题。

 

我们引入电商坑位归因的概念，把每一笔的成交都归给转化路径中不同的坑位。根据坑位的曝光转化价值来评判坑位的好与坏。把宝贵的流量尽可能都引导到转化率更高的坑位，以此达到精细化运营的效果。当然有了这个坑位价值评判的机制后各个坑位的改版也能准确的评估，真正做到了数据驱动增长。

 

02 归因类型简介

1. 首次触点模型：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个「待归因事件」功劳为 100%。

2. 末次触点归因：

   多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为最后一个「待归因事件」功劳为 100%。

3. 线性归因：

   多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为每个「待归因事件」平均分配此次功劳。

4. 位置归因：

   多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个和最后一个「待归因事件」各占 40% 功劳，其余「待归因事件」平分剩余的 20% 功劳。

5. 时间衰减归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为越靠近「目标转化事件」做出的贡献越大。

 

对于电商平台来说，末次触点归因是比较适合电商站内销售归因的。虽然用末次触点归因实现方案上比简单，但是直接将价值100%归因给购买或者转化之前最后一次接触的渠道，而完全不考虑整个过程中消费者到底接触过多少个触点。转化之前发生了太多的事情，该模型完全忽视了漏斗上层和中层部分的行为对转化的影响。

 

因此我们公司融合首次触点归因和末次触点归因，计算用户进入一级流量入口后再到完成的完整购物链接行为。一级流量流入的定义为：各个入口之间无法进行跳转，只能通过切换tab进行跳转或者返回初始位置后重新点击进入。这样我们就可以基于购物的完整链接的最外层进行销售归因，并且也能知道用户购物的完整路径，同时保证销售归因后各个入口坑位的销售额之和等于当日的销售额。

 

使用这种融合归因方式，也可能知道中间步骤的转化率。比如活动会场页和商品详情页的相关推荐，虽然对电商平台整体进行销售归因时，不会计算活动会场页各个模型的销售，也不会计算商品详情页的相关推荐。

 

但是由于我们记录了用户进入一级流量入口后的详细路径，因此我们单独研究活动会场页和商品详情页的效率时，也是可以计算得到各个模块的销售来进行对比分析。但是切记不能和一级流量入口的销售混合在一起看，这样会导致销售归因发生重复。

用户购物路径模拟图

 

03 电商归因实现方案

对于电商归因我们进行了三个方面的归因，包括：曝光归因、点击归因、销售归因。即归因出所有的商品曝光来自哪里，所有的商品点击来自哪里，所有的销售来自哪里。这样就可以追踪各个流量入口的曝光链路归因指标。比如各个流量入口的商品曝光点击率、商品点击支付率、商品曝光价值等等核心监控指标来评价各个流量入口的效率。

 

电商归因准确的前提是埋点日志的完整性，因为我们是通过需要归因的事件往前找到用户的购买路径，这样的好出是大大减少计算量，也基本解决的归因的问题。因此用户行为日志的完整记录才能真实还原用户的购买路径，否则就可能导致归因出错，最终造成错误的评价数据。

 

首先需要在埋点体系中引入PageId的概念，PageId的作用是每当用户产生一次跳转行为进入一个新页面时，为这个页面赋予一个新的PageId；而当用户点击返回时，不会产生新的PageId。PageId是越靠近的当前时间的页面浏览的行为越大，且不会重复，类似于自增ID的实现逻辑。PageId的实现当然是写入埋点SDK当中，这样保证所有的埋点事件都带上PageId，并且也无需开发同步每次单独写逻辑。

 

然后根据埋点日志去还原用户的行为路径，全程都可以仅仅使用SQL逻辑就能计算完成。

1. 首先要确定所有要归因的end事件（末端事件），包括商品曝光、商品点击、商品加购成功（加购后可以通过server的订单表判断用户是否完成了付款，也达到了销售的归因目的）。

2. 然后在确定所有归因head事件（首端事件），即之前就定义的好的各个一级流量入口。

   我们平台比较特殊，是工具类App同时拥有电商业务，这样一级流量入口会比较多，但是可以枚举完成的，不仅仅包括常规电商App的流量入口，还可以在各个工具页面嵌入电商入口，这样复杂性要强于一般的电商App。

3. 我们的埋点日志都会记录用户发生各个行为的本地时间，用end事件时间去找最接近的这个时间的head事件，直接用SQL的left jon关联日志表就能完成计算。

   这样在首尾2段时间内的所有埋点日志行为就是我们需要日志。

4. 然后筛选出这些日志中的所有点击事件，过滤掉其他无效事件。

   再对所有剩下的日志进行排序，按照本地时间排序，这样就得到了一条完整的用户有效行为的路径记录。

   对于这部分数据我们就可以进行存储使用了，这部分数据为归因后用户完整链路记录数据。

5. 再基于PageId过滤掉同个页面相同PageId的事件，保留本地时间最晚的那一条事件记录。

   这样就得到了用户进入一级流量入口后真正进行末端事件的有效路劲。

   这部分数据也需要存储记录，并且这个部分真正归因完成的用户行为路径，此时的得到各个一级流量入口就行归因得到此末端事件的来源。

6. 通过这样计算后就了解各个一级流量入口的商品曝光点击情况，也能知道销售情况。

   利用这些数据就能衡量各个流量入口的效率情况，也同样也可以中间承载页面的效率如何。

   就能帮助产品运营更好的改善各个功能以及迭代各式各样的活动。

用户进行一次加购的路径还原

 

通过上述方法的计算，我们最终得到的用户加过链路步骤为：【1，2，9，10，11】，并且入口事件【1】就此次加购事件的归因来源。

 

另外再来举个商品详情页相关推荐的例子，下图所示的用户行为最终得到的链路步骤为：【1，2，9，10，11，12】，由于我们是完整保留用户的路径，因此我也只能这次加购事件不仅来源于1，也有一部分功能功能来于11，也就是商品详情页的推荐，因此我们也能计算出商品详情页的推荐效率如何，后续算法团队迭代模型时也能根据这个数据来衡量优化的好与坏。

 

商品详情页之间的横跳类型用户路径

 

04 总结

通过以上方案得到电商归因模型数据，可以大大提高运营同学的运营效率，不再是盲人过河实的凭感觉去优化各个坑位和活动，已经可以通过数据清晰公平的判断运营每一次迭代的结果。

 

但是仅仅根据坑位归因决定坑位价值，容易出现短期偏见，即追求短期利益，比如在一款内容产品中镶嵌一些游戏元素，可以让用户停留更久、数据表现更好。但从长期来看，这种行为破坏了整个产品的价值定位，因为内容产品原本提供的是内容并不是游戏，产品也不并是为了追求用户停留时长而是为了实现价值。这是两者都存在的短期偏见。

 

因此不能仅仅根据坑位归因后的销售转化价值来评价坑位，还需要综合考虑产品价值定位、战略发展等因素，才能围绕长期目标进行健康发展。