本文介绍了打点治理的概念和其对于数据质量保障的重要性，分享了日志中台在打点治理方面的解决方案与实践经验。文章从用户痛点和打点治理的难点出发，介绍了日志中台如何通过质量标准的制定、在线化流程的建设和相应的配套工具来解决这些问题。

　　打点是指在网站或者APP中加入一些统计代码，通过日志记录用户在APP内触发的一系列行为，包括点击、滑动等。打点上报后汇聚成用户行为日志，用户行为日志可用于报表统计、AB Testing、个性化推荐等，是分析用户、调整策略、迭代产品的重要依据。

　　打点治理是指在打点的生命周期内对其进行监控与管理，目标是确保数据的准确性、及时性、可比性、一致性、适用性和可获得性。在实践中我们经常会发现，日志数据总是会变得无效以至于无用、甚至有时新增打点也因为各种原因变得杂乱无章。因此从增量数据产生到存量数据维护的全流程，都是打点治理不可忽视的内容，也是日志中台关注的重点。

　　日志中台建设并打磨打点平台，聚焦打点内容管理、管理打点全生命周期、推动打点规范设计、打点开发测试、打点效果验证等工具在业务侧落地。本文从打点平台角度，描述日志中台在打点治理方面提供的解决方案与实践经验。

　　01 用户痛点

　　数据需求从被提出、添加打点、到最后使用数据，涉及到很多用户角色和步骤：

　　业务方（多为市场运营团队或产品经理）提出数据统计&分析需求；

　　数据PM设计打点方案，这里可以复用已有的打点，也可以新增打点；

　　打点RD进行打点代码开发；

　　QA进行打点测试，一般从打点日志的内容和触发时机两个维度进行测试；

　　数据RD完成数据表&看板建设；

　　业务方基于数据表&看板，满足统计&分析需求。

　　不同用户角色在整个打点周期中的痛点不尽相同：

　　数据应用方：

　　查找难度大：点位多且缺乏管理，不清楚有哪些历史打点，点位代表的业务含义是什么；

　　难以直接使用：打点经过多次迭代后，点位规范与打点代码不再一致，含义不再清晰；

　　质量无法确定：不确定如何衡量打点质量，打点是否准确可用存疑。

　　数据生产方：

　　流程机制欠缺：打点涉及的角色多，流程多，协同难度高；

　　缺乏工具支持：打点设计、开发、测试、验收、监控纯人工操作，效率低。

　　针对已上痛点，日志中台从打点质量评估、流程规范和配套的工具等多个层面提供了解决方案：

　　质量标准：

　　对一条打点日志是否合规正确进行了明确定义，帮助业务方衡量数据质量、解决质量无法确定的问题；

　　通过历史数据迁移、线上日志补录形式填充打点规则集合，提升打点数据可用性、助力业务使用打点。

　　打点在线化全流程：抽象出了规范的打点全流程并实现在线化，填充了流程机制的欠缺。

　　配套提效工具：

　　规范设计:

　　提供打点规则编辑功能，能够在线设计点位规范；

　　建设页面场景树管理模型，帮助从业务全局视角了解与管理点位。

　　开发测试：

　　支持APP扫码后实时抓取日志功能，开发阶段能够直观看到日志详情；

　　通过规则匹配能力实时校验日志合规情况、能够一键生成点位测试报告，实现了高效可靠的打点测试。

　　验证评估：

　　定义并统计大盘点位整体合规率、流量波动大的点位发送邮件报警，帮助业务方监控打点与其质量水平；

　　提供线上PV等指标的实时数据，点位能够即埋即看、快速验收。

　　下文将从以上两个基础能力（质量标准、在线化全流程）和三个层面的配套工具角度，详细阐述日志中台打点平台在打点治理方面的建设。

　　02 质量标准

　　打点质量的规范标准是打点治理的前提与基础，只有明确了什么样的日志数据是准确的、清晰了如何衡量去打点数据质量，才能够摸清打点数据现状、了解打点质量水平。

　　日志数据对应各个点位的打点规范，规范中应包含上报日志的字段名、字段值类型&长度等属性，上报的数据应该在各个维度都需要匹配上打点设计好的规范，才能够被划分为合规、使得打点日志在真正处理有据可依、数据在应用时的含义能够被明确保障。日志平台在建设初期，就支持了打点基础规范的管理、迁移了历史的老打点数据，通过推动业务方使用平台录入新的打点规范、帮助历史使用内部文档的业务方批量导入规范数据等方式与手段，快速建立了初期的规范全集。　　

　　△通过规则匹配功能，确定打点日志是否合规

　　通过平台的规则匹配功能，将规范集与打点日志相匹配，计算得出了初步的大盘合规情况。由于百度APP历史打点多、规范缺乏维护等客观因素，中台通过离线老版本日志抽取后自动补齐了部分打点的规范，解决了部分当前数据同学在使用数据时对于历史打点规范不清晰的痛点，能够使历史数据得到更有效的利用、也扩充了大盘打点规范集合。

　　在摸底过程中，老版本日志双端规范不一致、SQL语言的弱类型特性，也使得字段类型通过简单基础的string number boolean object array五大类型难以合法表达，打点平台也扩充了objectstring类型（支持上报字符串类型的object但配置内部结构）、weaknumber/weakobject类型（支持Android/iOS双端上报number/object时一端上报字符串类型的number/object场景），帮助业务方解决已经无法发版修复的老打点无法合规表达的问题、更好地聚焦于增量打点与规范的严格约束。　　

　　△打点规则集的建设

　　通过对于打点规则集的建设，打点的标准得到了清晰明显的定义，是业务方了解自身已有打点形态的基础、能够通过规则与实际日志的对比来确定打点日志的合规准确性，更是平台衡量全局打点质量水平、对打点进行针对性治理、直观观测治理效果的基础。

　　03 打点流程

　　从打点需求提出到打点上线，中台根据角色和工作职责，抽象出了提需->设计->审核->开发->测试->验收->上线的打点全流程。流程的在线化，使得跨部门协作中进展的追踪、信息的传达、工作的流转、操作的留痕等关键性问题有了可靠有力的保障手段。

　　同时，中台也引入数据BP审核机制，其作为各业务打点的数据干系人，对打点从需求提出到数据验收上线的全流程审核并负责。借助打点平台以及在线化流程管理，打点责任到人、流程清晰，高效线上操作、及时跟踪进展，保证了执行效果和数据质量。　　

　　△打点在线化管理全流程

　　04 规范设计

　　打点语法表义与打点业务含义是否准确是影响打点质量的两大关键，也是打点质量问题频现的场景，例如：

　　语法：

　　字段类型不匹配：应该上报boolean类型的参数，上报为0/1的integer类型；

　　字段长度不符合要求：参数值过长，超过设定的合理范围；

　　字段值不符合枚举要求：应上报为click的字段，错打为Click。

　　语义：

　　缺失上报：如点击某个按钮后没有进行上报；

　　重复上报：如一次页面的滑动，上报多次打点；

　　打点触发时机不对：如页面展现打点，在点击按钮时上报；

　　上报内容不准确：如点击元素A时，打点上报元素B。

　　日志中台针对以上问题，提供了打点规范的平台化表达工具，并且在长时间实践中总结了打点的页面场景树模型，并将约束时机规范的事件关联对应到页面位置和点位，综合表达了打点的准确含义。

　　点位日志规范表达：字段名、类型、长度、是否必传、枚举值是日志规范的重要组成因素，平台支持配置与管理string number boolean array object objectstring六大类型字段的多层级嵌套表达，能够低成本结构化表达点位必传属性、长度限制、枚举值精准/模糊（正则）等打点规范，能够在语法层面对于打点进行准确清晰的表达。　　

　　△点位规范整体表达　　

　　△多种字段类型支持　　

　　△枚举值管理　　

　　△正则匹配

　　页面场景树模型：通过topic、产品线、位置、点位的层次关系描述整个打点拓扑，从产品页面和点位双方向提供了打点的位置地图，解决打点位置不清晰、相同位置多打、不同位置漏打错打等问题，也助力业务侧从顶层视角着手每次打点的规范设计，统一业务方整体打点的规范。　　

　　△表达页面及页面结构　　

　　△页面视角查看各位置绑定的点位　　

　　△点位视角查看其绑定的页面位置

　　事件规范管理：事件是包含了时机约束的一系列规范，业务方维护适合自身业务场景的事件规范后，将打点与其绑定，就可以在设计阶段准确表达每个打点应该上报与不应上报的时机，为后续打点开发测试人员的打点含义理解、以及打点含义准确性的校验提供了基础。　　

　　△打点事件规范的表达

　　05 开发测试

　　传统抓包测试时，QA需要人工抓包、肉眼验证，很多打点问题难以被发现：

　　语法是否合规：打点上报与方案中设置的字段名称、字段类型是否一致，是否符合标注的参数长度约束、参数的枚举值范围等。

　　语义是否准确：打点上报是否符合点位设计中上报、上报时机、条数等规则。

　　在日志中台，业务方通过打点平台设计并表达点位的约日志规范后，中台会依托这些约束规则生成一系列相匹配的测试规则，在测试过程中进行自动匹配、测试，为业务测试打点数据提供了切实有效的提效工具。　　

　　在进行打点测试时，业务侧RD或QA可以通用手机扫码或输入用户ID的形式，将APP与日志汇聚服务建立连接。在App上操作触发打点后，打点校验服务可以实时获取到用户上报的数据，使用打点设计时生成的测试规则，便可以自动将日志与规则匹配并得到校验结果，在打点平台上实时展示上报的每一条日志是否合规，并且可以为多条日志生成测试报告。

　　打点平台提供了实时验证的测试工具，可以根据打点规范自动测试上报数据的准确性，并且能够将测试报告一键生成后、推送给PM在下个打点流程环节进行验收，全面助力打点开发与测试阶段的质量保障与效率提升。

　　06 效果验证与评估

　　打点上线后，实际效果的验证与持续监控也是打点质量中不可忽视的事后管理内容。中台从质量、流量、业务三个方面，设立多方位指标监控体系，助力业务方对于存量打点的把控，做到打点数据质量的长期治理。

　　质量角度，在数据质量模型这一基础标准上，定义并计算合规率。

　　对线上上报的日志进行抽样，抽样的总pv做分母，其中合规部分的pv做分子，计算整体合规率；点位流量根据业务方向划分后，计算分方向合规率，能够从整体大盘与细分业务两个角度监控数据合规情况；

　　关注业务个性化需求、收集各业务不同点位的关注程度，通过对核心点位的标记单独计算核心点位合规率，提升业务方对核心功能、核心数据的及时把控与管理；

　　△整体与分业务合规情况

　　由于历史版本已经发版、不合规日志的打点很难修复，为剔除老数据影响、聚焦增量打点的更加精细化且更加严格的把控，中台在存量合规率的基础上定义了增量合规率——拆分出百度APP不同版本需求对于点位规范的更新、计算新版本日志对于当期需求增量变更规范的合规情况，为业务方提供增量打点质量的观测渠道。　　

　　△增量合规率的计算方法

　　流量角度，日志量级有异常波动时，发送邮件到点位负责人与业务数据BP，做到打点日志量级的自动监控。

　　业务角度，依托中台服务端的实时统计，可以分点位、分页面、分场景地查看实时（15min时效）pv与时长指标，支持下钻。业务可以自定义字段规则进行流量分业务场景的查询，提供了更加精细化的实时观测工具，能够及时发现细分场景业务流量异常。　　

　　△支持自定义业务规则的流量查询

　　07 总结

　　综上，依托于日志中台的打点链路，打点平台在设计表达、开发测试、验证评估监控等多个方面提供了工具，配合在线化的打点全流程管理，致力于增量与存量打点质量的把控治理。同时，随着对业务理解的不断深入，中台的打点模型、流程和平台技术仍在不断迭代，希望能够更好地在业务侧应用与实践。