知乎客户端埋点流程、模型和平台技术

标签: 知乎 客户端 模型 | 发表时间:2018-08-01 00:00 | 作者:雨舟
出处:http://www.zhihu.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

准确定位一个事件发生的位置。主要包含以下几个字段提供埋点设计者来做用户事件的定位。

   {
 optional LogType type = 1;      // 日志类型
 optional int32 id = 2;          // 由埋点管理平台生成,作用类似大家通常用的 event_name
 optional string url = 3;        // 当前页面 url
 repeated ModulePath module = 4; // 该位置所处的模块,模块之间的嵌套以及模块在父模块中的位置
}

What

在事件发生位置上的内容信息,这里采集的内容由业务决定。 例如点击的卡片是一个回答还是一个 Live,当前内容的状态这类需求。

对于业务定制化的「What」,最初我们为个性化的需求,设计了通用的 ContentInfo,以及特定领域的数据结构。

   message BusinessInfo {
 optional ContentInfo content = 1;
 optional PlayInfo play = 2;
 optional SearchInfo search = 3;
 optional ReadInfo read = 4;
}


对于 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 框架,跨端通信和埋点传输由框架提供支持,自动化解决和日志接收服务的通信问题。

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

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

总结

今天的大数据发展趋势之快,对于很多公司来说都是挑战,埋点是数据整个数据链路中的起点,是数据的生命之源。随着知乎的快速发展,业务越来越多,知乎的埋点模型、流程和平台技术在不断迭代当中,在应用实践上还有很大的改进的空间。欢迎对数据开发感兴趣的朋友加入我们,详情请见: 传送门 资深传送门

团队介绍

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

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



来源:知乎 www.zhihu.com
作者: 雨舟

【知乎日报】千万用户的选择,做朋友圈里的新鲜事分享大牛。 点击下载

相关 [知乎 客户端 模型] 推荐:

知乎客户端埋点流程、模型和平台技术

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

深度剖析知乎目前的内容架构模型

- - 互联网分析沙龙 - 干货
本文深度剖析知乎目前的内容架构模型,对于社区应用开发者可将其中的架构思维推广到一般 UGC 网站产品的优化上. 知乎是目前国内用户平均素质最高的网站,其日均访问 IP 在 60 万以上. 对于这样一个用户活跃度极高、产出大量优质内容(UGC)网站来说,如何把内容更好地组织呈现并将其中优质部分的价值最大化,非常重要.

MongoDB 客户端 MongoVue

- - haohtml's blog
今天在同事那里看到了一个很不错的MongoDB的客户端工具MongoVue,地址是 http://www.mongovue.com/. 做的不错,1.0版本的开始收费了,费用也不贵才35$. 真正需要的同学可以掏点钱买个吧,也算是支持这个工具,如果只是学习研究用的话我这里还有一个0.9.7版本,虽然比起1.0版来说有些bug,平常使用也够了,需要的同学可以单独联系我.

[转]memCached 客户端

- - 小鸥的博客
memcache客户端下载. 许多Web应用都将数据保存到DBMS中,应用服务器从中读取数据并在浏览器中显示. 但随着数据量的增大、访问的集中,就会出现RDBMS的负担加重、数据库响应恶化、 网站显示延迟等重大影响. memcached 是以LiveJournal 旗下Danga Interactive 公司的Brad Fitzpatric 为首开发的一款软件.

客户端·优化

- - 博客园_首页
网络连接和初始HTTP请求. 浏览器检索网页,先从URL开始,使用DNS确定IP地址,再用基于TCP和HTTP协议连接到服务器,请求相关的内容,得到相应,浏览器解析并呈现到屏幕上. 服务器响应后,浏览器响应不会同时全部到达,会陆续到达,有时候之间还会有时间间隔. 页面解析和新的资源请求浏览器等待数据包时,会解析得到包,并寻找可用新的HTTP请求,并启动,每一个服务器,浏览器一般最多同时打开两个请求连接.

BitCoin for Ubuntu 11.04 客户端

- Riku - Wow! Ubuntu
BitCoin 最近很热,大量的媒体、Blog ,甚至叽喳上都在谈论此物. 那么 BitCoin 到底为何物. [以下引用自 ivarptr 的文章,详情请看“通俗易懂讲解什么是 Bitcoin 虚拟货币”一文]. Bitcoin (为了便于书写和理解,下面如果是表示 “Bitcoin币”意思的地方我称呼其为“贝壳币”,取粤语相近的音译)是一种网络虚拟货币,跟腾讯公司的Q币类似,你可以使用贝壳币购买一些虚拟的物品,比如网络游戏当中的衣服、帽子、装备等,只要有人接受,你也可以使用贝壳币购买现实生活当中的物品.

GClient – Google+ 桌面客户端

- 闷闲居士 - 软件街
就是一个SNS社交网站,在这个社交网站上你可以和不同兴趣的好友分享好玩的东西. Google+ 在网络上占着举足轻重的地位,G粉整天挂着浏览器,随时观看有没有新的通知,这样还是蛮累滴,如果有G+桌面客户端那多方便. 没错就是有这么一款 Google+ 桌面工具:GClient,支持通知新信息,还可以直接在桌面玩转Google+ ….

叽喳客户端 Polly

- We_Get - Wow! Ubuntu
Linux 平台上的叽喳客户端我们介绍过很多,比如 Hotot ,Pino,Twip 等等. 现在要介绍的 Polly 是款全新的叽喳客户端,目前还处于 pre-alpha 阶段,它的主要功能如下:. 与 Messaging Menu 整合. # Ubuntu 11.04 及 11.10 用户安装.

知乎 HBase 实践 - 知乎

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

优秀的Android Twitter客户端

- 馒头 - Solidot
Irene Janes 写道 "无论用任何标准衡量,社交网络正日益成为生活的一部分. Twitter是最流行的社交网络服务之一. 12个月前,它每天约发送6500万条消息;今天,这一数字已经上升到每天超过2亿条,相当于2亿注册用户每人每天发送一条. Twitter从根本上改变了许多人的交流方式.