事件模型
-
一个事件的触发，有4个因素：触发者、触发位置、触发的事件、触发的时间。
触发者
- 触发者即触发事件的用户；
- 需要一个唯一标识，来识别不同的用户；
- 同时，需要识别在不同平台的同一个用户。
触发位置
- 为了识别一个网页里面，事件触发的位置，需要一个页面的唯一标识、和控件的唯一标识；
- 页面的唯一标识
- 一般通过 url 标记，但要处理好url后面的参数；
- 控件的唯一标识
- 一般通过元素在整个文档中的xpath路径来标记。xpath是能唯一标记控件在网页的唯一位置的一种标记方法。
触发的事件
- 事件类型有
- 浏览
- 点击
- 搜索
- 曝光
- 分析
- 进入
- 退出
- 返回
- 悬浮
- 下拉
- 滚动
- 长按
- 右键
- 等等
- 最常用的还是浏览和点击。
触发时间
- 事件触发的时间一般取的是客户端时间，也就是用户的本地时间；
- 如果用户的设备是移动端，取的就是手机时间，如果是电脑，取的就是电脑的时间。
- 但是客户端的时间不太准确，因为用户可以去更改设备时间，我们需要一个机制去校准客户端时间。
- 一般的做法是，在上报事件时，我们会上报事件触发时间 t1 和数据发送时间 t2，服务端也会拿到一个接收数据的时间 t3；
- 如果 t3-t2>60s，则认为客户端时间不准，要对客户端时间进行修正，修正后的客户端时间是：t1+(t3-t2)；
- 之所以 t3-t2>60s 会认为不准，因为数据发送到接收的时间，一般不会超过60s。
事件分类
- 根据所要埋的事件类型进行分类很有必要，一方面方便对需求进行优先级确认，另一方面设计埋点时，不同类型的事件需要对应各自的方法。
核心事件
- 产品的核心流程及用户核心行为的分支事件，根据具体业务需求进行专门处理和参数设置。
通用事件
- 对于通用的、泛化性的、活动等次要流程事件，可以进行抽象化处理。
- 比如：在日常工作中，经常遇到市场或活动运营同事提出某次活动的埋点需求，如果每次活动都单独处理成一个事件，随着时间的推移将会导致同类事件越积越多，不利于管理，因此对于这类相关的事件，需要进行抽象化的通用事件处理。
边缘事件
- 所谓边缘事件，指的是零散的只查看点击或浏览行为的事件，比如 APP 端诸如设置、客服入口等功能按钮。
处理此类事件，有两种常见方法：
- 一种是做一个最基本的自定义事件容器，然后把相关按钮名称、所在页面及其他零散东西抽象化后放进去。
- 另一种是手动纠正一些全埋点进行上报。之所以要手动纠正，是因为前后端的技术架构不同，没有办法 100% 地适应全埋点，当全埋点数据出现未知或无法采集时，需要手动调 SDK，纠正所要采集的页面。
