谈谈埋点质量管理

编辑导语：作为一种常用的数据采集方法，数据埋点无疑在产品正常运营过程中起着至关重要的作用，埋点质量管理也就显得尤为重要。那么，在埋点过程中，有哪些常见的质量问题？我们又应当采取哪些措施来预防这些问题呢？

如今互联网人对于数据的使用可畏常态化，虽然有的是日常工作，有的只是几次需求，但无论对与数据有多少依赖，在数据的使用或解读上，以下情况大家应该都**遇到一二。

• 团队来了一位新同学，想分析某个功能的数据情况，但感觉无从下手。便问老员工这个功能对应的埋点、那个页面对应的参数，得到的不是口口相传就是看着聊天记录中的文档地址。面对着黑压压一**的埋点信息，内心估计已经开始神兽奔腾了；
• 新版本上线后进行效果分析，发现埋点出现纰漏，此时若是重要数据，需要紧急找人发版，时间紧张又担惊受怕；若此时是一般数据，开发同学的回复大概率是：“和下个版一起迭代”，时隔半年一年再进行分析，这段数据波动的原因估计也没人能说清了；
• 测试同学拿着协作的埋点文档，测试过程中发现不是字段对应错误就是信息维护不全，解读起来麻烦不说，如果碰到大版本还需要进行埋点回归，不仅测试过程中工作量大，还有漏测的风险。

埋点数据作为日常数据最重要的三大来源之一（包括业务数据和对外合作数据），其重要性不言而喻。上能影响推荐、AB实验、数据分析的准确；下能影响仓库的结构设计和日常维护成本。当前数据更是作为资产被各家公司所重视。想象一下到年终**点时，面对一团“剪不断，理还乱”的数据，**是一种什么心情。

笔者通过对最近接手的埋点质量项目的一些经验总结，希望通过这篇文章给大家分享一下心得体**。

一、埋点质量问题有哪些？

埋点过程整体链路环节较长，囊括的角色也相对较多。出了问题排查难度大，周期长，而且涉及团队配合问题也不好把控，下面我们来总结一下哪些环节容易出问题导致埋点质量问题。

如果在数据产出阶段不进行把控，等到了应用阶段就**出现数据不完整、数据重复、数据不一致、数据不匹配等数据问题。所以解决埋点质量问题要做到“预防为主、防治结合、综合治理”的方针，下面我们来看下如何进行埋点质量管理。

二、如何进行埋点质量管理？

要开展埋点质量的管理，笔者认为可以从以下三个角度开始执行：意识、制度&流程、工具。

1. 意识

这里所谓的意识更多的是一种价值观、信念或者说是一种行为“动机”，是每个同学做事对自我要求的一项软性标准，类似于“道德”。

可能读到这大家觉得有些浮夸，怎么管理个埋点都上升到道德层面了。别着急，继续往下看。

对于执行层，无论是分析师或埋点产品必须要对出自自己手中的需求要负责，时刻意识到，埋点需求是整条数据链路的源头，并且用户实时发生数据拥有着不可回溯性。如果要是从源头开始“错、缺、乱”，那后续的环节不仅增加了成本，同时这部分数据也“白白流失”了。

而对于高层管理者，在任职期间要适当地给予数据治理一些侧重，无论是在人力上还是时间上。

让自己或自己的上级领导提升一些基础建设的意识，磨刀不一定**误砍柴功。用产品进行向上管理固然重要，毕竟是一个看的见、用得到并且能“体**”价值的载体。如果只在乎表面光鲜，那背后的“千疮百孔”要何时才能有机**修补。

任何一个组织创建时都需要有一个文化或者信念，在做事的时候可以时刻提醒自己。所以在质量管理的第一个重要角度是意识。

2. 制度&流程

上面讲述了意识层面上的统一，下面开始说的就是行为上的规范。所谓无规矩不成方圆，任何一件事有一个良好的规范去执行，那出错的概率就**比每个人自由发挥低很多。

这里所说的制度包括两个方面：角色流程和采集规范。

1）角色流程

埋点从需求产出开始要经历埋点开发、数据上报、数据采集、数据清洗、数据入库最终到业务应用，涉及的人员包括埋点产品&分析师、开发、测试、采集工程师、仓库工程师等。

各个环节能有机组合就需要一个良好的配合制度，既能保证工作有条不紊，同时又避免了权责混乱导致的问题无法及时响应。

2）采集规范

① 文档规范

文档规范要求负责埋点的同学列清相关需求点，包括：所需要的事件信息、统计位置、打点逻辑、上报时机。甚至还可能有失败后如何处理、失败原因、变更历史等相关内容，细化的需求文档有利于降低其他环节同学的理解偏差，也便于埋点使用时了解前因后果及错误信息。

② 接入规范

是指业务开发同学在使用埋点组件时要严格遵守组件方提供SDK的使用规则，例如通用事件内扩展字段的埋点位置、上报时机等。切不可根据“自我经验”进行更改优化。

③ 命名规范

命名规范适用于埋点信息的命名，包括事件ID、事件参数以及实际的参数值，做到以下原则：

1. 方便解读；
2. 不要有特殊字符，不要采用系统关键字或预置关键字进行命名；
3. 字段不易过长；
4. 版本前后字段映射统一等。

无法挨个维护的的参数值可以采用SPM或SCM模型来制定采集规范。

SPM叫**级位置模型，最早是受到土地户籍制度启发而设计的位置系统，目的应用于页面的统计、追踪页面的来源等场景，通常在埋点时作为埋点参数上报到数据后台。其编码形式采用A.B.C.D四层级进行组合，分别代表了业务、页面、页面区块、区块内的点位。

我们以小红书的商城首页举例：

业务：商城（shop_center）

页面：首页（home_page）

页面区块：变美季（beauty）

区块内点位：3

SPM模型命名澳大利亚·秋冬必备神级修复的位置内容就可以写成：shop_center.home_page.beauty.3

在统计数据时可以通过该参数知道这个模块的位置的流量大小情况。

SCM叫**级内容模型，用来标识唯一一块内容的模型，在埋点时SCM模型的数据作为埋点参数上报到数据后台，其编码形式和SPM一样也是通过A.B.C.D四个层级进行编码，只不过四个层级记录的信息与SPM有所差别，分别是：内容来源、投放算法、算法版本以及对应的人群。

还以上面的内容为例：

内容来源（content_source）:shop

投放算法（algorithm）：cf

算法版本（version）：3.3

对应人群（crowd）：woman

该条内容：澳大利亚·秋冬必备神级修复的内容情况如：shop.cf.3.3.woman

可以统计不同位置下该条内容所展示的信息和流量情况SPM和SCM作为两种不同的编码规范，我觉得可以根据自己的需要进行相关的改良，比如更改层级或更改定义等。

3. 工具

1) 埋点模型

埋点模型采用的是事件模型，事件模型描述了一个人做某件事情所需要的几个重点要素：时间（when）、地点（where）、人物（who）、途径（how）、结果（what）。

例如：小明4月3号早上9点用小米手机在京东买了一个iPhone12，转译到埋点语言就是：

以上设备信息均为虚拟信息，仅作参考

实现以上信息采集的埋点方式当前行业内有：代码埋点、无埋点。

① 代码埋点

代码埋点是根据具体埋点需求进行数据采集的方式，这也是用户行为数据最早的采集方式。

代码埋点可支持客户端埋点和服务端埋点。客户端埋点主要采集用户行为，服务端埋点更多采集的是业务数据。

优点：

1. 埋点可以做到按需采集、减少无效的信息上报；
2. 事件触发方式可以自定义，降低端上的资源消耗。

缺点：

1. 新增埋点周期较长，需要跟随版本迭代；
2. 管理成本较高，造成系统代码“冗余”；
3. 采集数据有“缺失”，只能获取到上线之后的数据。

② 无埋点

无埋点是识别端上各区块元素，对其进行全面的采集。

优点：

1. 新版本上线也可看到历史数据；
2. 前端埋点成本低，管理成本低；
3. 埋点范围覆盖相对较广。

缺点：

1. 数据冗余过剩；
2. 对应用开发的元素命名和开发规范要求严格；
3. 不能进行自定义数据的采集；
4. 服务端压力较大。

为了埋点数据全&准的两个准则，一般可以采取两种方式组合的方式。重点业务、非重点页面采用代码埋点，重点页面非重点业务采用无埋点。合理分配两种埋点策略做到不丢不漏在合理的维护成本范围内，尽可能多而全的采集。

2）埋点平台

虽然有了意识上的“统一“、制度上的规范，但我相信依旧有一些团队在沿用公用文档维护埋点信息。

文档化维护方式在信息量小的时候问题还不凸显，但当面对成百上千的埋点就**出现埋点信息维护不全、查找困难、测试同学面对“海量”的上报数据头晕眼花极容易漏测、实际上报与需求不符无法及时发现等问题。

所以埋点质量的最后一个环节就需要通过平台化来进行辅助管理，主要管理的方向有以下几个方向：

1. 元数据管理完善、可溯源，提升查询效率；
2. 自动化测试+人工校验、降低漏测风险；
3. 质量监控，提升对错误埋点的发现效率；
4. 引入埋点流程、辅助进行“团队管理”。

① 元数据的完善

元数据管理主要包含以下内容：事件基础信息、业务组织架构、当前开发状态、操作日志及变动日志。

1. 事件基础信息：事件ID&名称、参数ID&名称、参数值ID&名称，统计口径、上报时机、版本、需求地址等。
2. 业务组织架构：事件归属的页面、功能层级结构等信息。
3. 当前开发状态：该事件所处的流转状态，包括：需求中、需求完成、开发中、开发完成、测试中、测试上线、灰度、正式上线。
4. 操作日志及变动日志：记录系统上所有人员对于元数据的操作日志以及该事件历史版本变动日志等。

有了完备的元数据信息，还需要提供完善的筛选和查找机制，让埋点使用人员可以方便管理和查询。

同时平台可以根据埋点组件规范和埋点信息自动生成一段代码给到业务开发同学，即降低了代码埋点的开发成本，也降低了出错的概率。

② 自动化测试

对于测试而言，有了完善元数据后埋点平台可以提供：

• 自动化的测试功能：可以根据实际上报的数据明细自动比对元数据模块下维护的信息内容，在每次测试任务中都**自动提醒哪些事件不符合规范，极大的提高了测试效率，加上后期的人工校验，也**降低漏测的概率。
• 规范的数据展示方式以及详细的信息记录：传统的测试方式一边需要对着文档、一边需要看着一条巨长的上报数据来找到需要比对的信息来确认埋点是否准确。平台完全可以结构化上报数据，隐藏无关维度信息，并根据上报内容关键字（事件或参数信息）自动去元数据内进行数据查询，埋点同学每次测试任务只需要了解版本需求范围即可。

③ 质量监控

即使测试通过了，埋点数据就一定让人放心了么？肯定不是的。上线后面对大样本使用，用户App什么样的机型都有，甚至**被篡改一些信息。

为了能让最终上报的数据减少错误，埋点平台可以提供质量管理模块，具体监控策略可以根据数据质量评估标准通用的5项准则：完整性、及时性、唯一性、稳定性、准确性进行设定。

④ 引入埋点流程辅助

管理整个埋点平台使用流程，可以根据上面2.制度&流程的角色流程进行划分和管理。上线前每个环节由相关负责人员进行确认，多层确认机制可以保证埋点信息的完善和准确，也为后续管理上带来了极大的便利性。埋点平台功能框架参考如下：

三、写在最后

数据质量问题在业务发展到一定阶段都**遇到，就像升职以后需要管理团队一样，不同级别面临的问题不一样，所需要采用的手段也不一样。

希望本篇文章可以让那些即将面临这个问题或已经身在其中的小伙伴能有一部分可借鉴的地方。因篇幅问题，涉及SDK、埋点设计以及平台搭建的部分都没法详细展开描述，如果对此感兴趣或有疑问的同学欢迎一起交流。

作者：一个数据人的自留地；公众号：一个数据人的自留地

本文由@一个数据人的自留地 授权发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议。

给作者打赏，鼓励TA抓紧创作！

**赏

1人打赏