一、概述
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所示,后台在埋点管理时,也按照对应页面、组件、展位、事件类型进行定义。
元素命名规范:
✔ ️“#”可以用作所有元素的通配符;
✔ ️不能出现汉字、拼音、拼音英文混用的情况;
✔ ️只有展位可以用数字命名,如果用数字要用纯数字,不要加入其他符号;
关于页面、组件、展位的定义,参照以下组图进行理解:
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 双端统一实现方式
同样的功能,双端在实现时,要对埋点、技术实现方案进行统一。