一、概述
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 双端统一实现方式
同样的功能，双端在实现时，要对埋点、技术实现方案进行统一。