关于埋点:一文读懂字节跳动埋点验证平台

49次阅读

共计 5055 个字符，预计需要花费 13 分钟才能阅读完成。

序言

埋点数据作为举荐、搜寻、产品优化的基石，其数据品质的重要性显而易见，而要保障埋点数据的品质，埋点验证则首当其冲。工欲善其事必先利其器，要做好埋点验证会面临很多技术挑战：易用性、准确性、实时性、稳定性、扩展性，如何攻克这些挑战呢，其实还是技术，这也是本文的宗旨所在。目前埋点验证已在字节外部失去宽泛应用，通过一键扫码开启验证、实时上报验证、主动生成验证报告，解决了埋点数据验证难、埋点品质保障难的问题。
埋点验证流程埋点生命周期：4+6

  • 4 个角色：PM、DA、RD、QA
  • 6 个节点：提出需要、设计埋点、开发埋点、测试埋点、上报埋点、剖析埋点
    埋点验证流程：3+3+3
  • 3 个角色：DA、RD、QA
  • 3 个节点：设计埋点、测试埋点、验收埋点

  • 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：利用 id
  • event_name：埋点名称
  • logical_filter：用于“规定选择器”
  • physical_validation：用于“埋点验证器”
  • source：辨别规定起源：按需要验证、按元数据验证

规定选择器

规定选择器将根据“埋点”中的要害信息，从“验证规定池”中抉择出对应的“埋点验证规定”。

  • 抉择逻辑：具体数据参考“规定生成器”

    • 依据“埋点数据”中 app_id 和 event 从“验证规定池”中筛选出“匹配的规定”

    • 将“埋点数据”的 parms 字段和“匹配的规定”的 login_filter 规字段进行匹配，抉择出最终的“埋点验证规定”

      埋点验证器

      埋点验证器将根据“根底验证规定”以及“规定选择器”产出的“埋点验证规定”，对“埋点数据”进行验证并产出“验证后果”。

  • 根底验证规定：埋点是否注销；埋点是否禁用；是否是 debug 埋点；
  • 埋点验证规定：参数是否失落；参数类型是否正确；参数取值是否合乎预期: 枚举、范畴、正则；

  • 埋点验证后果：验证后果提供双语格局，用户可自行抉择中文或者英文；

    埋点推送器

    埋点推送器将“埋点验证后果”推送到前端，推送的过程存在数据交互频繁、数据体积大、数据传输稳定性的要求，这里咱们自建 Push 服务进行数据传输，保证数据实时可达。

    技术挑战

  • 易用性：疾速接入埋点验证，疾速开始埋点验证
  • 准确性：埋点验证后果精确、用户可信
  • 实时性：埋点数据实时可见
  • 稳定性：埋点数据牢靠不失落

  • 扩展性：疾速接入新的埋点数据格式

    易用性：

    疾速接入埋点验证，疾速开始埋点验证

    SDK

  • 疾速接入埋点验证
  • SDK 提供“埋点验证开关”，客户端集成 SDK 的时候，可依据不同环境来配置是否开启“埋点验证开关”

  • SDK 层判断如果开启“埋点验证开关”，埋点数据会双发，此过程对业务是通明的

    1. 双发的起因或者为什么不从“线上埋点通道”取数？这里次要思考两个起因：

      1. “线上埋点通道”数据量太大
      2. SDK 层线上上报逻辑是采纳微批的模式，默认 1 分钟从客户端上报一次，而埋点验证要求实时性，所以采纳独自的通道

      扫码连贯

  • 疾速开始埋点验证

  • 连贯流程

    1. 建设 WS 连贯：服务端和验证平台建设长连贯，用于通信
    2. ws_id：验证平台依据 ws_id 生成二维码
    3. 扫码：客户端扫描二维码
    4. 获取并关上验证开关：客户端获取设施信息并且关上埋点验证开关
    5. 上报 device_id：客户端将长连贯信息和设施信息上报至服务端
    6. 下发 device_id：服务端将设施信息推送到验证平台
    7. 开始验证：埋点验证平台进入验证阶段
    8. 上报埋点：客户端开始上报埋点
    9. 推送埋点：服务端将埋点推送到验证平台

  • 下发原理

    1. 客户端上报的埋点数据中含有设施信息
    2. 用户通过扫码在验证平台回填设施信息
    3. 服务端接管到埋点数据后，将埋点数据中的设施信息和验证平台的设施信息进行匹配，如果匹配则将埋点数据进行下发

准确性

埋点验证后果精确、用户可信
埋点验证引擎必须保障埋点验证后果的准确性，能力升高验证老本。针对埋点数据自身的格局验证，咱们采纳了 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

  • 测试地址：https://www.jsonschemavalidat…

实时性

埋点数据实时可见
埋点验证场景下，服务端和验证平台须要频繁地进行数据交互，所以咱们自建了 Push 服务(基于 WebSocket 的封装)，可能保证数据的实时畅通性

Push 服务指标

  1. 基于 WebSocket 实现一套通用长连贯通信协定，能实现同一个客户端上的不同业务共享同一个长连贯通道，并实现牢靠的心跳机制。
  2. 客户端和服务端基于通用长连贯通信协定实现一个稳固牢靠的全双工通道。
  3. 客户端实现一个通用的 SDK，服务端实现一个通用接入层。
  4. 客户端 SDK，服务端接入层，都要很不便后续 service 接入。

  5. Push 服务定期做打点监控，同时凋谢 http 的 Admin 接口，不便零碎的监控和查看服务状态

    Push 服务劣势

  6. 连贯稳定性：Push 服务分为两个组件 Push 和 Backone，实现了业务和推送解耦。push 面向客户端连贯，设计尽可能简略，需放弃大量客户端沉闷连贯，防止了业务服务更新时不影响客户端连贯
  7. 服务隔离性：不同的业务服务接入 push 服务，会依据接入信息做集群隔离，防止业务之间相互影响

  8. 横向扩展性：当业务服务一直增多时，只需对 push 服务做横向扩容即可反对

    Push 服务流程

稳定性

埋点数据牢靠不失落

SLA

  1. 定义：服务级别协定 (service-level agreement，即 SLA) 是服务提供方与客户之间的正式承诺，用来量化服务水平(品质、可用性、责任)

  2. 埋点验证服务：服务的特色是实时，所以掂量埋点验证不可用的伎俩是“数据提早”，即埋点从“上报”->“验证平台”的 p99 超过 3s 即视为不可用，日常 p99 在 1s

    措施

    为了保障“SLA”，咱们做了一系列的保护措施
    日志转换器：客户端、服务端、web 端上报的是原始日志格局，须要转换为埋点验证日志格局后进行验证

    扩展性

    疾速接入新的埋点数据格式

  3. 提供可插拔的“日志转换器插件”，服务高内聚，可反对各种日志格局疾速接入、验证

瞻望

埋点验证是保障埋点品质的无效形式，此形式属于事先验证，实用于埋点频繁变动的业务场景，须要肯定水平的人工染指，可能解决根本的埋点品质问题。然而对于外围埋点场景来说，这种形式的验证老本较高，须要反复的人力投入，为了解决外围埋点验证老本高的问题，咱们正在摸索落地其余形式：

  • 回归验证(自动化验证)：随同每次发版，外围埋点都须要进行回归验证，目前咱们通过外部其余团队的单干实现了自动化验证性能来撑持回归验证，以后已有一部分业务正在应用，极大地升高了验证外围埋点的老本
  • 预先验证：通过事先验证、回归验证，埋点品质根本能失去很好的保障。但为了更好的保障咱们也在摸索预先验证的场景和落地：
    品质大盘：通过“规定引擎”，联合“品质模型”对埋点数据进行品质评估，得出各个维度的“品质评分”，而后针对品质问题进行专项修复，进一步提高埋点品质。
    品质工具：提供监控打算，业务能够针对本人关注的埋点配置监控报警，当线上呈现品质问题，会发送品质报告给业务，及时止损。
  • 全链路埋点品质保障：事先验证、回归验证、预先验证贯通埋点的生命周期，买通这三个流程，从而造成埋点品质保障全链路，彻底解决埋点品质问题。

立刻跳转火山引擎大数据研发治理套件产品官网理解详情！

正文完
埋点
发表至： 埋点
2022-08-08
 0
关于埋点:一文读懂字节跳动埋点验证平台
关于埋点:云音乐曙光埋点还原数据理想国
关于埋点:业务线用户路径问题
关于埋点:前端组件化埋点的实践