4月14日晚，DTalk邀请到了谯洪敏老师，他是滴滴上海前端团队负责人，前陆金所移动前端团队负责人，进行了一次关于《前端数据采集与分析的那些事第二弹：前端篇》的微信群线上主题分享。
活动分享了埋点需求的整理原则，埋点的命名规范，埋点流程规范，埋点上报的解决方案，以及一些实际场景中的注意事项。谯洪敏老师会在4月21日的 DTalk上海数据驱动实战案例研讨Workshop中深入帮助参会团队解决数据埋点方面的问题。
一、埋点需求整理原则
其实就是整理一系列问题，并基于这些问题确定埋点需求，我作为FE的RD，针对这些原则，我们至今也没有真正全面的做到，但是如果遵循这些原则，将会受益良多（也欢迎大家补充问题内容）：
HOW LONG：
-
埋点可用周期是多久，持续几个版本可以？
-
生命周期结束后是否可以考虑下掉？
HOW MUCH：
-
现有的埋点哪些可以满足我的部分埋点需求？
-
哪些现有的埋点可以替代我要的部分埋点？
-
新的埋点有多少？这些埋点是否是最必要的？
HOW：
-
怎样证明新功能效果？
-
需要哪些埋点？
-
我该怎么埋这些点？
-
部分埋点的计算逻辑是什么？
-
数据结果怎么看？漏斗？同环比？
WHO：
-
我的产品设计面对的用户群里是谁？
-
用户特征是什么？
-
这部分特征用户对功能预期的数据结果是什么？
-
用户习惯是什么？
WHAT：
-
我的新产品是什么？
-
新产品包含哪几个模块？
WHY：
- 涉及新产品的目的是什么，为了解决什么问题？
WHERE：
-
新功能展示在产品端的哪个位置？
-
在哪些版本生效？
-
哪些功能的展示或作用在哪里需要跟服务端等交互？
WHEN：
-
功能是在用户场景什么时候调用产生？
-
调用过程中什么时候和服务端交互？
-
功能调用正常情况下需要大概需要多长时间？
-
什么情况会影响调用结果？
-
调用有风险的时候，是否需要加监测？
二、埋点命名规范
我们当前的做法是埋点名称只能是由字母、数字、下划线组成，并保证在应用内唯一，sw是展示，ck是点击。
常用规则的举例如下：
-
比如行为埋点： {团队|业务|角色}{组件|页面}{具体元素}_{动作} 示例：yourteam_fc_all_msg_ck
-
autoplatform_flowtab_sw ： autoplatform代表业务线，flowtab 代表功能，sw代表页面操作，sw是展示，ck是点击
-
uber_comt_share_ck ：uber业务线，comt评价组件，share分享按钮，ck点击
三、埋点流程规范
埋点作为重要的资产，是数据生产的第一步，那为什么制定规范占首要位置？
因为30%用户反馈找不到埋点，根本无法进行数据分析，造成这个问题的原因包括：
-
埋点语义不明确，同一个按钮存在多种描述，不易检索；
-
无用/重复埋点太多，干扰了正常埋点数据，一个公司可能已经包括上千个埋点信息，而且还在按照很高的速度迭代增长；
-
大量存量埋点Owner离职或者转岗，导致大量僵尸埋点信息，找不到归属方和解释方；
如果你发现每天有大量埋点错误反馈，并导致很多错误的分析结论，一个错误的分析结果还不如没有数据分析结果。造成这个问题的原因包括：
-
前端埋点涉及复杂的交互，难以找准埋点位置；
-
埋点的验收流程不完善，没有经过测试和产品经理的测试和验收，验证不完备；
好的埋点需求应该和业务功能需求同等重要，也需要经历软件开发的整个生命周期，如果能严格按照一个规范的流程处理埋点，以上问题会得到更好的解决：
规范内容：
1、需求阶段：
确定埋点信息，核心包括五方面信息：事件ID、埋点名称、埋点描述、埋点属性以及截图。
举例：
-
快车页面打车的埋点信息为：
-
埋点ID为：gulf_p_f_home_order_ck
-
埋点名称为：呼叫快车
-
埋点描述：在快车首页点击呼叫快车按钮。
如何落地：
如果不按照规则和流程埋点将不会上报相关数据，制定强制规定。
开发什么功能：
埋点全文检索能力、自动找到重复埋点（语义相近或者数据相近）功能。
2、开发阶段：
务必和开发沟通，并让开发在完全理解业务语义的情况下，在前端按照埋点代码规范进行埋点。
举例：
比如针对商品购买按钮，在前端点击方法的第一行调用SDK，最好也传入文本字面描述。
如何落地：
静态代码检查。
开发什么功能：
开发探测每个埋点对应到的代码文件和代码行，开发根据人均事件量级进行监控报警功能。
3、测试阶段：
务必和测试沟通，并让测试在完全理解业务语义的情况下，通过CodeReview和埋点测试两种方式对埋点正确性进行验证。
举例：
比如针对商品购买按钮埋点，需要检查埋点测试中上传数据中事件ID、属性是否符合定义，另外触发时机是否正确。
如何落地：
规定如果未经测试的埋点不允许上报埋点数据。
开发什么功能：
提供所见即所得的埋点测试平台。
4、验收阶段：
确保相关人员在完全理解业务语义的情况下，可以通过与自比较和他比较的方式来进行验证。
举例：
自比较验证：同一APP某一个业务线的购买冒泡数量一定要小于所有业务线的冒泡数合计；
他比较验证：前端某业务点数量和对应服务端数据应该基本相当。
如何落地：
规定如果未经验证的埋点不允许上报埋点数据。
开发什么功能：
提供埋点实时数据查询。
5、清理阶段：
确认完全理解语义的情况下，可对业务发生巨大变化或者不在维护的埋点进行废弃。
举例：
百度糯米合并饿了么后，埋点在经历产品大改版后已经和其他业务线合并，需要废弃之前的遗留埋点。
如何落地：
3个月以上未被使用的埋点、1个月以上数据为0的埋点自动废弃。3个月后使用次日会自动开启采集。
开发什么功能：
根据规则提供针对未使用埋点的计算、并自动废弃。
可以做一个表用来记录:
四、关于埋点上报的解决方案
一般会实现上个模块，Event收集器，Event缓存器，和Event上报器。
1、Event上报模式
除了用户个人不希望耗费流量以外，也可能会因为弱网及断网情况，如果确保数据不丢失，基于这些问题而诞生的上传策略，来设计如何上报已收集的所有事件数据。上报一般包括针对内存实时数据的上报和本地持久化数据上报两个部分，分别介绍一下它们的上报策略与实现方式。
2、内存埋点数据的实时上报
针对内存埋点数据的上报策略一般如下：
-
基于时间间隔：每隔 n秒（时间间隔可以根据公司的业务情况自定义）
-
基于数据条数：每累积 n条数据（条数可以自定义）
-
不间断实时上报，如果是低频率，数据量小，实时性要求高的数据可以不设限制
上述条件满足时，便会触发从内存中读取数据，并执行上传操作。Native可以创建了一个并发队列，H5会基于浏览器并发发送。
3、本地持久化数据的延迟上报
为了尽早的上传本地持久化埋点数据，以防用户卸载 App或者关闭浏览器造成本地数据的丢失，针对本地持久化数据的上传策略如下：
Native相关：
（1）App 冷启动
（2）App 进入前台
（3）App入后台
HTML5、Hybrid相关：
（1）localstorage，浏览器关闭埋点数据并不会被删除，如果用户再次访问，会启动上报
（2）基于Native提供的bridge，让Native帮忙持久化数据，并在再次进入时，启动上报
这里也可以创建一个单独的串行队列，来实现对本地持久化数据的逐个上报。
另外我们在前端埋点中也遇到过一些注意事项，整理如下，希望对大家有所帮助。
注意事项
1、一些埋点安全性问题：
如果你使用普通的http 协议，在数据传输的过程存在被劫持(包括不限于：JS代码注入等)的可能性，造成H5页面中出现诸如：未知的广告或者原网页被重定向等问题。为了降低此类事件发生的可能性，建议最好使用https 协议（倡导全站https），以确保数据传输过程的完整性，安全性。
2、版本迭代的时候埋点需要注意什么？
-
如果是公用模块，可以非常放心安全的全量迁移埋点；
-
如果是新增模块，那就需要注意是否遵循了最新的埋点规范，有没有重复的埋点命名存在，埋点是否符合业务逻辑；
-
如果是下线模块，那就需要评估下线后对数据的影响范围，而且要第一时间充分周知相关方，让各方参与评估；
-
如果是更新模块，需要评估在原有埋点上需要修改的埋点内容，是否需要重新埋点，删除不需要的埋点，而且要修改功能的数据承接。
本文作者：
谯洪敏老师，DTalk核心专家组成员，滴滴上海海浪前端团队负责人，前陆金所移动前端团队负责人，主要专注与前端工程化、前端Web安全及前端性能优化，有丰富的前端埋点技术工程、数据处理和数据质量的经验。
干货专访和文章
【DTalk精华】网易郑栋：前端数据采集与分析的那些事第一弹: 从数据埋点到AB测试
【DTalk精华】滴滴出行谯洪敏：前端数据采集与分析的那些事第二弹：企业如何选择自动埋点和可视化埋点
【DTalk精华】滴滴出行谯洪敏：前端数据采集与分析的那些事第三弹：埋点需求整理原则于埋点流程规范
【DTalk专访】彭圣才：AI超越人类大脑，是一场「別有用心者」的骗局吗？
【DTalk专访】翁嘉颀：AI行业现阶段最需要什么样的人才？
【DTalk专访】赵华：携程怎么把机器学习与实际业务相结合？
【DTalk专访】网易郑栋：BI、可视化数据产品和大数据的几个核心问题
网友评论