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

用户痛点

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

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

• 数据PM设计打点方案，这里可以复用已有的打点，也可以新增打点；
• 打点RD进行打点代码开发；
• QA进行打点测试，一般从打点日志的内容和触发时机两个维度进行测试；
• 数据RD完成数据表&看板建设；
• 业务方基于数据表&看板，满足统计&分析需求。

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

• 数据应用方：

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

• 难以直接使用：打点经过多次迭代后，点位规范与打点代码不再一致，含义不再清晰；
• 质量无法确定：不确定如何衡量打点质量，打点是否准确可用存疑。
• 数据生产方：
• 流程机制欠缺：打点涉及的角色多，流程多，协同难度高；

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

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

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

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

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

• 配套提效工具：

• 规范设计:
  

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

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

• 开发测试：
  

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

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

• 验证评估：

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

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

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

质量标准

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

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

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

△打点规则集的建设

打点流程

△打点在线化管理全流程

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

• 语法：
• 字段类型不匹配：应该上报boolean类型的参数，上报为0/1的integer类型；
• 字段长度不符合要求：参数值过长，超过设定的合理范围；
• 字段值不符合枚举要求：应上报为click的字段，错打为Click。
• 语义：
• 缺失上报：如点击某个按钮后没有进行上报；
• 重复上报：如一次页面的滑动，上报多次打点；
• 打点触发时机不对：如页面展现打点，在点击按钮时上报；

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

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

△点位规范整体表达

△多种字段类型支持

△枚举值管理

△正则匹配

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

△表达页面及页面结构

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

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

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

△打点事件规范的表达

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

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

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

效果验证与评估

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

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

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

△合规率计算公式

△整体与分业务合规情况

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

△增量合规率的计算方法

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

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

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

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