七猫统计埋点实践

一、概述

1.1 数据过程

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

1.2 事件模型定义

事件模型:谁(WHO)在什么时间(WHEN)在什么地点(WHERE)做了什么事情(WHAT)。

其中各元素代表的意义:

元素

意义

WHO

设备标识符集合

WHEN

事件触发时间、接收时间

WHERE

设备环境、网络环境、业务环境等

WHAT

事件、事件属性

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

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

二、事件的定义

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

2.1 事件ID

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

其中各元素代表的意义:

元素

意义

页面

APP中一个独立的功能页面

组件

APP中某个页面下的一个功能模块区域

展位

APP中某个页面某个组件下的具体的一个功能元素

事件类型

该次事件动作的类型如展现点击阅读等

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

图3-1 管理后台

元素命名规范:

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

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

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

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

图3-2 书城页面
图3-3 七猫中文网

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 埋点需求流程

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

Step1:一个埋点需求

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

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

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

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

图4-2 在埋点系统录入事件

Step3:埋点审核(目前是自动通过审核)

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

Step4:研发执行埋点处理

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

Step5:测试校验埋点准确性

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

Step6:跟随版本发布上线

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

Step7:查看统计结果

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

图4-3 查看统计结果

五、埋点的思想

5.1 多个点形成面

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

5.2 多个点连成线

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

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

5.3 只埋小位置

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

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

图5-1 只埋小位置

5.4 埋点单一职责原则

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

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

5.5 多功能操作要多个埋点

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

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

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

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

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

5.7 合理利用事件类型

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

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

5.8 双端统一实现方式

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

展示评论