埋点|为什么埋点治理这么难？( 二 )

但这些还是比较初阶的埋点设计方案，当很多业务属性以参数形式传递时，如何管理及规划这些参数，让数据RD看到埋点日志时很容易就能理解这条埋点携带了哪些信息，那么就引出来我要讲的下一点。
2. 埋点设计要具有规范性其实规范性这个词很宽泛，我们通篇也都在探讨如何基于埋点治理的痛点制定规范。上面讲到我们如何管理埋点日志里的参数，我觉得可以按照性质和层级给这些参数进行个简单划分：

文章插图
公共参数：每条买点日志都要上报的参数，包含设备信息、上报时间、IP地址等信息（这里不具体讲，大家可以参考第三方数据分析工具如神策、GrowingIO等公共参数的采集）。
那么数据产品对于公共参数的设计和管理体现在要规划号公共参数并协调各个埋点端上报格式一致，降低数仓解析成本。
私有参数：也叫自定义参数，每条买点在不同场景、不同操作、不同逻辑下会触发并传递不同参数，此类参数叫做私有参数。

文章插图
这里的层级指的是埋点日志的json层级，如果能做好json层级的划分，那么对于不同角色的RD可以按照自己关注的参数去解析，大大降低了解释成本。
1）公共信息层：如果读了上面的公共参数，那么会很好理解什么叫公共信息层：顾名思义就是存放公共参数层。
2）业务信息层：里面存放自定义参数，针对同类或同场景的采集信息可以抽象成一个对象，在对象里存放这些信息，例如上面提到的“点击支付按钮”事件，可以把页面信息存放到一个对象里、位置信息存放到一个对象里，下面举个巨简单的栗子：

文章插图
3）策略信息层：里面存放为策略服务的参数，之所以把它单独划分一层是因为策略多变且灵活，最好还是规划在同一层级下管理。
4）透传信息层：这种后端透传前端的参数也建议单独规划，便于后续做链路追踪等应用。
当埋点设计形成了规范，那么其实也完成了埋点最难的高度抽象的部分，接下来就是基于抽象好的规范甚至是数据模型来复用到后续的埋点规划中，抽象的思路可以先关注重点场景：先设计核心指标有关的核心点位或者场景复杂的点位。
3. 埋点设计要具有可扩展性埋点设计的可扩展性与上面的规范性密不可分，当规范建立好数据产品要思考是否具有较强的扩展性，还有后面规范的新增和变更该如何管理和维护。要知道埋点不仅仅只是服务于指标统计，想要全面的规划埋点还要设计分析产品性能、使用体验的埋点，比如上报启动时间、崩溃事件、页面加载时间等事件。
三、埋点开发不规范这个问题也很有意思，数据产品经常有个疑问：为什么我规划好了的埋点，实际开发或上线后根本不符合预期。这个环节共设计到两个角色：数据产品和埋点开发，那么到底是哪一方在沟通理解上出现了问题呢？

数据产品：技术背景较薄弱，针对不同开发环境和生态了解欠缺；
埋点开发：了解开发逻辑，对于未明确的细节用惯用逻辑实现。

大家发现了吗，当埋点场景复杂时，由于两个角色的侧重点不同很容易会出现gap，有人问有什么好的办法去规避吗？
其实除了上面讲的，只能不同角色补齐自己的短板，还有就是两方一定要多沟通，埋点开发在埋点评审时要思考不同实现逻辑和异常场景是否会影响埋点上报，在开发埋点之前尽量把问题暴露出来。
四、埋点验收不够全面埋点验收环节作为埋点上线的最后一道保障，也是很容易踩坑的。具体的现象不多说，只说如何在验收环节尽量不踩坑：