七猫统计埋点实践

一、概述

1.1 数据过程

大数据应用像一条工业流水线，它一般会有数据采集、数据加工、数据存储、数据计算及可视化这几个环节。数据采集，顾名思义采集相应的数据，是整个数据流的起点，采集的全不全、对不对，直接决定数据广度和质量，影响后续所有的环节。而埋点作为一种重要的采集手段，可以将用户行为信息转化为数据资产，为产品分析、业务决策、数据推荐、商业化应用等提供可靠的数据支持。

1.2 事件模型定义

事件模型：谁（WHO）在什么时间（WHEN）在什么地点（WHERE）做了什么事情（WHAT）。

其中各元素代表的意义：

例如：韩梅梅在2021-05-28 09:10:15分在WI-FI环境下启动了七猫免费小说。

其余的WHO、WHEN、WHERE都是通过客户端SDK统一的方式来定义和获取的，一次实现之后，少量优化和维护。而WHAT代表事件及属性，是跟业务使用紧密结合的，其质量的好坏，直接决定了后续数据系统的质量。

二、事件的定义

事件定义包含事件ID和事件属性两个部分。

2.1 事件ID

事件ID以“页面_组件_展位_事件类型”四段式位置追踪规范组成唯一事件ID。

其中各元素代表的意义：

如下图3-1所示，后台在埋点管理时，也按照对应页面、组件、展位、事件类型进行定义。

元素命名规范：

✔ ️“#”可以用作所有元素的通配符；

✔ ️不能出现汉字、拼音、拼音英文混用的情况；

✔ ️只有展位可以用数字命名，如果用数字要用纯数字，不要加入其他符号；

关于页面、组件、展位的定义，参照以下组图进行理解：

2.2 事件属性

事件属性指事件携带的可定义属性，如bookid（书籍ID）、chapterid（章节ID）、duration（看书时长）等，事件属性会提供一个固定列表，在使用中发现属性列表不能满足需要时，由大数据研发评估后增加属性。

三、配套系统

3.1 客户端SDK

分别开发了Android端和iOS端客户端SDK来采集WHO、WHEN、WHERE等公用数据，SDK对WHAT事件做一定预聚合之后上报，这一块的细节比较多，在后端客户端关于SDK的部分会详解。

3.2 日志接收系统

基于Golang研发，部署于K8S，结合Filebeat工具，完成了从日志接收、数据补全、落盘、转发的轻量化处理流程，保障数据的处理效率和稳定性。系统细节较多，会在后续的文章中详解。

3.3 日志埋点管理系统

日志埋点管理系统主要用来管理事件组成要素，包括项目、页面、组件、展位、事件类型、属性。同时日志埋点管理系统里记录的数据会作为日志检测系统的元数据，来对埋点合规性进行管理。

3.4 埋点检测系统

该系统同时具备数据合规性检测和埋点质量检测功能，它周期性拉取日志埋点管理系统的元数据，把从日志接收系统传递过来的数据，与其逐条进行比对、校验后，保留合规的、剔除不合规的，并通过邮件提醒对应的负责人。

四、埋点需求开发流程

需求流程如上图4-1所示：

Step1:一个埋点需求

即想在APP的某个页面某个位置添加一个事件，统计某个功能的使用情况。

Step2:日志埋点管理系统录入

在日志埋点管理系统里，按照事件ID的定义方式创建页面->创建组件->创建展位->选择事件类型、选择事件属性，完成后提交在后台里。

注：如果你所需要的页面、组件、展位已经存在，则不需要再创建，直接下拉选择即可。

Step3:埋点审核（目前是自动通过审核）

目前都是自动通过审核的，后续会考虑增加人工（数据产品、大数据研发）审核环节，确保数据埋点的质量。

Step4:研发执行埋点处理

研发根据产品提交的埋点需求，将正确的事件埋在正确的位置。

Step5:测试校验埋点准确性

研发完成后，需要测试进行埋点准确性的校验，我们的标准是，一个字符也不能错，错了就会被埋点检测系统过滤掉。

Step6:跟随版本发布上线

我们采用的是代码埋点的方式，必须发版才能发布新的埋点方案。

Step7:查看统计结果

版本发布上线后可在七猫统计里查看所埋事件的PV和UV等计算结果。

五、埋点的思想

5.1 多个点形成面

让一个面上的事件能够完整的铺开，把需要的位置都能统计到，可以有效分析整个页面的使用情况。

5.2 多个点连成线

让一个操作路径上的事件具有连贯性、逻辑性，形成一条紧密的线，便于使用情况追踪、转化漏斗计算。

例如：启动APP->选择性别、内容偏好->书城页打开->书籍展现->书籍点击->书籍详情页打开->阅读按钮点击->阅读器打开->翻章->翻章->......。

5.3 只埋小位置

事件是由“页面_组件_展位_事件类型”组成的，只埋小位置也就是说，我们要在“展位”这个层面进行埋点，系统会自动对“页面”、“页面_组件”维度进行上卷计算。

如下图5-1所以，书城男生频道页中，组件C是主编推荐区域，我们在埋点的时候只需要给其中的3本书对应的展位分别进行埋点即可，系统会自动计算出组件C的点击量。

5.4 埋点单一职责原则

每个事件的作用是独立的，只代表一个意义和功能，不需要二次推导其作用。

如终章页里的“换一换”按钮，它代表的就是“换一换”功能的触发情况，而不是让它同时具备“换一换”和与之相关的书籍展现统计。

5.5 多功能操作要多个埋点

同一个按钮，如果有多种功能，从维度拆分的角度来说，应该埋多个事件，细化粒度，提升数据利用效率。

如终章页有个“加入书架并继续阅读”按钮，那在这个按钮触发的时候，就应该埋下去“加入书架”和“阅读”两个事件。

5.6 埋点属性的添加要针对被操作的对象

所有的埋点属性的应用，应该是基于被操作的那个对象是什么。

如终章页里由A书推出了B书，那点击加入书架按钮的时候，bookid的值应该为B书ID，因为被操作的对象是B。

5.7 合理利用事件类型

尤其是对内容方面来说，不同事件类型（show、click、join、move、read等）代表了其对内容的不同喜好程度，是可以根据不同操作类型来给用户行为打分的。

注：慎重增加新的事件类型。

5.8 双端统一实现方式

同样的功能，双端在实现时，要对埋点、技术实现方案进行统一。