编辑导读：数据埋点作为一种常用的数据采集方式，无疑对产品的正常运行起着至关重要的作用，而埋点的质量管理尤为重要。那么，埋点过程中常见的质量问题有哪些呢？我们应该采取什么措施来防止这些问题？ 　　

　　

　　 　　

　　

　　如今，互联网人对数据的使用既恐惧又正常。虽然有些是日常工作，有些只是少数需求，但无论有多依赖数据，在数据使用或解读方面，都要满足以下一两种情况。 　　

　　

　　*有个新同学来团队，想分析某个功能的数据，但又觉得无奈。问老员工这个功能对应的埋点和那个页面对应的参数，他们会得到的不是口碑就是聊天记录里的文档地址。面对暗埋的信息，估计野兽已经开始疾驰了； 　　

　　

　　*新版本上线后进行效果分析，发现埋点有瑕疵。这个时候如果是重要数据，就要紧急找人发布版本，时间紧又怕。如果是此时的一般数据，开发同学回复的概率很大：“用下一个版本迭代”，半年后再分析。估计没人能解释这种数据波动的原因。 　　

　　

　　*考研生持有协作埋藏的文件。在测试过程中，发现要么是字段对应错误，要么是信息维护不完整。翻译起来很麻烦。如果遇到大版本，就需要进行埋点回归，不仅导致测试过程工作量大，还会带来漏测的风险。 　　

　　

　　作为日常数据(包括业务数据和对外合作数据)的三大重要来源之一，埋藏数据至关重要。会影响推荐、AB实验、数据分析的准确性；会影响仓库的结构设计和日常维护成本。目前，数据被公司视为资产进行估值。想象一下，在年底，面对一大堆“切割不停，整理管理”的数据会是什么样子。 　　

　　

　　希望通过这篇文章，通过总结我最近接手的埋点质量项目的一些经验，和大家分享一下我的经验。 　　

　　

　　# 1.埋点有哪些质量问题？ 　　

　　

　　嵌入过程的整个环节比较长，涉及的角色也比较多。故障排除困难，周期长，涉及团队合作的问题不易控制。我们总结一下哪些环节容易出现问题，导致质量问题被埋没。 　　

　　

　　 　　

　　

　　如果在数据输出阶段不对数据进行控制，那么在应用阶段就会出现数据不完整、数据重复、数据不一致、数据不匹配等数据问题。因此，解决埋地质量问题，应遵循“预防为主、防治结合、综合治理”的原则。让我们来看看如何管理掩埋场的质量。 　　

　　

　　# 2.埋点质量如何管理？ 　　

　　

　　开展埋点质量管理，笔者认为可以从以下三个角度来实施：意识、系统流程、工具。 　　

　　

　　## 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协议。