网易严选流量体系建设实践

在中国的人口基数下，流量，用户，资本红利貌似总是被绑定在了一起。随着互联网的高速发展，多元化的应用压榨了本身就碎片化的时间和流量，对于电商来说，不管是平台还是自营，在流量红利殆尽的当下，挖掘用户更多的价值成为了所有公司的共识，于是流量的建设和用户行为的分析便成为了给风口上那只猪插下翅膀里必不可少的一环。流量体系建设在不同行业的建设和应用存异，本文主要介绍网易严选在流量体系建设过程中的思考和阶段性总结，如有理解错误的地方，欢迎批评指正，希望能够给各位小伙伴带来些许有价值的启发和思考。 对于电商来说，好比我们要开一家大型商场，这家商场地基建设中很大的一块那便是流量的建设。流量建设的终极目标在于用户行为的分析，抽象了说：用户行为分析的本质也就回归到了技术对人的探索（我是谁，我在哪，我要去哪里）。 笔者有幸参与并主导了流量体系的从0到1的建设过程，总结一句话就是"眼看他起高楼，眼看他楼好了"。以下enjoy~

埋点体系建设 

流量建设中最核心的一环：埋点体系的建设。埋点体系的好坏直接决定了流量数据质量的好坏，直接影响了上游应用的数据质量以及业务对数据的可信度。九层之塔，起于累土，埋点体系的建设好比就是老子笔下九层塔里的筐筐"累"土。

埋点体系的建设其实需要解决的是我们在私域流量快速增长，业务精细化程度越来越高的情况下，如何在增量以及保障数据质量的背景下，提升埋点开发，QA 测试，数据清洗以及生产环节下全链路的效能。      

1. 寻求埋点方式的平衡解

埋点体系建设里几种常见的埋点方式： 代码埋点，可视化埋点，全埋点。

代码埋点：

• 优势：定义灵活，可根据自身业务需求定义属性。
• 劣势：代码引入对性能的影响，代码方式数据质量的可控性较差，更新需要发版。

可视化埋点：

• 优势：界面式操作灵活，业务友好度高，人力介入成本低。
• 劣势：埋点场景局限于交互，覆盖面小。且需要可视化工具支持。

全埋点：

• 优势：历史数据可回溯，自动化程度高。
• 劣势：上报量级对服务性能考验大，覆盖场景局限。

不用埋点方式优劣不同，所以我们在实际发展过程中，也在各优劣下寻求一种对于业务和技术来说最好的平衡解，对技术来说：成本小，开发效率高最为核心，对业务来说：响应快，准确性好，数据精细化程度高最优。所以这个平衡解在严选现阶段下，我们采用了自动化埋点+代码埋点的方式实现。自动化埋点，参考阿里的 SPM ( Super Position Model 超级位置模型 )+SCM ( Super Content Model 超级内容模型 )，通过位置模块+内容定义的方式实现成本较低的自动化埋点，解放埋点复杂度高，数据精细化程度要求较高的页面：例如像首页流量分发的核心页面。如下图所示：通过事件 ( click )+页面 ( index )+模块 ( kingkong )+坑位 ( sequence )+内容 ( type，extra，name 等 ) 组合得知用户点击了首页金刚区具体某个坑位，以及这个坑位的具体名称，对应素材图对应的资源信息，通过位置信息和内容信息的封装，实现自动化埋点。此处相对于阿里的 spm 编码方式我们采用了语义化的英文定义方式，上报方式则通过 a.js 的请求上报。

再者，也可以通过代码埋点满足业务在日常需求中精细化埋点需求，目前代码埋点没有完全被自动化埋点取代，原因之一是因为该套体系存在较久，运行较成功且数据质量可控，完全替代阵痛和成本可能会大于收益。所以在严选现状下，我们兼容了两套埋点模式达到现阶段的平衡解。当然，平衡解也会随着业务发展变动而变动，毕竟，唯一不变的是变本身。     

2. 埋点管理体系的建设

对于埋点管理体系的建设概述，这里引用严选 QA 同学的一句话："埋点管理体系的建设看似是个流程管理+元数据管理平台，实际意义主要是体现在结构化的数据定义，标准化的数据生产以及协作效率上，即明晰了各个角色的职责，又提高了信息记录和传递效率、透明了埋点所在的具体生命周期 ( 定义，开发，测试，上线，预警 ) "。

埋点体系按照 Top-down 的设计思路，包括：埋点体系规则建立、埋点生产过程标准化、埋点过程流程化、埋点数据质量保障、埋点线上数据监控与预警，五个从下到上的建设过程，如下图所示。

① 埋点体系规则的建立和生产过程的标准化

贯穿我们埋点体系的基线：体系化，规范化，标准化，流程化。基于这四个基线下入仓的数据有两个特点： 一是入仓数据清洗难度小，二是入仓数据质量高。

数据标准化生产的过程就好比我们搭积木的过程，大家都玩过搭积木或者乐高的游戏，规则的积木搭建起来的楼宇即稳固且呈现形态多样。所以埋点规则体系就好比规则结构的积木，数据标准化的生产过程就好比我们搭积木的过程。所以要想保障数据的产出质量，以及数据清洗的高效性，一套通用且能满足各场景的埋点体系的规则就十分重要。

严选的埋点体系规则建设包含对用户通用行为的抽象：事件的定义，页面 ，模块 ，参数以及版本的管理。大致拆分成了两类：一是发生行为的名称以及位置（事件，页面，模块，坑位），二是发生行为的内容（参数，版本信息等）。

用户行为事件触点类型包含了点击，曝光，访问，自定义事件，加购事件，加购事件因结合了严选本身电商特性单独抽象出来的事件，加购本身其实也是一种点击行为，加购行为作为用户支付意愿的核心行为，抽象出来后方便后续我们对支付行为统一归因做汇总处理，节省开发数据清洗的成本，同时简化了清洗逻辑。

页面管理，模块管理，参数以及版本的定义与管理，把以往杂乱的定义标准化，通过对页面，模块，参数定义的约束 ，收口了对数据定义的管理权，看似是管理，实则本质是标准化和结构化， 举个简单的例子：埋点名称：用户点击猜你喜欢的商品图 ，单看埋点名称，可能并不知道具体是做什么的，在哪个页面哪个模块，通过结构化的管理体系 ，我们可以清晰的知道，这个埋点在哪个页面下，对应的模块是什么，我应该如何取用它的参数。

同时对内容的参数实施了限定，枚举通用的参数，精简上百个参数到 18 个。ETL 过程不再是从众多参数中捞取业务定义的字段。开发的清洗过程对业务参数的定义变得更透明简单。

规则化事件的定义，标准化页面模块管理以及参数的限定，通用规则的解析，体系化打通埋点到看数链路，通俗点说，就是按照规则体系下上线的埋点需求，帮助业务实现了 T+1 时效和 0 开发成本的自助看数。如下图为埋点管理系统示例截图。

② 埋点过程的流程化

规则定义了我们的标准，流程化帮助我们提升了协同性。从埋点定义，埋点开发，埋点测试，到埋点上线，我们通过流程化的任务流协同整个链路，提升了埋点整体环节的效率。如下图为埋点全链路的协同流程，明确了职能划分。

通过任务流转指派，对应节点责任人接收通知邮件，完成开发或者测试任务，埋点上线后邮件周知需求方，上线及时反馈，业务及时查验数据，需求也不再是单点-单点重复沟通。再者，在产品功能开发前期，往往很容易忽视了埋点需求的重要性，直到真正复盘，需要看数据的时候才想起来"我的产品数据效果如何，这个数据是否是准确等"，所以在流程化之上，通过联动 JIRA，打包业务功能需求和埋点需求，我们希望拉平业务的功能需求和埋点需求重要性，以免捡了"芝麻"丢了"西瓜"。

如下示例为我们通过任务流指派方式，实现埋点全链路的可视化流转，使埋点信息在传递过程中透明化，辅助我们提升整体的协同效率。

③ 埋点数据质量保障

千丈之堤，以蝼蚁之穴溃；百尺之室，以突隙之烟焚，忽视小的错误，便可能会导致的大的错误，埋点亦如此。所以埋点数据质量的保障，是我们埋点体系建设中最核心最重要的一个环节。

从下到上，对于埋点方式的平衡解探索，结构化的数据规则的定义，以及流程化的管理，其本质无一不在是为我们的埋点数据质量的保障做出贡献。除上述内容，我们还通过对测试流程的把控提升埋点质量，测试流程主要包含以下几块内容：手动测试，自动化测试，UI 测试，数据校验规则以及数据线上预警。

手动测试：

针对上线前的埋点进行手动触发，  支持不同端，不同设备，账号，不同事件类型的筛选测试，可直接观测到实际入仓数据日志，同时，通过基础的校验规则，自动识别日志与定义的异常，提高测试效率。但自动识别只是针对缺失，遗漏等漏埋情况，无法有效覆盖错埋场景。比如参数 value 值应该是 A 实际上传了 B，目前针对这种场景，只能通过 QA 同学测试发现。

自动化测试：

一般针对批量回归测试，建立埋点执行集，自动执行埋点验证，埋点验证的匹配规则由经验制定批量的测试校验规则。校验规则的基本原则：

• 埋点上报的完整性：如对字段为空，非法值的校验
• 埋点行为追踪的有效性：如用户跳转后，当前埋点和上一步跳转埋点是否有效携带历史行为记录
• 埋点间的依赖关系正确性：如前后埋点sequence是否是有效自增的等

UI 自动化测试：

埋点 UI 自动化测试校验规则和自动化测试基本一致，自动化测试需要人为触发埋点测试集，测试耗时较多，所以通过 UI 自动化触发的方式实现对与埋点集的自动触发以及校验，生成结果集，以节省 QA 人力成本。

④ 埋点线上数据监控与预警

埋点测试准确上线后，为什么还需要线上预警呢？一是产品功能一直在迭代，每次发版上线对于数据同学来说都是黑盒，代码的微小变动可能会导致历史埋点的异常，往往不可知的数据异常就隐藏在黑盒中，有些历史埋点问题在线上就会暴露出来，监控预警防止该问题存在过久导致的历史数据缺失和不准。二是 QA 校验通过后的埋点，因为校验场景复杂，即使测试时该场景下，埋点正确，但其他场景下是否触发异常我们很难预知。综上，所以我们需要对线上埋点数据进行监控以及预警，以避免这种错误。

埋点数据进行监控以及预警我们采用邮件抄送对方式通知对应责任人每日数据异常。如下图所示：

页面导购体系：用户行为追踪与归因

搭建完底层埋点基建后，后续环节就是我们的用户行为追踪的实现，用户的路径往往杂乱无序，如何从这杂乱无序的用户行为中抽丝剥茧地去追踪他的行为链路，归属他的交易，那就要说到页面导购体系，页面导购体系通过对用户行为的追踪，变现交易的归属，使我们对用户的判断从"盲人摸象"的状态到交易，路径的有迹可循。

在没导购体系之前，业务需求零散，不同业务场景不同，没有统一的导购变现的方案，基本是一种场景一个报表的开发，浅了看，定制开发响应速度慢不说，同时耗费了人力成本和时间成本，各自开发也导致统计层不一致。深了看，因为各个业务场景的统计产出没有通用的底层逻辑支撑，没有统一量化的标准方案，导致的直接问题是业务视角不水平，无法让业务在统一口径标准看数据，导致公说公有理，婆说婆有理，管理层基于数据做的决策视角并没有一碗水端平。

页面导购体系分两步走，开发侧，夯实基建：底层通用化方案的建设，导购埋点体系方案的实现。业务侧，量化归一：建立统一的页面导购变现的追踪体系，统一量化业务价值。

业界归因方式较多，分权，平摊，末次，多计等，此处不对各种类型过多介绍，结合严选电商业务特性，最终严选采用两种归因方式： 一是末次归因，二是多计归因。

1. 末次归因

末次方式在于覆盖逻辑，用户触发交易行为锚点之前最近的一次行为作为交易归属页面。 所以此种方式优势比较明显：好切蛋糕，能清楚拆分金额。缺点：页面天然存在优先级关系，层级优先级高的页面归因优势越明显。

2. 多计归因

多计归因在于大家都算，优势在于：评估方式直接，易于多方业务接受，比如：用户 P 被页面 A，B 引导到了商品 D，P 购买了商品 D。商品 D 的交易归属会同时计在 A 和 B 上。缺点：不好切蛋糕，加总销售大于总体。

综合优缺点，最终选取这两种方式，原因如下：电商中有的页面天然作为用户必经页面，比如首页或者搜索页，这些页面作为用户在站内导流的入口页，这里引入的入口页概念，其实可以形象的理解成我们商场的大门，商场一般会有多个大门用来导流用户，入口页职能承接了流量在站内分发的作用，此处如果采用多计方式，那对于全站来说，大多用户都需要进过这个"大门"，多计导致的问题是销售会被过多的归因到这些所谓的入口页，所以此处针对入口页我们采用末次方式的归因，一是解决入口页的合理归因，二是也划清各个入口的交易，一举两得。

对于流量分发下游的承接页面，比如我们的栏目，活动，专题等页面，作为流量承接页，核心关注页面对商品导流能力，所以我们采用多计方式归因。优势如上所说：评估方式直接，大家都容易接受。

末次归因方式的用户追踪需要解决两个主要问题： 用户行为的如何透传，支付归因逻辑如何定义。理清楚这两个问题，基本导购方案的结构就有了，其余的只是更细节的问题的解决，比如浮层的交易归属，购物车这种特殊页面的归因逻辑，因为本身可以直接购买等，对于此类问题此处不做细节描述。

① 用户行为的透传

透传方式有两种，一种是用户行为的全链路透传方式 ( 即用户行为的记录跟随用户在网站的整个浏览生命周期 )，一种是多步透传方式 ( 即按照用户行为先进先出的方式透传用户行为路径信息 )，一般情况下，透传 3 步即可，用户交互层级一般不会超过三步到商品详情落地页，以免漏斗太深，用户触达不了商品直接流失，实现透传方案涉及信息较多，此处不单独贴图展示，基本思路见下图：

全链路透传：

用户从 A 页面点击资源位 S1 跳转到 B 页面后，再从 B 页面点击 S2 跳转到 D 页面，当用户访问商品详情页 D 时，会在访问事件下带上 B 页面的访问事件，S2 资源位点击事件的所有信息，同时，在 B 页面访问事件时会带上 A 页面的访问事件，S1 资源位点击事件的所有信息，所以在用户访问商品详情页 D 时我们可以很清楚的从日志层面知道用户的上游页面是 B，用户从哪个模块，以及点击了哪个素材跳转过来，由此，追踪用户行为。上报时，也可以通过对事件进行编码，通过回溯的方式获取用户来源信息，例如，对 A 页面的访问事件编码为 1001，资源位点击事件为 1002  B 的访问事件为 1003  透传的数据信息为可以通过 1001 获取 1001 对应的所有信息，该方法适合数据上报压力大的情况，但对于实时解析数据的实效性不友好，视具体情况采用。 

三步透传：

透传基本思想和全链路透传思想一致，唯一区别在于三步透传按照先进先出原则保留用户 3 步内用户路径信息。

② 支付归因逻辑

前面谈到了两种归因模式的优劣采用，其中全链路追踪 ( 即入口页追踪 ) 我们采用末次归因的方式，其他页面 ( 即非入口页 ) 采用多计归因方式。

入口页全链路末次归因：

从用户的长链路出发，注重的是流量分发的价值变现，拆分清楚流水，通过入口位置的流量分发效能聚焦评定出坑位特性和如何去做资源分配。

非入口页三步多计归因：

非入口页作为流量承接页面，注重承接用户并引导用户转化，评估页面对商品导流以及最终变现的能力，链路不适合太长，更多是用来衡量页面投放效果。两者之间互不重叠矛盾。 

举个例子：严选好比是一个大商场，里边有各个门店，入口就是各个门店，需要评估看到用户在各个门店完成的支付情况，以及各个门店的运营效益和问题点，如何进行资源配置能促使全局最优；而非入口页就是各个导购员，他们的作用就是通过营销玩法，活动手段等，让来店里的客人尽可能地购买他们的商品，尽快产生购物行为。

不同平台实现方式不同，具体实施方式不一定是最优解，所以此处对于严选的归因周期，归因锚点等细节实现不做详细叙述，更多地是希望从传达实现机制的原理中，能给到读者些许启发，已达到本文目的。

结束语

流量体系的建设只是严选中台建设中的冰山一角，埋点体系建设和页面导购体系的建设帮助我们对用户行为有了更深，更精细化的了解。流量体系的建设就好比地基，地基之上更大的价值在于我们对用户行为背后的原因挖掘，实现人-货-场的快速匹配，商品货架资源效能的最大化。

今天的分享就到这里，谢谢大家。

嘉宾介绍：

赵华翔，网易严选流量产品负责人，资深数据产品经理，2017 年加入网易，曾任职阿里巴巴国际业务线数据产品经理。

文章转载自：DataFunTalk（ID：datafuntalk）

原文链接：网易严选流量体系建设实践