聚焦电商场景，详解抖音集团埋点及归因分析方案

01

（1）无日志采集

（2）Log 1.0

2013 到 2016 年期间，开始复用友*事件格式，自己做采集，主要是为了支撑推荐场景和围绕推荐的分析场景。在这些场景下，流量的埋点主要用于构建推荐系统，对数据分析的支持则较为有限。

（3）Log 2.0（未上线）

2. 场景迭代

• 质量问题开始凸显，漏传、错传现象频繁发生，进而引发线上事故；
• 归因未知场景增多，业务分析困难；
• 维护成本高，埋点效率低下。

3. 电商业务痛点

（1）用户层面

（2）分析层面

（3）工程和数据层面

解决方案

1. 总体框架

• 埋点管理
  解决方案框架的底层主要是管理埋点，并通过 BTM 和 BCM 的定义来建立规范，确保相关信息的透出能够得到充分约束，还会针对一些关键事件，如页面访问和商品曝光点击信息等进行优化，然后将其输出到 SDK 中。
• SDK
  多个前端团队协同合作，其实并不是实现目标的可靠方式。因为参与者越多，不可控性就越高。因此引入了通用化能力，选择以 SDK 来简化这部分的实施过程。
• 归因平台
  实际上，在抖音集团内部的工程团队、分析师团队、策略团队和数据团队的协作过程中，经常会出现信息遗漏和关键迭代无法同步的问题，此时，会通过归因平台来解决这些问题。
• 分析产品
  框架的最上层原本由行为分析平台提供支持，但针对电商埋点升级的情况，可以利用新定义的 BTM、BCM 和 SDK 的链路生成能力，提供更简化的分析，降低用户的分析和操作门槛。

• 事件名称不统一
  Log 3.0 是一个事件加参数框架，其下有大量的事件发生。以商品曝光事件为例，该通常命名为 show_product，而搜索前端团队则的埋点则命名为 search_result_show。电商团队购买商品卡时，会命名为 show_ecom_card。
  由于不同的前端团队以及其自身的架构层面不属于同一架构下，存在理解不统一、规范不统一的问题，造成了很高的事件处理成本。此外，重复发送事件也会带来额外的成本。
• 事件参数杂乱
  事件参数杂乱的主要原因是命名规则不一致。比如，搜索、猜你喜欢、商业化等各业务都会独立设计参数传递方案，尽管有时大家的诉求是一致的，但由于规则不统一，仍然需要重复开发，造成了额外的成本。
  那么，不一致的诉求会如何影响埋点呢？目前各团队都是各自添加自己的埋点，导致整体埋点参数疯狂膨胀。这不仅增加了传输成本，还可能导致用户体验卡顿。当卡顿达到一定程度时，就需要进行治理。此外，传输还会带来数仓的存储成本。在流量很大且参数很多的情况下，存储成本会非常高。
• 发送时机不统一
  以商品曝光为例，来理解发生时机的不统一，即不同业务团队对于商品曝光的上报有不同定义，到底是每次展示都上报，还是仅首次展示上报，亦或只要有加载就上报（虚曝光）？
  这就可能导致三种不同的上报逻辑。此外，上报的比例也可能不同，到底是展示 25%，还是 50%，亦或 100% 上报，也并未达成一致。可能每个团队的逻辑都不统一，而这种不统一在数据层上可能影响不大，但在业务层上就可能导致某些 AB 实验或分析无法达到预期效果。

3. SDK 能力

• APP 动线抽象处理
  APP 相对 PC 来说比较简单，一次只能显示一个页面，若要查看之前的页面，则只能回退操作。由于用户只能聚焦在一个页面，可以将其理解为一个队列的数据结构。用户可能进入 A ，然后进入 B ，再返回 A ，然后进入 C ，进入 D，可以把它理解为一个简单的进出原则，SDK 会处理这些进出信息。
• WAP & PC 抽象处理
  在抽象 WAP&PC 时，由于用户可以多窗口操作，每个窗口也可以有自己的链路，所以用户动线可以抽象为一棵“树”的数据结构。用户进入 A 后，可以打开一个新页面 B，也可以在 A 上直接进入 C，然后回到这个 A 里面，可能去打开两个不同的页面。
  按照树的结构，至少能够有一个推导的过程。例如从 K1 路径来看，经过了 A、B、D、E 四个节点，最后进入 K1。于是我们就无需纠结页面关闭或重新加载的问题。在此情况下，我们可以将重新加载视为仍在当前页，而非新页面，从而简化用户的动线。

（4）SDK 归因处理

4. 归因平台

• 产品的迭代影响归因逻辑，归因数据问题滞后。
  产品迭代会影响归因逻辑，数据问题通常出现较晚。当前产品有许多策略，如调整用户路径结构、增加实验等，但这些实验往往无法及时同步到数据侧处理。只有当需要查看数据时，才会发现并询问数据缺失或错误的问题。
  这种后置问题会给数仓带来很高的成本，一种情况是埋点遗漏，需要通过其他参数来弥补；另一种情况是虽然进行了埋点，但规则没有更新，因此需要更新规则，并涉及数据回溯。电商拥有庞大的流量数据，问题发现得越晚，处理回溯的成本就会越高。下游链路有上万个任务，我们需要决定是全部回溯还是只回溯其中一部分，这就会带来巨大的成本，因此我们需要建立一个流程来评估和审批相关点位变更。

• 归因策略只能靠文档管理，口径不易理解，问题难排查。
  在归因的落地过程中，数据团队发现很多归因口径只能通过文档来管理。业务方通常会提供一份归因说明文档，这是一份业务层面的说明，并非代码层面的说明。负责代码编写的同学可能会有自己的一套代码化口径理解，二者之间有时会出现无法对齐的情况。
  此外，当遇到问题时，工程师往往无法直接从文档中查询到答案，而只能去查看代码，再层层分析数据，最终才能定位问题。因此从整体来看，我们希望有一套易于维护的归因策略配置信息。

• 标签化
  对于新增的点位，需要确定它的性质。如果在业务层面上不涉及任何归因，那么它可能只是一个路过页。归因平台会提供丰富的标签，为这个点位打上合适的标识，比如入口页或末次归因等。
• 对应策略配置
  根据不同的页面类型，需要决定如何处理。例如，当遇到一个入口页时，是将其截断，还是根据其类型定义相应的业务逻辑，这可能涉及到因子数的配置。
• 生成对应数据加工任务
  最后，将入仓的硬编码转化为整个归因平台上的配置信息，然后通过 UDF 管控进行落实。

5. 分析产品

（1）页面模块分析

• 首先将访问明细表进行拆分，通过 A 点位就能够获取到页面力度的基本信息和站点信息；
• 框选到 B 点位时，可以获取页面信息；
• 框选到 C 点位时，可以获取模块信息。

总结规划

• 埋点质量提升
  在业务层，“其他”分类降低，无法归类的数据控制在 0.X% 以下，与原数据规模（X%）相比，实现了大幅减少。由于埋点质量有保障，埋点所引起的线上事故大大减少，归因系统的相对稳定性也得到提升。
• 开发效率提升
  归因平台目前还在落地阶段，但在整个约束落地之后，分析师将通过该平台，在口径制定、端上埋点实施以及数仓加工等方面实现成本降低。
• 归因能力提升
  过去，数据团队根据业务需求，通过这些参数层层传递信息，最终生成订单。但现在，相关数据团队有能力提供各种归因口径的支持，这得益于还原用户访问路径的能力。

点个在看你最好看

SPRING HAS ARRIVED