C端归因行为介绍——电商平台的归因体系

2026 年 7 月 1 日

3444 字

17 分钟

工程

AI 摘要

文章以B站URL参数引入,介绍了电商平台的归因体系。首先解释了spm(位置模型)和scm(内容模型)用于追溯用户行为路径,为个性化推荐提供数据基础。随后明确了归因目的:评估各流量入口的转化价值以实现精细化运营。归因类型包括首次触点、末次触点、线性、位置和时间衰减,电商业务融合首次与末次触点,基于一级流量入口进行销售归因。实现方案依赖埋点日志和PageId,通过SQL还原用户完整行为路径,区分曝光、点击、销售归因,以监控各入口效率。最后指出归因结果需结合产品长期战略,避免短期偏见。

引言

image.png

这是 B 站网页端,我们从除首页以外的其他页面进入的视频页面,就是从视频详情页点击其他相关的视频,细心的同学就可能发现网页的 URL 链接拼接了若干参数

  1. spm_id_from
  2. track_id
  3. vd_source

image.png

不同的是,从首页点击进入的视频却只有 vd_source 这个参数。这就让我们疑惑万分,不都是视频吗,为什么参数还不一致,多的两个参数到底做了啥?

image.png|300

实际上是,不止是 B 站,我们常用的软件,网页如知乎,抖音,快手等诸如此类都有类似 spm_xx_id/scm_xx_id 。这种通性让我迫不及待地想深入介绍一下,恰巧,在去年双十一,我曾担任某电商公司的 C 端工程师见识了真实的线上埋点与归因体系 (下文会介绍)。经过最近的查阅资料,完善了这篇文章的骨架。

下面乘着顺风车,一起来看看吧!

结论先行

Spm_id_from 有个模板化的命名规范 spm_id,当然各家叫法不一样,b 站可能叫做 spm_id_from,抖音可能叫做 spm_dy_id,下文统称 spm_id,同理,还有 scm_id。

这两者都是记录用户画像,记录用户偏好,以便生成个性化推荐

名称含义作用
spmSuper Position Model(超级点位/位置模型)根据网站位置追溯用户行为
scmSuper Content Model (超级内容模型)根据网站内容追溯用户行为

所以是追溯用户行为路径的不同划分方式,一种是通过位置去找,一种是通过内容去找,追溯用户行为路径的目的就是刻画出一个完整的用户画像,为搜广推业务打下数据基础,个性化搜索,个性化广告,个性化推荐,都是建立起一个有一个 spm/scm 模型上面的

image.png

举个例子,在 B 站搜索推荐中,我们常常能看到一些个性化的信息,大部分时候非常准确,最终提高了我们在平台的用户粘度

而上述的 spm/scm 只是一种模型,一种规范,实际上在我们看不到的地方有各种参数被上报,例如设备信息,国家,用户信息,视频标签,分类,时间,地点,从哪个页面进入等。一般来讲,越精细化的推荐就意味着上报的参数越多,往往在几十到一两百个不等。而这些参数业界有个统一的命名——埋点,参数上报的行为,本质上叫做埋点上报。

而庞大的参数数量需要管理、清洗、校验,就衍生了埋点治理,管理体系、等各种大数据的业务,这些都是后话

image.png|176

如此完善的埋点体系就足以支持用户行为的归因。下面用我们电商场景介绍了归因的相关内容

一、电商归因目的

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

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

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

  1. 单因素变量控制并不容易做到完全可控,如果产品处在增长期,产品增长本身就是一个影响因子,很容易忽略此类因素的影响。
  2. 评估方式低效,如果 2 天内只控制 1 个坑位变动,那么评估 20 个坑位内容改变就需要 40 天时间,这样的效率任何企业都无法接受
    image.png
    因此,我们希望用数据分析中归因的方式解决坑位运营中评估的问题。

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

二、归因类型简介

  1. 首次触点模型:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为第一个「待归因事件」功劳为 100%
  2. 末次触点归因:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为最后一个「待归因事件」功劳为 100%
  3. 线性归因:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为每个「待归因事件」平均分配此次功劳
  4. 位置归因:多个待归因事件 对同一个目标转化事件作出贡献时,认为第一个和最后一个「待归因事件」各占 40% 功劳,其余「待归因事件」平分剩余的 20% 功劳
  5. 时间衰减归因:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为越靠近「目标转化事件」做出的贡献越大

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

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

使用这种融合归因方式,也可能知道中间步骤的转化率。比如活动会场页和商品详情页的相关推荐,虽然对电商平台整体进行销售归因时,不会计算活动会场页各个模型的销售,也不会计算商品详情页的相关推荐。但是由于我们记录了用户进入一级流量入口后的详细路径,因此我们单独研究活动会场页和商品详情页的效率时,也是可以计算得到各个模块的销售来进行对比分析。但是切记不能和一级流量入口的销售混合在一起看,这样会导致销售归因发生重复。

image.png

三、电商归因实现方案

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

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

首先需要在埋点体系中引入 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. 通过这样计算后就了解各个一级流量入口的商品曝光点击情况,也能知道销售情况。利用这些数据就能衡量各个流量入口的效率情况,也同样也可以中间承载页面的效率如何。就能帮助产品运营更好的改善各个功能以及迭代各式各样的活动。

image.png

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

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

image.png

四、总结

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

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

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

正在加载评论...

输入关键词开始搜索