知乎数据埋点方案.docxVIP

知乎数据埋点方案 埋点的流程 从业务过程中采集埋点，是数据驱动型公司的必要条件。知乎的产品功能评审环节，不只要 PRD (Product requirement document），还加入了对应的 DRD ( Data requirement document）。对于埋点而言，DRD 需要明确业务目标与埋点缺口之间的关系以及需求的优先级。埋点的需求大多来自于 DRD，整个过程会涉及多个角色，次要包括产品经理、业务数据担任人、开发工程师、测试工程师。 目前知乎的埋点流程如下图所示。 回顾知乎埋点流程的迭代史，整个流程落地三部曲可以总结为六个字：力量、意愿、工具。 力量 这几年知乎的业务进展很快，埋点的流程也随着迭代了很多个版本。在数据平台组成立之初就研发了全端埋点 SDK 和日志的接收服务。在有了埋点 SDK 之后，数据平台组开头在公司推广埋点工作，在晚期是埋点的推动方和设计者，使得公司基本具备了打点的力量。 意愿 为了快速推动业务的埋点，数据平台组聘请了埋点设计人员来设计全公司的打点。这个方法在短期内挂念公司的埋点工作顺当进行，但是很快随着业务持续的增长，即便是埋点设计的老手也无法快速响应业务的埋点需求，跨业务的任务排期也给业务带来较多的困扰。我们发觉埋点的流程假如做到业务闭环，能让整个流程变得更为高效和顺当。业务中哪个角色更有意愿来设计埋点是流程能否高效的重要因素。以下是业务几个和数据有关角色的次要工作内容： 数据分析师和产品经理次要是数据的使用者，工作内容是发觉和处理业务的问题，不断对产品进行迭代 工程师对代码的细节和打点时机最为了解，但是对于数据具体的使用不见得很清楚 数据仓库接口人担任业务数据的生产，和数据仓库团队对接，对埋点的定义需要有深化的理解综合考虑各角色的意愿后，我们设计了「业务数据担任人」这个角色，来全体来担任业务的数据生产工作，次要担任业务数据仓库需求和埋点设计。 工具 晚期埋点测试只要一个力量有限的小工具，用户体验并不够好，直接将埋点测试作为客户端发版流程中的一部分只会全体降低测试工程师的效率。客户端发版往往会遇到新增的埋点打重、打错和打漏，老的埋点缺少回归测试等等问题，给业务带来了不少困扰。因而一个易用性高、自动化和智能化的埋点测试平台成了当时迫在眉睫的事情。在开发完一整套埋点管理和测试系统后，测试工程师将埋点加入了客户端发版流程，并对全公司埋点做了全体评审，推动业务完善了埋点的元信息，并对核心埋点创建了回归测试。在埋点测试平台有效使用起来之后，埋点的质量相比之前得到了大幅度的提升。 埋点的模型 古语有云：「治大国若烹小鲜」。目前知乎的埋点数量约为三千个，假如缺少统一的模型来做标准化，每个人设计出来的埋点都不一样。数据平台为此供应公司级通用的埋点模型，既要有公司级别的规范，又要满足业务共性化的需求。在技术上，我们使用 Protocol Buffers 管理埋点 Schema，统一埋点字段和 enum 类型取值，统一 SDK 发版。 页面扫瞄 页面扫瞄的统计，对于 Web 端而言， 由于 URL 格外明确， 统计规章简约清新。通常来说，依据一些正则对 URL 进行分类，即可统计出某类页面的 PV。 对于客户端而言，统计的方式和 Web 端比较相像。由于客户端不像 Web 端自然?具备 URL，因而需要为页面伪造 URL。只需能被定义 URL，那么 URL 变化了，即可算一次新的 PV。客户端页面扫瞄统计中，我们遇到的最难的问题是：页面是什么？假如说页面的跳转算一次新的曝光，问题在于页面的功能变化多少算一次页面的跳转？一个典型的场景是一个页面中某子模块进行了 Tab 间切换时，当前页面的 PV 该如何统计。目前对于这个问题，知乎目前没有做统一，由业务本人来定义。 行为大事 对于行为大事，知乎选择了大事模型，完整描述 Who、When、Where、How 和 What 五大要素。 Who、When 和 How Who：用户和设备的身份特征。 When：埋点触发的时间。 How：埋点发生时，用户当前的形态，例如网络是 4G 还是 Wifi，当前的 AB 试验命中情况等等。模型中 Who、When、How 由埋点 SDK 自动生成，埋点人员在绝大多数情况下不必关怀这三个要素。 Where 精确?????定位一个大事发生的位置。次要包含以下几个字段供应埋点设计者来做用户大事的定位。 What 在大事发生位置上的内容信息，这里采集的内容由业务打算。 例如点击的卡片是一个回答还是一个 Live，当前内容的形态这类需求。 对于业务定制化的「What」，最后我们为共性化的需求，设计了通用的 ContentInfo，以及特定领域的数据结构。 对于 What，在客户端开发上，我们次要遇到以下问题： 采集需要的数据有时和客户端功