埋点作为商业智能（BI）和人工智能（AI）体系中重要的一环，是公司提高产品工程质量、实施ABTesting、个性化推荐服务重要的数据来源。在传统的纯Web和Native开发的产品中，埋点从技术的角度来说未必多晦涩，但从业务的角度来说要做到埋点设计规范、流程高效和保证质量却是很难。本文重点介绍一下知乎顾客端的埋点模型、流程和平台技术。
顾客端埋点为何难？
Web端的埋点可以随着新代码上线即时生效，对版本的发车概念相对较弱，虽然埋点错漏，修补成本较低。
对顾客端而言，假若使用Native技术开发的功能埋点有问题，则须要等下一个版本能够修补，而且还有版本覆盖度的问题。修补埋点的这个时间窗口通常都比较长，会对业务的产品快速迭代形成很负面的影响。从业务的角度来说，顾客端在发布功能之前，对于要做的数据剖析不见得想得全，无计划搜集特别多的埋点，对于埋点设计人员、客户端开发、测试人员来说是很大的工作量。反过来说，真正要用数时才发觉重要的埋点没有采集，则会「点」到用时方恨少。为此，怎么综合规划一个版本要采集的埋点，也是颇具挑战的事情，颇具「养兵千日，用兵一时」的觉得。
埋点的流程
从业务过程中采集埋点，是数据驱动型公司的必要条件。知乎的产品功能评审环节，除了有PRD(Productrequirementdocument），还加入了对应的DRD(Datarequirementdocument）。对于埋点而言，DRD须要明晰业务目标与埋点缺口之间的关系以及需求的优先级。埋点的需求大多来自于DRD，整个过程会涉及多个角色，主要包括产品总监、业务数据负责人、开发工程师、测试工程师。
目前知乎的埋点流程如右图所示。
回顾知乎埋点流程的迭代史，整个流程落地三部曲可以总结为六个字：能力、意愿、工具。
能力
这几年知乎的业务发展很快，埋点的流程也随着迭代了好多个版本。在数据平台组创立之初就研制了全端埋点SDK和日志的接收服务。在有了埋点SDK以后，数据平台组开始在公司推广埋点工作，在初期是埋点的推进方和设计者，致使公司基本具备了打点的能力。
意愿
为了快速推动业务的埋点，数据平台组急聘了埋点设计人员来设计全公司的打点。这个方式在短期内帮助公司的埋点工作顺利进行，并且很快随着业务持续的下降，虽然是埋点设计的老鸟也难以快速响应业务的埋点需求，跨业务的任务排期也给业务带来较多的困惑。我们发觉埋点的流程如果做到业务闭环，能让整个流程显得更为高效和顺利。业务中那个角色更有意愿来设计埋点是流程是否高效的重要诱因。以下是业务几个和数据有关角色的主要工作内容：
●数据剖析师和产品总监主要是数据的使用者，工作内容是发觉和解决业务的问题，不断对产品进行迭代
●工程师对代码的细节和打点时机最为了解，而且对于数据具体的使用不见得很清晰
●数据库房插口人负责业务数据的生产，和数据库房团队对接，对埋点的定义须要有深入的理解
综合考虑各角色的意愿后，我们设计了「业务数据负责人」这个角色，来整体来负责业务的数据生产工作，主要负责业务数据库房需求和埋点设计。
工具
初期埋点测试只有一个能力有限的小工具，用户体验并不够好，直接将埋点测试作为顾客端发版流程中的一部份只会整体增加测试工程师的效率。顾客端发版常常会碰到新增的埋点打重、打错和打漏，老的埋点缺乏回归测试等等问题，给业务带来了不少困惑。因而一个易用性高、自动化和智能化的埋点测试平台成了当时迫在眉睫的事情。在开发完一整套埋点管理和测试系统后，测试工程师将埋点加入了顾客端发版流程，并对全公司埋点做了整体评审，推动业务建立了埋点的元信息，并对核心埋点创建了回归测试。在埋点测试平台有效使用上去以后，埋点的质量相比之前得到了大幅度的提高。
埋点的模型
俗语有云：「治大国若烹小鲜」。目前知乎的埋点数目约为三千个，倘若缺乏统一的模型来做标准化，每位人设计下来的埋点都不一样。数据平台因此提供公司级通用的埋点模型，既要有公司级别的规范，又要满足业务个性化的需求。
在技术上，我们使用ProtocolBuffers管理埋点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
确切定位一个风波发生的位置。主要包含以下几个数组提供埋点设计者来做用户风波的定位。
optionalLogTypetype=1;//日志类型
optionalint32id=2;//由埋点管理平台生成，作用类似你们一般用的event_name
optionalstringurl=3;//当前页面url
repeatedModulePathmodule=4;//该位置所处的模块，模块之间的嵌套以及模块在父模块中的位置
What
在风波发生位置上的内容信息，这儿采集的内容由业务决定。诸如点击的卡片是一个回答还是一个Live，当前内容的状态这类需求。
对于业务多样化的「What」，最初我们为个性化的需求，设计了通用的ContentInfo，以及特定领域的数据结构。
messageBusinessInfo{
optionalContentInfocontent=3;
optionalPlayInfoplay=16;
optionalSearchInfosearch=4;
//电子书阅读
optionalReadInforead=22;
对于What，在顾客端开发上，我们主要遇见以下问题：
●采集须要的数据有时和顾客端功能开发无关，顾客端获取数据难
●当数据结构较复杂，顾客端工作量减小
●打错和打漏的情况，须要发版，周期长
面对上述打点，对于不是必须由顾客端获取的数据改成由业务前端生成ProtocolBuffers结构，序列化成string随api带回顾客端，顾客端只需将string放置到通用的位置即可。数据平台组统一的实时ETL程序会反序列化该结构，过程如右图所示。
对于What，在埋点设计上，目前主要遇见以下问题：
●埋点的Key越来越多快手埋点赞的平台，数组和业务并没有在系统级别绑定关系，有些数组多个业务在用，枚举值越来越多，对埋点设计者引起了较多的信息噪声
●业务依赖了其他业务的打点，埋点变更可能引起其他业务的核心指标深受影响
第一个问题我们正在对埋点数组进行整治，将平台通用数组和业务主键做系统级别的元信息构建。第二个问题，我们目前还在探求中。「他山之石，可以攻玉」，倘若你们在这块有好的实践经验，欢迎给文章评论中分享知识。
埋点的平台技术埋点管理平台
当公司的规模生态还很小时，埋点使用Excel或则Wiki管理对埋点使用上影响不大。当公司业务快速发展，从一个产品弄成多个产品，从几十个埋点弄成几千个埋点，想要精准的用好埋点，就须要开发埋点的管理平台了。
埋点管理平台负责管理埋点的元信息，解决了埋点的录入和查找需求，同时简化了顾客端埋点的内容，是知乎埋点流程的重要组成部份。同时在工程上又为埋点测试平台，数据采集系统提供埋点的元信息插口。
查看埋点
支持根据多个标签来查找和过滤埋点。在创建埋点时，须要花时间录入这种元信息，从常年来看，利润会特别大。
创建埋点
在创建埋点时，填写埋点对应的业务元信息和技术元信息，包括埋点对应的测试说明。
埋点管理平台提供埋点的key，假如须要新增key则可向平台申请。对于enum类型的value，系统会手动补全。
生成埋点设计文档
埋点设计文档是工程师开发埋点的根据，是埋点流程中交流须要的重要「媒介」。埋点文档标准化了埋点的设计，包含埋点的以下信息：
埋点的基本信息：业务、等级、应用、使用说明、打点时机、测试说明、需求文档等
埋点对应的角色：数据负责人、开发、QA
埋点对应的数组和数组的取值
提供埋点元信息API
数据采集服务会对采集到的埋点写入到Kafka中，对于各个业务的实时数据消费需求，我们为每位业务提供了单独的Kafka，流量分发模块会定期读取埋点管理平台提供的元信息，将流量实时分发的各业务Kafka中。
埋点测试平台
埋点的质量是数据的生命线，一旦出现问题，则会造成整条大数据链路的数据价值出现问题。埋点异常不但影响决策，修补数据同样会消耗大量的精力和时间，最直接的后果就是即使数据量越来越大，数据本身却未能有效的使用。
知乎的数据团队在2016年做了一个埋点的小工具，只要输入测试设备的id，就可以查看对应的埋点信息。这个工具主要有以下几个痛点：
●埋点日志量大，一般很难找到自己想测试的埋点
●展示一整条日志，系统难以判断埋点是否确切，全靠肉眼来看
●无法创建测试用例，不能做回归测试
●埋点漏了或则错了人力尚能发觉，埋点重复发送人很难发觉
面对如上问题，我们重新设计了埋点测试平台，目标是让埋点测试更手动化和智能化，主要有以下功能：
●可创建埋点测试用例，打通埋点管理平台，支持多条件筛选埋点
●支持发起埋点测试实例，只展示埋点测试用例中的埋点，多余信息单独展示
●自动化提示埋点打错、打漏和打重，后端界面高亮展示，生成测试报告
●支持手机扫码连上系统，无需人输设备id
其他：关于Hybrid类型埋点
顾客端内的H5生成埋点使用的是JavaScriptSDK，倘若直接发送到日志搜集服务，会遗失顾客端的重要属性。知乎的做法是将H5的日志发献给顾客端，由顾客端处理后发送给日志接收服务。在知乎我们对H5这类也称Hybrid，我们自研了Hybrid框架，跨端通讯和埋点传输由框架提供支持，手动化解决和ZA（ZhihuAnalyticsLogServer）的通讯问题。
Hybrid框架主要处理以下的问题：
●对于Native和JS混和的页面，该页面爆光统计
●对于JS页面内部的跳转，页面爆光的统计
●JSSDK生成的日志，传输到Native，并发献给日志搜集服务
●对于UTM系列追踪链，做到跨Native和JS支持
总结
明天的大数据发展趋势之快快手埋点赞的平台，对于好多公司来说都是挑战，埋点是数据整个数据链路中的起点，是数据的生命之源。随着知乎的快速发展，业务越来越多，知乎的埋点模型、流程和平台技术在不断迭代当中，在应用实践上还有很大的改进的空间。欢迎对数据开发感兴趣的同学加入我们，详情请见：
团队介绍
知乎的大数据平台团队，属于知乎的技术中台，是具有数据驱动基因的公司发展到一定阶段必然会重点塑造的团队。面对业务的多样化发展和精细化营运，数据的需求显得越来越多，大数据平台团队主要负责：
●搭建公司级可视化剖析系统和数据服务
●维护全端数据的采集、集成和数据库房，对接业务系统
●管理数据生命周期，提供一站式的数据开发、元信息管理和任务调度平台
●提供ABTesting实验平台，系统化集成实验剖析框架，促进业务下降
