数据埋点太难!知乎的做法有何可借鉴之处?

标签: 数据 知乎 | 发表时间:2018-08-28 08:00 | 作者:
出处:http://www.phpxs.com

埋点作为商业智能(BI)和人工智能(AI)体系中重要的一环,是公司提升产品工程质量、实施 AB Testing、个性化推荐服务重要的数据来源。在传统的纯 Web 和 Native 开发的产品中,埋点从技术的角度来说未必多深奥,但从业务的角度来说要做到埋点设计规范、流程高效和保证质量却是很难。本文重点介绍一下知乎客户端的埋点模型、流程和平台技术。

数据埋点太难!知乎的做法有何可借鉴之处?

客户端埋点为什么难?

Web 端的埋点可以随着新代码上线即时生效,对版本的发车概念相对较弱,即使埋点错漏,修复成本较低。

对客户端而言,如果使用 Native 技术开发的功能埋点有问题,则需要等下一个版本才能修复,并且还有版本覆盖度的问题。修复埋点的这个时间窗口一般都比较长,会对业务的产品快速迭代产生很负面的影响。从业务的角度来说,客户端在发布功能之前,对于要做的数据分析不见得想得全,无计划收集非常多的埋点,对于埋点设计人员、客户端开发、测试人员来说是很大的工作量。反过来说,真正要用数时才发现重要的埋点没有采集,则会 「点」 到用时方恨少。因此,如何综合规划一个版本要采集的埋点,也是颇有挑战的事情,颇有「养兵千日,用兵一时」的感觉。

埋点的流程

从业务过程中采集埋点,是数据驱动型公司的必要条件。知乎的产品功能评审环节,不仅有 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,在客户端开发上,我们主要遇到以下问题:

  • 采集需要的数据有时和客户端功能开发无关,客户端获取数据难
  • 当数据结构较复杂,客户端工作量增大
  • 打错和打漏的情况,需要发版,周期长面对上述打点,对于不是必须由客户端获取的数据改成由业务后端生成 Protocol Buffers 结构,序列化成 string 随 api 带回客户端,客户端只需将 string 放置到通用的位置即可。数据平台组统一的实时 ETL 程序会反序列化该结构,过程如下图所示。

数据埋点太难!知乎的做法有何可借鉴之处?

对于 What,在埋点设计上,目前主要遇到以下问题:

  • 埋点的 Key 越来越多,字段和业务并没有在系统级别绑定关系,有些字段多个业务在用,枚举值越来越多,对埋点设计者造成了较多的信息噪音
  • 业务依赖了其他业务的打点,埋点变更可能导致其他业务的核心指标受到影响

第一个问题我们正在对埋点字段进行治理,将平台通用字段和业务字段做系统级别的元信息完善。第二个问题,我们目前还在探索中。「他山之石,可以攻玉」,如果大家在这块有好的实践经验,欢迎给文章评论中分享知识。

埋点的平台技术

埋点管理平台

当公司的规模生态还很小时,埋点使用 Excel 或者 Wiki 管理对埋点使用上影响不大。当公司业务快速发展,从一个产品变成多个产品,从几十个埋点变成几千个埋点,想要精准的用好埋点,就需要开发埋点的管理平台了。

埋点管理平台负责管理埋点的元信息,解决了埋点的录入和查找需求,同时简化了客户端埋点的内容, 是知乎埋点流程的重要组成部分。同时在工程上又为埋点测试平台,数据采集系统提供埋点的元信息接口。

查看埋点

支持按照多个标签来查找和过滤埋点。 在创建埋点时,需要花时间录入这些元信息,从长期来看,收益会非常大。

数据埋点太难!知乎的做法有何可借鉴之处?

创建埋点

在创建埋点时,填写埋点对应的业务元信息和技术元信息,包括埋点对应的测试说明。埋点管理平台提供埋点的 key,如果需要新增 key 则可向平台申请。对于 enum 类型的 value,系统会自动补全。

生成埋点设计文档

埋点设计文档是工程师开发埋点的依据,是埋点流程中交流需要的重要「媒介」。埋点文档标准化了埋点的设计,包含埋点的以下信息:

  1. 埋点的基本信息:业务、等级、应用、使用说明、打点时机、测试说明、需求文档等
  2. 埋点对应的角色:数据负责人、开发、QA
  3. 埋点对应的字段和字段的取值

提供埋点元信息 API

数据采集服务会对采集到的埋点写入到 Kafka 中,对于各个业务的实时数据消费需求,我们为每个业务提供了单独的 Kafka,流量分发模块会定期读取埋点管理平台提供的元信息,将流量实时分发的各业务 Kafka 中。

数据埋点太难!知乎的做法有何可借鉴之处?

埋点测试平台

埋点的质量是数据的生命线,一旦出现问题,则会导致整条大数据链路的数据价值出现问题。埋点异常不但影响决策,修复数据同样会消耗大量的精力和时间,最直接的后果就是虽然数据量越来越大,数据本身却无法有效的使用。知乎的数据团队在 2016 年做了一个埋点的小工具,只要输入测试设备的 id,就可以查看对应的埋点信息。这个工具主要有以下几个痛点:

  • 埋点日志量大,通常很难找到自己想测试的埋点
  • 展示一整条日志,系统无法判定埋点是否准确,全靠肉眼来看
  • 无法创建测试用例,不能做回归测试
  • 埋点漏了或者错了人力尚能发现,埋点重复发送人很难发现

面对如上问题,我们重新设计了埋点测试平台,目标是让埋点测试更自动化和智能化,主要有以下功能:

  • 可创建埋点测试用例,打通埋点管理平台,支持多条件筛选埋点
  • 支持发起埋点测试实例,只展示埋点测试用例中的埋点,多余信息单独展示
  • 自动化提示埋点打错、打漏和打重,前端界面高亮展示,生成测试报告
  • 支持手机扫码连上系统,无需人输设备 id

数据埋点太难!知乎的做法有何可借鉴之处?

其他:关于 Hybrid 类型埋点

客户端内的 H5 生成埋点使用的是 JavaScript SDK,如果直接发送到日志收集服务,会丢失客户端的重要属性。知乎的做法是将 H5 的日志发送给客户端,由客户端处理后发送给日志接收服务。在知乎我们对 H5 这类统称 Hybrid,我们自研了 Hybrid 框架,跨端通信和埋点传输由框架提供支持,自动化解决和 ZA (Zhihu Analytics Log Server)的通信问题。

数据埋点太难!知乎的做法有何可借鉴之处?

Hybrid 框架主要处理以下的问题:

  • 对于 Native 和 JS 混合的页面,该页面曝光统计
  • 对于 JS 页面内部的跳转,页面曝光的统计
  • JS SDK 生成的日志,传输到 Native,并发送给日志收集服务
  • 对于 UTM 系列追踪链,做到跨 Native 和 JS 支持

总  结

今天的大数据发展趋势之快,对于很多公司来说都是挑战,埋点是数据整个数据链路中的起点,是数据的生命之源。随着知乎的快速发展,业务越来越多,知乎的埋点模型、流程和平台技术在不断迭代当中,在应用实践上还有很大的改进的空间。

团队介绍

知乎的大数据平台团队,属于知乎的技术中台,是具有数据驱动基因的公司发展到一定阶段必然会重点打造的团队。面对业务的多元化发展和精细化运营,数据的需求变得越来越多,大数据平台团队主要负责:

  • 搭建公司级可视化分析系统和数据服务
  • 维护全端数据的采集、集成和数据仓库,对接业务系统
  • 管理数据生命周期,提供一站式的数据开发、元信息管理和任务调度平台
  • 提供 AB Testing 实验平台,系统化集成实验分析框架,推动业务增长

 

来自:http://www.infoq.com/cn/articles/event-tracking-in-zhihu

 

相关 [数据 知乎] 推荐:

大数据: 知乎1.3万亿条数据毫秒级响应

- -
Zhihu,在中文古典中文中意为“你知道吗. ”是中国的Quora:一个问答网站,其中各种问题由用户社区创建,回答,编辑和组织. 作为中国最大的知识共享平台,我们目前拥有2.2亿注册用户,3000万个问题,网站答案超过1.3亿. 随着用户群的增长,我们的应用程序的数据大小无法实现. 我们的Moneta应用程序中存储了大约1.3万亿行数据(存储用户已经阅读过的帖子).

数据埋点太难!知乎的做法有何可借鉴之处?

- - 编程学习网
埋点作为商业智能(BI)和人工智能(AI)体系中重要的一环,是公司提升产品工程质量、实施 AB Testing、个性化推荐服务重要的数据来源. 在传统的纯 Web 和 Native 开发的产品中,埋点从技术的角度来说未必多深奥,但从业务的角度来说要做到埋点设计规范、流程高效和保证质量却是很难. 本文重点介绍一下知乎客户端的埋点模型、流程和平台技术.

ElasticSearch在数十亿级别数据下,如何提高查询效率? - 知乎

- -
es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊. 这个问题是肯定要问的,说白了,就是看你有没有实际干过 es,因为啥. 其实 es 性能并没有你想象中那么好的. 很多时候数据量大了,特别是有几亿条数据的时候,可能你会懵逼的发现,跑个搜索怎么一下. 5~10s,后面反而就快了,可能就几百毫秒.

处理海量数据:列式存储综述(存储篇) - 知乎

- -
列式存储(Column-oriented Storage)并不是一项新技术,最早可以追溯到 1983 年的论文 Cantor. 然而,受限于早期的硬件条件和使用场景,主流的事务型数据库(OLTP)大多采用行式存储,直到近几年分析型数据库(OLAP)的兴起,列式存储这一概念又变得流行. 总的来说,列式存储的优势一方面体现在存储上能节约空间、减少 IO,另一方面依靠列式数据结构做了计算上的优化.

运营商是怎么分析出数据通道中特定 App 的数据流量的? - 知乎

- -
主要是通过DPI(Deep Packet Inspection)来实现的,一般称之为「深度报文检测」或「深度包检测」. 从字面意思来讲,所谓「深度」是相对于普通的报文检测而言的. 普通的报文检测仅分析IP包的层4以下5元素:源地址、目的地址、源端口、目的端口及协议类型. 而DPI除了对以上5元素进行分析外,增加了应用层分析,用来识别各种应用及其内容.

不衰的经典: ARIES事务恢复 [数据库学习的成人试炼] - 知乎

- -
已经好几个月没写东西了, 比较忙, 开的技能树有点多, 主要在刷概率/统计/优化/NLP相关的东西, 分布式的东西看的比较少, 只是偶尔刷刷小红书的推荐论文还有看看datalake相关的东西; 不过ARIES这篇论文还是很值得在知乎记个笔记的.. 小红书的时候在第三章“Techniques Everyone Should Know”(很明显我还没入门啊, 这些paper几乎都没看过.

机构、研究员写文章的调研数据是从哪里找的 - 知乎

- -
研究员写作文章的数据来源均有三大类: . 1、第一类是我们公司自有的一手数据,我司是深圳前瞻商业资讯有限公司,长期跟踪研究1000多个行业、与10万余企业有良好合作关系,从而积累了丰富的一手调研数据,并且建立了专业的数据库;. 2、第二类是来自于官方、协会数据,我司拥有国家统计局、国家税务局、海关总署、工信部、商务部等三十余个官方部门数据查询权限,并且与国内500余协会形成合作关系;.

知乎 HBase 实践 - 知乎

- -
HBase 是一个基于 Hadoop 面向列的非关系型分布式数据库(NoSQL), 设计概念来源于谷歌的 BigTable 模型,面向实时读写、随机访问大规模数据集的场景,是一个高可靠性、高性能、高伸缩的分布式存储系统,在大数据相关领域应用广泛. HBase 系统支持对所存储的数据进行透明切分,从而使得系统的存储以及计算具有良好的水平扩展性..

知乎问答

- - 人月神话的BLOG
没有编程经验的,至少需要掌握哪些知识,才能胜任软件产品的需求分析工作. 在这里首先要注意编程经验和懂编程,编码和软件工程是两回事情. 举个例子你没有在生产线做过工人,但是不代表你不可以了解一个产品从原材料开始如何从生产线生产出来的. 你可以当生产线去参观和学习,当然如果你能够在生产线实习一段时间印象更加深刻.