序言埋点数据作为举荐、搜寻、产品优化的基石，其数据品质的重要性显而易见，而要保障埋点数据的品质，埋点验证则首当其冲。工欲善其事必先利其器，要做好埋点验证会面临很多技术挑战：易用性、准确性、实时性、稳定性、扩展性，如何攻克这些挑战呢，其实还是技术，这也是本文的宗旨所在。目前埋点验证已在字节外部失去宽泛应用，通过一键扫码开启验证、实时上报验证、主动生成验证报告，解决了埋点数据验证难、埋点品质保障难的问题。埋点验证流程埋点生命周期：4+6
4个角色：PM、DA、RD、QA6个节点：提出需要、设计埋点、开发埋点、测试埋点、上报埋点、剖析埋点埋点验证流程：3+3+33 个角色：DA、RD、QA3 个节点：设计埋点、测试埋点、验收埋点3 个物料：埋点验证计划、埋点验证工具、埋点验证报告
技术架构产品流程先简略介绍一下产品，以便大家能对平台有整体意识，不便大家更加轻松地了解技术，平台次要包含三局部：埋点验证计划、埋点验证工具、埋点验证报告，三者相辅相成，极大的升高了用户的埋点验证老本。附埋点验证工具图
技术架构图埋点验证的链路很长，能够简略概括为三个环节：埋点上报、埋点接管、埋点验证，每个环节都有肯定的复杂性，此处先介绍整体流程，让大家能够疾速对全流程有所意识。其次将次要聚焦于“埋点验证”环节，此环节的重中之重是埋点验证引擎，它包含 4 个局部：规定生成器、规定选择器、埋点验证器和埋点推送器，通过对埋点验证引擎的详解让大家对“埋点如何验证”有更深的了解。
埋点上报环节重点是丰盛的 SDK(客户端、服务端、JS、Chrome 插件)，要做到简略易用并且保障埋点实时上报。埋点接管环节重点是数据接管服务(客户端-applog、Web 端-mcs、服务端-databus)、数据保留服务(音讯队列)，要保障服务稳固并且保障埋点不失落。埋点验证环节重点是埋点验证引擎，要确保服务高性能并且保障埋点验证后果的准确性。
规定生成器规定生成器将“埋点验证计划”转换为“验证规定”。埋点验证计划是验证规定的逻辑视图，不便用户操作，升高验证规定的编写和保护老本。通过逻辑视图和物理视图两层逻辑，确保了埋点验证引擎底层不受业务变动的影响。
埋点计划埋点验证计划反对 2 种：
按需要验证：即新建需要打算，针对某次需要验证按元数据验证：即按元数据验证，元数据是指所有需要的并集按元数据验证：埋点名称：video_play参数信息
(名称、类型、是否必填、值校验、是否是场景条件)enter_from,string,必传,固定值(login),是duration,integer,必传,值无限度,否type,integer,必传,枚举(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":"登录页" }, "validate_field":[ "duration", "enter_from", "type" ] }, "physical_validation":"{\"$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\"]}", "source":"schema_scene"}埋点规定字段阐明
app_id：利用idevent_name：埋点名称logical_filter：用于“规定选择器”physical_validation：用于“埋点验证器”source：辨别规定起源：按需要验证、按元数据验证规定选择器规定选择器将根据“埋点”中的要害信息，从“验证规定池”中抉择出对应的“埋点验证规定”。
抉择逻辑：具体数据参考“规定生成器”
依据“埋点数据”中app_id和event从“验证规定池”中筛选出“匹配的规定”将“埋点数据”的parms字段和“匹配的规定”的login_filter规字段进行匹配，抉择出最终的“埋点验证规定”
埋点验证器埋点验证器将根据“根底验证规定”以及“规定选择器”产出的“埋点验证规定”，对“埋点数据”进行验证并产出“验证后果”。
根底验证规定：埋点是否注销；埋点是否禁用；是否是debug埋点；埋点验证规定：参数是否失落；参数类型是否正确；参数取值是否合乎预期:枚举、范畴、正则；埋点验证后果：验证后果提供双语格局，用户可自行抉择中文或者英文；
埋点推送器埋点推送器将“埋点验证后果”推送到前端，推送的过程存在数据交互频繁、数据体积大、数据传输稳定性的要求，这里咱们自建 Push 服务进行数据传输，保证数据实时可达。
技术挑战易用性：疾速接入埋点验证，疾速开始埋点验证准确性：埋点验证后果精确、用户可信实时性：埋点数据实时可见稳定性：埋点数据牢靠不失落扩展性：疾速接入新的埋点数据格式
易用性：疾速接入埋点验证，疾速开始埋点验证SDK疾速接入埋点验证SDK提供“埋点验证开关”，客户端集成SDK的时候，可依据不同环境来配置是否开启“埋点验证开关”SDK层判断如果开启“埋点验证开关”，埋点数据会双发，此过程对业务是通明的
双发的起因或者为什么不从“线上埋点通道”取数？这里次要思考两个起因：
“线上埋点通道”数据量太大SDK层线上上报逻辑是采纳微批的模式，默认1分钟从客户端上报一次，而埋点验证要求实时性，所以采纳独自的通道
扫码连贯疾速开始埋点验证连贯流程
建设WS连贯：服务端和验证平台建设长连贯，用于通信ws_id：验证平台依据ws_id生成二维码扫码：客户端扫描二维码获取并关上验证开关：客户端获取设施信息并且关上埋点验证开关上报device_id：客户端将长连贯信息和设施信息上报至服务端下发device_id：服务端将设施信息推送到验证平台开始验证：埋点验证平台进入验证阶段上报埋点：客户端开始上报埋点推送埋点：服务端将埋点推送到验证平台下发原理
客户端上报的埋点数据中含有设施信息用户通过扫码在验证平台回填设施信息服务端接管到埋点数据后，将埋点数据中的设施信息和验证平台的设施信息进行匹配，如果匹配则将埋点数据进行下发准确性埋点验证后果精确、用户可信埋点验证引擎必须保障埋点验证后果的准确性，能力升高验证老本。针对埋点数据自身的格局验证，咱们采纳了JsonSchema作为验证伎俩，以反对欠缺的验证规定、可信的验证后果。上文中的“规定生成器”、“规定选择器”、“埋点验证器”也都在肯定水平上保障了埋点验证后果的准确性。埋点计划 event:video_play埋点名称：video_play参数信息
(名称、类型、是否必填、值校验、是否是场景条件)enter_from,string,必传,固定值(login),是duration,integer,必传,值无限度,否type,integer,必传,枚举(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 }}验证后果event:video_play
...