数据开发之离线计算_全链路归因数据体系

一、什么是全链路归因

1.概述

顾名思义，【全链路归因】可以理解为针对业务定义的用户结果属性行为（如点击、加购、下单），依据用户从站外来源到站内分发的全链路行为，找出结果行为的主因是什么。从全零售业务（场主、货主、经分等）视角出发，【主因】主要被细化为一级场域来源、一级场域、二级场域来源、二级场域、素材来源、素材、商详间接分发。

若从研发视角看：

一级场域来源：一级场域的上一跳。其中上一跳定义为上一个行为。
一级场域：距离结果事件最近的，符合一级场域定义的事件。
二级场域来源：二级场域的上一跳。其中上一跳要求与二级场域之间有真实点击。若二级场域来源同时满足二级场域的定义，则二级场域来源名称取此定义下的名称，否则二级场域来源名称为空。
二级场域：距离结果事件最近的，符合二级场域定义的事件。且要求必须在一级场域之后发生。
素材来源：
- 商详归因&商详页加购归因：素材的上一跳。其中上一跳要求与素材之间有真实点击，且要求必须在一级场域、二级场域之后发生。若素材来源同时满足素材的定义，则素材来源名称取此定义下的名称，否则素材来源名称兜底为“单品”。
- 非商详页的直接加购归因：结果事件的上一跳。其中上一跳要求与素材之间有真实点击，且要求必须在一级场域、二级场域之后发生。若此事件满足素材的定义，则素材名称取此定义下的名称，否则素材名称兜底为“单品”。
素材：
- 商详归因&商详页加购归因：结果事件的上一跳。其中上一跳要求与素材之间有真实点击，且要求必须在一级场域、二级场域之后发生。若此事件满足素材的定义，则素材名称取此定义下的名称，否则素材名称兜底为“单品”。
- 非商详页的直接加购归因：直接加购事件本身，且要求必须在一级场域、二级场域之后发生。若此事件满足素材的定义，则素材名称取此定义下的名称，否则素材名称兜底为“单品”。
商详间接分发：距离结果事件最近的，符合商详间接分发定义的，所在商详页与结果事件spu不同的事件。且要求必须在一级场域、二级场域之后发生。

以上各层级归因结果都可以为空。

举两个简单的例子：

1）此链路下，一级场域为我京、二级场域为PLUS频道、素材为单品（商详浏览6，因为浏览7与结果事件A之间无真实点击）、素材来源为店铺页

2）此链路下，一级场域为我京、二级场域为空（不是逛，因为逛在一级场域之前）、素材为直播间（直接加购事件的素材为自身）、素材来源为店铺页

以上，你应该已经知道一个数据研发眼中全链路归因的样子了。

全链路归因不同口径的差异：

2.流量归因

首先，通过将用户行为路径进行归纳总结，抽象出如下路径：

站外来源（渠道）—>站内场域—>场域触点—>素材—>素材触点—>进商/加购—>下单

用户下单之前会经过一系列的流量路径节点，因此在进行订单归因之前，需要先对流量进行归因。考虑到用户进入某个商详或者完成某次商品加购之前可能已经经过了多个场域，因此引入了场域截断的逻辑规则，规定场和场之间的路径流量归属于上一个场。

针对场域本身的特点和定位，进一步划分了一级场和二级场，被归类为一级场域的，只有在碰到一级场域时才会进行路径截断，两个一级场之间的路径流量会归属给上一个一级场，如果路径中有二级场存在也会归属给对应的二级场。具体一二级场域划分如下：

一级场域：搜索、首页推荐、我京、购物车、首页、PUSH消息
二级场域：平台运营频道、频道生态认证频道等

触点也称作场域/素材页面上的模块、资源位，其定义为：结合页面流量动线、页面布局设计等角度，将业务属性上具有密切相关或相似性的页面区域划分为同一个页面模块，且不同页面模块整体之间具有明显的业务差异性。一个页面模块内会包含一个或多个点击埋点，这些点击埋点都属于同一个模块；一个点击埋点只归属于一个模块。以首页为例：首页页面上有核心频道楼层触点、为你推荐楼层触点、小首页&首页分类触点、百宝箱楼层触点等。

3.订单归因

订单归因是在流量归因基础上，进一步对每笔交易，进行场域、素材、触点归因。考虑到权重分配类算法的黑盒属性无法满足业务上的可解释和可预期的要求，因此采用业务协商方式进行归因。同时因为站内场域众多，不同场域的定位和承接作用有所不同，因此会有末次归因和种草归因两种逻辑口径来分别评估不同场域、素材、触点的订单贡献。

末次归因主要体现场域的直接成交、即时成交贡献，基本逻辑针对每一个成交的sku，追踪其末次加购的场域进行归因。

以用户行为中经过2个二级场域举例，一级场域同理：

4.案例说明

二、重点解决问题

1.业务埋点变更规范管理及系统化流程 - 变更可感知，及时响应

在原流程中，业务定义变更需要经历【埋点新增/变更、业务数据资产对应变更、业务沟通商分团队变更、商分团队提需归因变更、手动维护归因触点范围】这一流程，各节点间的联动全部需要人工驱动。

基于此，搭建一套系统化的流程承接全范围联动，减少各个步骤的人工投入，减少人工误差导致的信息同步风险，将业务变更及时体现在全链路归因结果中。

2.触点管理 - 统一维表

统一管理归因各业务线触点范围，拉通归因&各业务线独立资产的业务范畴，保证归因与业务真实的运营场景匹配，同时实现归因引导进商/引导订单与其他各业务数据的多视角交叉分析。

此维表体系整合和管理了来自不同渠道或系统的触点数据，包含了所有触点的共同属性，如触点类型（页面/点击）、触点ID、触点名称、归属场域类型（一级/二级/素材等）、归属场域名称、匹配方式（关联/包含等）、归属的首末次场域来源（0-3级）等信息，确保在数据分析或业务处理时，能够准确识别和引用这些触点。

随着业务的发展和变化，触点属性或数据可能会发生变化，因此需要定期对统一维表进行维护和更新‌。除上一节中所述流程外，各个场域已优先实现业务流量资产的接入（如搜/推场域来自各自的定义模型、内容场域定义来自内容浏览gdm模型、二级场域定义来自营销中心认证频道模型等），相关业务的变更会经由业务数据资产在归因中直接体现，响应及时且无需二次开发，保持各端数据可置信、可对比。也就是由事实明细出维表数据。

总结来讲，全链路归因统一维表是确保数据一致性、准确性、可用性的关键步骤：

提高数据质量‌：通过标准化数据格式和属性，减少数据错误和冗余，提高数据的准确性和一致性。
增强数据协同‌：使得不同部门或系统之间能够基于统一的数据维度进行沟通和协作，提高工作效率。
支持决策分析‌：为数据分析提供统一的数据基础，使得分析结果更加可靠和具有指导意义。

3.技术架构全面更新重构

3.1 架构清晰，命名规范

在重构过程中，对任务链路进行了剖析和梳理。通过识别并优化各层计算之间的依赖关系，成功地简化了架构的复杂性，使得各个层级之间的界限更加明确。这样的优化不仅提升了架构的可读性，还极大地便利了后续的维护和扩展工作。

除此之外，对各层级的任务和模型进行了细致的命名规范调整，遵循清晰、简洁、具有描述性的命名原则，确保每个任务和模型的名称都能准确地反映其功能和职责。这样的命名规范不仅提升了代码的可读性，还极大地降低了团队成员之间的沟通成本，使得大家能够更快地理解和定位问题。

以加购归因链路为例，新架构下规范的命名可以一下就看出该层级所做的主要工作：step0-加购/点击/浏览的数据准备，step1-热点过滤，step2-点击/浏览触点定义，step3-用户行为合并，step4-加购归因中间表。

3.2 触点定义优化

原触点定义全部基于点击事件圈选，部分通过event_id限制，部分通过页面page_id限制。但并非所有点击事件都强制上报page_id信息，这会导致部分触点定义遗漏。重构后，浏览和点击触点分开定义，通过后续的处理步骤做融合匹配。

浏览事件触点‌：通过原生页page_id、通天塔密文、万花筒链接等不同方式在浏览事件中圈选触点。
点击事件触点‌：对于仍然需要通过点击事件来定义的触点，继续保留原有的点击事件圈选方式：event_id圈选，部分卡控指定页面。
浏览点击匹配：基于串联后的用户行为，将每个点击归属给前序最近浏览事件。这样的匹配关系替代了原有的访次访序匹配，能更加全面地照顾到底层数据上报细节，准确度更高。

3.3 真实还原用户行为

a)统一时间统计标准 - 毫秒级时间‌

原架构中对时间类型的选择混乱，大部分选择访次访序，部分服务端秒级时间/客户端秒级时间。经过探查，同访次访序下有重复行为的用户占总量的52.7%，同服务端秒级时间下有重复行为的用户占总量的35.3%，同客户端秒级下有重复行为的用户占总量的30.9%，而同客户端毫秒级时间下有重复行为的用户占总量2.2%。针对此情况，选择毫秒级时间作为统一时间排序标准。

基于全链路归因所需业务范围，反推各个业务数据资产模型补齐字段（加购/内容/通天塔/搜索等资产模型都在本次推动下补齐时间粒度）。通过统一时间统计标准，可以确保所有用户行为数据的时间戳都是基于同一标准，有助于消除因时间差异导致的数据不一致问题。

b)使用客户端时间戳做用户行为串联

原架构使用访次访序来评判用户行为的先后顺序，但基于访序的上报规则（遇到浏览+1），同一个浏览下的多个点击行为无法仅依靠访次访序做精准区分，仍需要增加时间字段作为判断依据。基于上一条中已统一的时间标准，选择客户端时间戳作为用户行为先后判断的主依据。

目前在零售数据体系中，统一使用服务端时间完成时/分粒度的下钻和统计，这是因为服务端时间使用统一的标准，而客户端时间依赖时区、且可被用户自行修改，可能导致数据统计偏差。但在全链路归因中，归因计算的准确度完全依赖于用户行为的先后顺序，此特性决定了无法完全使用服务端时间来排序，因为用户在app中的行为并不是逐条上报而是累积多条统一上报的，这会导致多个用户行为的服务端时间一致，无法精确区分先后顺序。而客户端时间戳记录了用户行为发生的确切时间，使用客户端时间戳做用户行为串联可以更精细地还原用户行为序列。

至于时区差异和用户修改时间的情况，由于全链路归因中不会对多个用户行为做交叉分析，只需要获取用户自身相对先后顺序，因此时区差异和用户修改时间行对归因结果的影响较小。从事实角度出发，不排除用户在同一次会话中跨时区、修改客户端时间的行为，但此边缘情况可暂时忽略不计。

为与大盘流量、交易数据对齐，客户端时间仅用于用户行为排序串联，商详浏览和下单的时间统计仍使用统一标准服务端时间。

c)基于行为串联准确获取浏览和点击的关系‌

如上所述，归因计算的准确度完全依赖于用户行为的先后顺序。原架构点击和浏览行为匹配主要通过访次访序关联/pv_log_id字段关联，高度依赖这些信息的上报/获取情况。而新框架下采用时间匹配法，通过时间顺序来确定点击和浏览之间的关联。具体来说，一个浏览到下一个浏览之间的点击行为，将归属为前一个浏览的点击行为。

这样的方法意味着，系统可以基于用户行为的时间顺序和行为类型，自动将浏览和点击行为关联起来，而无需依赖访次访序/pv_log_id等额外信息的百分百准确上报。这种基于时间的匹配方式能够基于更少的数据、更准确地反映用户在实际使用过程中的行为模式，提高了归因分析的准确性。

3.4 归因算法优化

全链路归因计算的核心逻辑是，找到结果事件的前序最近一个符合 xxx（一级场域、二级场域……）定义的行为和相关信息。

下图为一个用户行为序列的示例，此商详浏览事件A的一级场域为【符合一级场域定义的、最近的行为】，即“我京”，同理二级场域为【符合二级场域定义的、最近的行为】，即“PLUS频道”

原架构下，归因计算使用sql语言处理，每一层归因结果都需要至少3次关联计算。以上述例子的一级场域为例：

▪关联1 – 找“前序”：商详浏览与一级场域触点池关联，找商详浏览前所有满足一级场域定义结果，结果是b、f、g。在所有结果中通过max时间计算找出前序行为中时间最大（距离商详最近）的行为g主键，包括访次、访序、客户端时间等

▪关联2 – 找“前序最大行为的全部信息”：1中获得的g主键重新关联一级场域触点池，获得前序最近一级场域行为g的全部信息

▪关联3 – 将g的信息与商详浏览数据拼接获得商详归因结果。

因此在原框架下，获得多层归因结果需要大约3x5=15次关联计算，非常繁琐，修改、迭代效率低下。

在新的框架下，用户行为数据已经通过时间戳等方式进行了串联，形成了完整的行为序列。将这些串联好的用户行为作为入参传递给UDF，可以使得UDF能够直接基于完整的行为序列进行归因计算，而无需再进行额外的关联操作。

UDF接收用户行为序列作为入参后，可以直接进行归因计算，并输出归因结果。计算方式也从反复匹配改为了行为序列倒序遍历寻找，找到符合条件数据即止。仍以上述示例做演示（需要注意的是示例图有细微不同，因为新架构中触点定义方式发生变化）：

从A开始倒序往前寻找：

•一级场域：在一级场域定义池子中找到了浏览3，停止，一级场域由浏览3的场域定义、page信息和浏览3下最后一个点击g的event信息拼接而成。

•二级场域：同上，在二级场域定义池子中找到了浏览4，停止，二级场域由浏览4的场域定义、page信息和浏览4下最后一个点击i的event信息拼接而成。

•……

这种方式避免了原框架下多次重复关联的繁杂计算，提高了归因算法的执行效率和准确性。

需要注意的是，待归因事件的类型（浏览/点击）不同、触点事件类型（浏览/点击）不同，所对应的计算方式会有细微差别，具体逻辑规则可见下图。

4.新架构运行示例

除常用的全链路商详、订单归因计算外，此流量场全链路归因算法还可以适用于不同类型的点击/浏览事件的全链路归因计算。只需对应改变入参中的待归因事件（即终止节点）即可实现，无需为每个事件类型单独编写归因算法。这大大提高了归因算法工具的灵活性和适用性。如目前泛商归因重构、八千百项目频道访问来源等都是基于此udf实现的，效果达预期，且开发效率大幅提升。详细复用步骤如下：

步骤1：准备好待归因事件数据，浏览、点击类型均可。需要具备：

▪字段区分待归因事件类型

▪设备号、pin、访次、毫秒级客户端时间戳，用于归因计算中的用户行为还原

▪其余需要呈现在结果里的、与归因逻辑计算无关的字段，如sku属性、架构归属、事件id等

步骤2：基于步骤1数据与带有归因口径流量场/素材定义的全量真实点击/浏览数据做拼接。需要互相适配到统一格式下，从相同视角做拼接。其中带有归因口径流量场/素材定义的全量真实点击/浏览数据已沉淀为通用模型：

▪浏览：udm_jdr_sch_d14_traffic_attribute_step_2_touch_point_define_pv_log_di

▪点击：udm_jdr_sch_d14_traffic_attribute_step_2_touch_point_define_click_log_di

▪以上模型场域定义关注：gy_type-场域类型、gy_field_id-场域ID、gy_field_name-场域名称

步骤3：基于步骤2合并好的用户行为做路径还原。用设备号/pin做窗，以时间排序，找到待归因事件的前序行为序列。示例代码如下

CASE 
 WHEN gy_cate = 'touch_point' 
 THEN NULL 
 ELSE collect_list( case when gy_cate = 'gy_cart' then NULL  else behavior_info end ) over(partition by session_id order by device_ts, gy_type desc desc)
END AS behavior_info