前言埋点数据是推荐、搜索、产品优化的基石。验证是第一位的。工欲善其事，必先利其器。要做好埋点验证，您将面临诸多技术挑战：易用性、准确性、实时性、稳定性和可扩展性。如何克服这些挑战，其实是技术。这也是本文的主题。目前，埋点验证已在字节中得到广泛应用。通过一键扫码开启验证，实时上报验证，自动生成验证报告，解决了埋点数据验证难、埋点质量难以保证的问题。跟踪点验证流程跟踪点生命周期：4+64个角色：PM、DA、RD、QA6个节点：提出需求、设计跟踪点、开发跟踪点、测试跟踪点、报告跟踪点、分析跟踪点、验证跟踪点流程：3+3+33角色：DA、RD、QA3节点：设计埋点、测试埋点、验收埋点3材料：埋点验证方案、埋点验证工具、埋点验证报告技术架构产品流程先简单介绍一下产品，让大家对平台有一个整体的了解，方便大家更容易的了解技术。平台主要包括三部分：埋点验证方案、埋点验证工具、埋点验证报告。大大降低了用户的埋点验证成本。埋点验证工具图附技术架构图。埋点验证环节很长，可以简单归纳为三个环节：埋点上报、埋点接收、埋点验证。每个环节都有一定的复杂性。这里先介绍一下整体流程，让大家快速了解整个流程。其次，我们主要关注“埋点验证”环节。这个环节最重要的部分是埋点验证引擎，它包括4个部分：规则生成器、规则选择器、埋点验证器和埋点推送器。埋点验证引擎的详解让大家对“如何验证埋点”有了更深入的了解。埋点上报环节的重点是丰富的SDK（客户端、服务端、JS、Chrome插件），要简单易用，保证埋点实时上报。埋点接收链路的重点是数据接收服务（client-applog、web-side-mcs、server-side-databus）、数据存储服务（消息队列），需要保证服务的稳定性，保证埋点不丢。埋点验证环节的重点是埋点验证引擎，必须保证服务的高性能和埋点验证结果的准确性。规则生成器规则生成器将“隐藏的验证方案”转换为“验证规则”。埋点验证方案是验证规则的逻辑视图，方便用户操作，降低编写和维护验证规则的成本。通过逻辑视图和物理视图两层逻辑，保证嵌点验证引擎底层不受业务变化的影响。埋点方案埋点验证方案支持2种：按需求验证：即一个新的需求计划，针对某个需求进行验证，元数据验证：元数据验证，元数据是指所有需求的并集，验证bymetadata:埋点名称：video_play参数信息（名称，类型，是否必填，取值校验，是否为场景条件）传递，取值无限制，无类型，整数，必填，枚举(1,2,3)，无埋点数据：{"app_id":100,"event":"click","params":{"enter_from":"login","duration":1,"type":3}}购买规则{"app_id":100,"event_name":"video_play","logical_filter":{"enter_from":"login"},"meta":{"required_field":["duration","enter_from","type"],"scene":{"condition":"enter_from=login","name":"loginpage"},"validate_field":["持续时间","enter_from","type"]},"physical_validation":"{\"$schema\":\"https://json-schema.org/draft/2019-09/schema\",\"type\":\"object\",\"properties\":{\"params\":{\"type\":\"object\",\"properties\":{\"duration\":{\"输入\":\"整数\"},\"enter_from\":{\"type\":\"string\",\"enum\":[\"login\"]},\"type\":{\"type\":\"integer\",\"enum\":[1,2,3]}},\"required\":[\"duration\",\"enter_from\",\"type\"]}},\"required\":[\"params\"]}","source":"schema_scene"}埋点规则字段描述app_id:applicationidevent_name:埋点名称logical_filter:用于“规则选择器”physical_validation:用于“埋点验证器”来源：区分规则来源：按需求验证，按元数据规则选择器验证规则选择器会选择对应的“埋点验证规则”选择逻辑：具体数据参见“规则Generator”根据“埋点数据”中的app_id和event从“ValidationRulePool”中过滤出“匹配规则”，并设置“埋点数据”的parms字段和“Matched”的login_filter规则字段Rules”匹配，最后选择“BuriedPointVerificationRules”BuriedPointValidator.Rules”，进行验证“埋点数据”输出“验证结果”。基本验证规则：埋点是否注册；埋点是否被禁用；是否为debug埋点；埋点校验规则：参数是否缺失；参数类型是否正确；参数值是否符合预期：枚举、范围、规律性；埋点验证结果：验证结果以双语形式提供，用户可选择中文或英文；埋点推送器埋点推送器将“埋点验证结果”推送到前端，推送过程数据交互频繁，数据量大，对数据传输稳定性有要求，这里我们构建Push服务进行数据传输，保证：数据是实时可用的。技术挑战易用性：快速接入埋点验证，快速启动埋点验证准确性：准确的埋点验证结果，用户可信度实时性：埋点数据实时可见稳定性：可靠的埋点数据不丢失可扩展性:快速接入新埋点数据格式Easeofuse快速接入埋点验证，快速启动埋点验证SDK快速接入埋点验证SDK提供“埋点验证开关”，客户端集成SDK时，可根据不同的使用环境配置是否开启“埋点验证开关”SDK层判断如果开启“埋点验证开关”，则埋点数据会被双发。这个过程对业务是透明的。双贴的原因还是为什么不从“在线埋点频道”进入？这里主要考虑两个原因：“在线埋点通道”的数据量太大。SDK层的在线上报逻辑是微批的形式。单独通道端SDK客户端如何开启埋点验证开关AndroidSDKIOSSDKAndroid和IOS提供API，开关默认关闭，可以在“域内测试包”中选择开启此开关”在整合业务方时。服务端GoSDKJavaSDKPythonSDK服务端会判断是否为离线环境。如果是离线环境，会默认开启“埋点验证开关”。Web端JSSDK浏览器插件1.JSSDK使用与客户端SDK相同的逻辑2.为了方便使用，我们还提供了一个浏览器插件，用户只需要打开这个插件-中，无需关注“埋点验证开关”扫码连接即可快速启动埋点验证连接流程EstablishWSconnection：服务器与验证平台建立长连接，用于通信ws_id：验证平台根据ws_id生成二维码扫码：客户端扫描二维码获取并打开验证开关：客户端获取设备信息并打开埋点验证开关上报device_id：客户端发送长连接信息并向服务器上报设备信息并发送device_id：服务器推送设备信息给验证平台开始验证：埋点验证平台进入验证阶段onstage上报埋点：客户端开始上报埋点推送埋点：服务端推送埋点到验证平台下发的原理客户端上报的埋点数据包含设备信息。用户在验证平台扫码回填设备信息后，服务器接收埋点数据，将埋点数据中的设备信息与验证平台的设备信息进行比对。匹配，匹配则下发埋点数据。准确的埋点验证结果是准确的，用户信任的埋点验证引擎必须保证埋点验证结果的准确性，才能降低验证成本。对于埋点数据本身的格式校验，我们采用JsonSchema作为校验方式，支持完整的校验规则和可信的校验结果。上面提到的“规则生成器”、“规则选择器”、“埋点验证器”也在一定程度上保证了埋点验证结果的准确性。埋点方案事件：video_play埋点名称：video_play参数信息（名称、类型、是否必填、取值校验、是否为场景条件）通过，无限值，无类型，整数，必须通过，枚举（1,2,3），无嵌入规则jsonSchema{"$schema":"https://json-schema.org/draft/2019-09/schema","type":"object","properties":{"params":{"type":"object","properties":{"duration":{"type":"integer"},"enter_from":{"type":"string","enum":["login"]},"type":{"type":"integer","enum":[1,2,3]}},"required":["duration","enter_from","type"]}},"required":["params"]}埋点数据event:video_play{"app_id":100,"event":"click","params":{"enter_from":"login","duration":1,"type":3}}验证结果事件：video_play测试地址：https://www.jsonschemavalidator.net/可以实时看到实时埋点数据在埋点验证场景下，服务端和验证平台需要频繁交互数据，所以我们构建了Push服务（基于WebSocket封装），可以保证数据的实时畅通。同一个客户端共享同一个长连接通道，实现可靠的心跳机制客户端和服务端基于通用的长连接通信协议实现稳定可靠的全双工通道，客户端实现通用的SDK，服务端实现通用的访问layer.客户端SDKa和服务端接入层都是，方便后续的服务接入。定时监控Push服务，同时打开http的Admin接口，方便系统监控和查看服务状态。推送服务优势连接稳定：推送服务分为Push和Backone两个组件，实现了业务和推送的解耦。Push是面向客户端的，设计越简单越好。需要维护大量的客户端活跃连接，避免业务服务更新时客户端连接服务的隔离：不同的业务服务连接推送服务，根据访问信息做集群。隔离避免业务间相互影响横向扩展：当业务服务数量不断增加时，只需要横向扩展推送服务即可支持推送服务流程稳定埋点数据可靠无损SLA定义：服务水平协议（service-等级协议（SLA）是服务提供商与客户之间的正式承诺，用于量化服务等级（质量、可用性、责任）埋点验证服务：该服务的特点是实时性，因此衡量手段埋点验证不可用是“数据延迟”，即如果埋点从“报告”->“验证平台”p99超过3s则视为不可用，每日p99可用性为1s双月故障时间年故障时间99.9%86.4m8.64h措施为保证“SLA”，我们做了一系列的保护措施。日志转换器：客户端、服务器、web端r导出原始日志格式，需要转换为埋点验证日志格式，然后进行验证措施监控，以保证在线服务的稳定性，监控在线流量，支持根据app查看app粒度的QPS粒度，以便在发生告警时可以快速定位到是哪个app的流量异常告警在线流量告警，告警策略设置如下：-当当前QPS达到最大qps的50%时，告警级别为warning，提示注意-当当前QPS达到最大qps的70%时，告警级别为critical，提示告警时必须处理限流，此时通过监控定位到具体的app，进行如下操作：1.限制本应用的数据流量，保证其他应用不受影响。2、联系应用业务方，确认本应用流量是否异常。3.如果是异常4.如果是正常流量，实时验证流程是目前主要的业务。当发现流量突然增加，无法解决限流时，降级自动化验证流程，保证主营业务稳定，快速扩展接入新的嵌入式数据格式。提供可插拔的“日志转换插件”，服务内聚性高，支持多种日志格式，快速访问。入场、检定展望埋点检定是保证埋点质量的有效途径。该方式属于预验证，适用于埋点变化频繁的业务场景。需要一定程度的人工干预，可以解决基本的埋点质量问题。问题但对于核心埋点场景，该方法验证成本高，需要反复人工输入。为了解决核心埋点验证成本高的问题，我们正在探索其他实现方式：回归验证（自动验证）：每次发布，都需要对核心埋点进行回归验证。目前，通过内部其他团队的合作，我们已经实现了自动验证功能，支持回归验证。目前部分业务正在使用，大大降低了验证核心埋点的成本。成本事后验证：经过事前验证和回归验证，埋点质量基本可以得到很好的保证。但为了更好的保障，我们也在探索事后验证的场景和实现：质量市场：通过“规则引擎”，结合“质量模型”对埋点数据质量进行评估，得到“质量得分”，然后针对质量问题进行专项修复，进一步提升埋点质量。质量工具：提供监控计划。商家可以为自己关心的埋点配置监控和告警。当线上出现质量问题时，会向商家发送质量报告，及时止损。全链路埋点质保：事前验证、回归验证、事后验证贯穿埋点生命周期，打通这三个流程，形成埋点质保全链路，彻底解决质量问题埋点问题。
