文章作者：赵华翔

内容来源：原创投稿

出品平台：DataFunTalk

导读：在中国的人口基数下，流量，用户，资本红利貌似总是被绑定在了一起。随着互联网的高速发展，多元化的应用压榨了本身就碎片化的时间和流量，对于电商来说，不管是平台还是自营，在流量红利殆尽的当下，挖掘用户更多的价值成为了所有公司的共识，于是流量的建设和用户行为的分析便成为了给风口上那只猪插下翅膀里必不可少的一环。流量体系建设在不同行业的建设和应用存异，本文主要介绍网易严选在流量体系建设过程中的思考和阶段性总结，如有理解错误的地方，欢迎批评指正，希望能够给各位小伙伴带来些许有价值的启发和思考。

对于电商来说，好比我们要开一家大型商场，这家商场地基建设中很大的一块那便是流量的建设。流量建设的终极目标在于用户行为的分析，抽象了说：用户行为分析的本质也就回归到了技术对人的探索（我是谁，我在哪，我要去哪里）。笔者有幸参与并主导了流量体系的从0到1的建设过程，总结一句话就是"眼看他起高楼，眼看他楼好了"。以下enjoy~

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

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

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

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

代码埋点：

优势：定义灵活，可根据自身业务需求定义属性。

劣势：代码引入对性能的影响，代码方式数据质量的可控性较差，更新需要发版。

可视化埋点：

优势：界面式操作灵活，业务友好度高，人力介入成本低。

劣势：埋点场景局限于交互，覆盖面小。且需要可视化工具支持。

全埋点：

优势：历史数据可回溯，自动化程度高。

劣势：上报量级对服务性能考验大，覆盖场景局限。

不用埋点方式优劣不同，所以我们在实际发展过程中，也在各优劣下寻求一种对于业务和技术来说最好的平衡解，对技术来说：成本小，开发效率高最为核心，对业务来说：响应快，准确性好，数据精细化程度高最优。所以这个平衡解在严选现阶段下，我们采用了自动化埋点+代码埋点的方式实现。自动化埋点，参考阿里的SPM(SuperPositionModel超级位置模型)+SCM(SuperContentModel超级内容模型)，通过位置模块+内容定义的方式实现成本较低的自动化埋点，解放埋点复杂度高，数据精细化程度要求较高的页面：例如像首页流量分发的核心页面。如下图所示：通过事件(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上。缺点：不好切蛋糕，加总销售大于总体。

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

对于流量分发下游的承接页面，比如我们的栏目，活动，专题等页面，作为流量承接页，核心