本文为数据茶水间群友原创，经授权在本公众号发表。
关于作者：我是水大人，资深潜水员，一个基于开发、面向分析、走向全栈的饱经摧残的数据新手，爱折腾不爱玩，爱总结爱思考的老兵，错了改改了又错的惯犯。
0x01 前言
前两节我们介绍了埋点设计四大思维，并给出了四种典型场景的埋点设计方式，本节介绍在埋点设计中的注意事项，这些事项是在进行埋点设计的时候应该遵循的准则，通过本节的阅读，你将获得以下准则的认知：
-
同质一致
-
同质继承
-
通用复用
-
粒度平衡
0x02 同质一致
相同指标度量的上报时机和格式一致，比如:
-
实体返回键和app返回键及空白位置的点击clickid统一处理成return
-
页面停留时长信息的上报，其上报时机为离开页面的时候，时长单位ms
-
多同质元素的曝光，用统一的上报格式，如下：
a=x,b=x,c=x;a=y,b=y,c=y #或者
a=x&b=x&c=x,a=y&b=y&c=y
#此种格式十分利于后期处理：
select
str_to_map(pos,',','&') # 转化为字典
from db.tbl
lateral view explode(split(cotentlist,','))ed as pos
where xxx rlike '_list_show$' # 此处多内容曝光事件的事件命名应该规范，和其它形式的内容曝光进行区分曝光和点都采用列表的方式， 在统计该位置的点击率的时候，若点击事件的上报和曝光事件的上报格式一致，可极大的提高效率
同质参数的名称和类型应该保持一致
同质参数的设计一致主要体现在普通参数、维度参数、行为标识上，虽然这些要求是数仓规范上介绍的，但如果能事先治理，在数据采集的时候就规范化，其能减轻的工作量是巨大的。以下是一些通用的词根：普通字段
| 名称 | 意义 | 备注 |
|---|---|---|
| 渠道 | channe | 一般是渠道编号 |
| 版本 | version | 若同时有多个版本，加前缀 |
| 包名 | package | 一般在上报层处理为小写 |
| 来源 | from | |
| 目的 | to | qq/wechat/weibo/friends等 |
行为字段规范
| 行为 | 命名建议 | 备注 |
|---|---|---|
| 点击 | click | |
| 曝光 | show | |
| 分享 | share | |
| 评论 | comment | |
| 点赞 | like | |
| 举报 | report | |
| 安装 | install | |
| 下载 | download | |
| 升级 | upgrade | |
| 退出 | exit |
注意：命名规范的应该遵循相应的逻辑，先要理解现有的埋点规范，然后对其进行沿袭，最好设计之初就严格按规范来执行，可以有效的避免后面统一的时候需要考虑新旧兼容的情况。
同页面同模块的事件名基本一致
同一个页面的点击事件，应该从事件名上可以直接进行区分，如下：1、进入页面即上报该页面的pv，作为分母(下滑等操作曝光的页面上部分的内容再单独上报各自的show事件)2、页面各个部分的点击遵循:页面名_模块部分名_click/show例如：
0x02 同质继承
-
跳转继承
从A页面跳转到B页面，只在B页面的展现事件上报了from，而在B页面的后续重点操作都没有继承最初进入该页的from属性，或者在B页面的下一级需要重点关注来源的页面也漏报了from属性，都是继承中断的情况。
-
初始继承
初始继承是指在用户当天（或者更长日期）首次发生某种行为的时候，该行为即成为用户的一种标签，在后续的其它事件的上报上都上报此标签。比如记录首次启动的方式，桌面图标的启动的，则标注为图标启动用户。虽然后台的数据处理可以计算出用户的这些首次行为标签，但是多个行为的时候可能会存在计算量大的情况。
0x03 通用复用
该准则的要求是尽量少的创建新的事件，而是想法复用原来的事件，这不仅是减少事件数量，方便后续的埋点管理，同时在思考能否复用的过程中，也是对自己埋点设计的能力的一次检验，检验埋点设计的扩展性如何。此处以弹窗的曝光和点击为例介绍
在此框架基础上，任何弹窗类型的交互事件都可以用该框架进行上报，其差异可能只是其中某些参数值的区别。在《埋点设计(上)》中介绍的适合抽象思维进行组织的事件，都适用于通用复用准则。但需要注意的是若参数层级的组合情况较多的时候，建议将参数的曾经用信息表的方式组织。每个参数一列，而没一行是一种参数组合情况。
0x04 粒度平衡
粒度平衡指埋点粒度在最小化的原子粒度和抽象粒度概括之间要平衡，常见的有以下几个方面：
时间粒度
时间粒度在盒子不变，其交互也不变，而盒子里的内容通过左右滑动或者点击跳转而改变，简言之就是复用同一套模板的交互情况下要特别注意。此处以某详情页的停留时长粒度来举例：事件名：离开详情页事件id： x_detail_exit 上报时机：
-
点击返回、切后台等常规形式的退出
-
点击页面交互元素跳转非同类模板页
-
点击相关推荐等进入同类模板页
参数： stay_duration:停留时长，单位ms 在设计埋点的时候，该事件的停留时长参数就一定要精确到原子粒度，即单个内容的停留时长，而不是该类页面的停留时长。基于单个时长可以统计同类时长，若埋点粒度太粗，就没法分解，这样在计算类似TopN条目的情况，埋点数据就无法支撑了。
事件粒度
虽然我们在设计埋点的时候要求采集的信息要完善，不能漏采，但并不是意味事件的上报并不是越多越好，要全但是不要滥，至于上报哪些事件，则要从整个产品交互逻辑和漏斗分析的重点对象出发，在满足版本迭代功能需求统计基础上，不断补齐漏斗环节。
事件的串联此外事件粒度也体现在埋点设计上，可以将一个串的事件用一个时间id，而在params里使用attribute1这个参数来代表不同的阶段，进行了埋点展平，同时这样的拆分设计也可以避免在不同的阶段下，附带的参数不一致，而需要不断的说明层级的关系。
时间粒度的上报数据量度量此外在处理类似心跳事件这样可能造成大量数据上报的情况，要有事前的预估，如果可能超出数据的接收能力，则在客户端进行选择性的上报，但要注意上报样本的均匀合理，能够反映总体的特征。
0x05 总结
本节从同质一致、同质继承、通用复用、粒度平衡四个方面介绍了埋点的注意事项，严格遵循这些准则能很大程度上提高埋点设计的效率，保障埋点设计的质量。