模型|干货：电商归因模型技术方案( 二 )_

文章插图
用户购物路径模拟图
三、电商归因实现方案对于电商归因我们进行了三个方面的归因，包括：曝光归因、点击归因、销售归因。
即归因出所有的商品曝光来自哪里，所有的商品点击来自哪里，所有的销售来自哪里。这样就可以追踪各个流量入口的曝光链路归因指标。比如各个流量入口的商品曝光点击率、商品点击支付率、商品曝光价值等等核心监控指标来评价各个流量入口的效率。
电商归因准确的前提是埋点日志的完整性，因为我们是通过需要归因的事件往前找到用户的购买路径，这样的好出是大大减少计算量，也基本解决的归因的问题。因此用户行为日志的完整记录才能真实还原用户的购买路径，否则就可能导致归因出错，最终造成错误的评价数据。
首先需要在埋点体系中引入PageId的概念，PageId的作用是每当用户产生一次跳转行为进入一个新页面时，为这个页面赋予一个新的PageId；而当用户点击返回时，不会产生新的PageId。
PageId是越靠近的当前时间的页面浏览的行为越大，且不会重复，类似于自增ID的实现逻辑。PageId的实现当然是写入埋点SDK当中，这样保证所有的埋点事件都带上PageId，并且也无需开发同步每次单独写逻辑。
然后根据埋点日志去还原用户的行为路径，全程都可以仅仅使用SQL逻辑就能计算完成。
首先要确定所有要归因的end事件（末端事件），包括商品曝光、商品点击、商品加购成功（加购后可以通过server的订单表判断用户是否完成了付款，也达到了销售的归因目的）。
然后在确定所有归因head事件（首端事件），即之前就定义的好的各个一级流量入口。我们平台比较特殊，是工具类App同时拥有电商业务，这样一级流量入口会比较多，但是可以枚举完成的，不仅仅包括常规电商App的流量入口，还可以在各个工具页面嵌入电商入口，这样复杂性要强于一般的电商App。
我们的埋点日志都会记录用户发生各个行为的本地时间，用end事件时间去找最接近的这个时间的head事件，直接用SQL的left jon关联日志表就能完成计算。这样在首尾2段时间内的所有埋点日志行为就是我们需要日志。
然后筛选出这些日志中的所有点击事件，过滤掉其他无效事件。再对所有剩下的日志进行排序，按照本地时间排序，这样就得到了一条完整的用户有效行为的路径记录。对于这部分数据我们就可以进行存储使用了，这部分数据为归因后用户完整链路记录数据。
再基于PageId过滤掉同个页面相同PageId的事件，保留本地时间最晚的那一条事件记录。这样就得到了用户进入一级流量入口后真正进行末端事件的有效路劲。这部分数据也需要存储记录，并且这个部分真正归因完成的用户行为路径，此时的得到各个一级流量入口就行归因得到此末端事件的来源。
通过这样计算后就了解各个一级流量入口的商品曝光点击情况，也能知道销售情况。利用这些数据就能衡量各个流量入口的效率情况，也同样也可以中间承载页面的效率如何。就能帮助产品运营更好的改善各个功能以及迭代各式各样的活动。

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