by 做埋点很长一段时间，越来越觉得埋点不像他们想象的那么简单，只是开发自己的统计业务场景写埋点代码包装传统数据完成工作，从最初的埋点需求规划到最终数据报告只要有一个链接坑会影响数据准确性，数据准确性估计是每个数据人必须面对的问题。让我们简单谈谈我们遇到的坑。这些可能只是表达现象。至于这种现象的本质，我相信不同的人有不同的看法 智者见智。
01、埋点需求混乱，缺乏控制
作为埋点需求的常见提出者，产品和运营在新功能或活动上线时会提出大量的埋点需求。如果数据产品在这个环节对埋点需求没有明确的要求规范和控制，就会导致埋点需求爆炸，这是开发和维护成本的压力。此外，在后续的数据分析中，经常会发现数据不可用或不准确。事实上，后续调查问题的成本非常高，因此，数据产品必须全面控制埋点需求。
1、明确埋点应统计哪些指标：
数据产品在评估埋点需求时，明确埋点需要统计哪些指标是非常重要的。埋点统计服务于指标。如果对埋点需求没有控制和放任需求，经过几个版本的迭代，会发现埋点难以维护，也可以推动操作和产品思考自己关注哪些核心指标，有助于后期的数据统计和复盘。
2、明确埋点提需规范：
埋点需求规范的价值是帮助业务方和数据产品对即将开发的埋点有一致的认知。因此，在设计埋点需求规范时，不仅要让业务方注明需要统计哪些指标、如何规划事件和触发机会，还要写出每个自定义参数的触发机会、参数在哪个层次、是否需要传播等，对于埋点处理的初始阶段，我们可以首先在需求规范的设计和实施中设计和实施能源focus，重点:埋点提需规范越详细越好，可以帮助拉齐各方对埋点的认知。
3、埋点需求评审会议和设置需求接口人
埋点需求评估没有具体进行。一般来说，它是组织业务方、开发、测试和数据产品来评估埋点需求。我想多谈谈需求接口人的角色。当我进入大工厂时，我发现需求接口人非常重要。如果没有接口人，仅仅依靠数据产品与业务对接在大规模、复杂的业务场景中是不现实的。因此，接口人的定位是埋点需求master，甚至数据需求master，重点是：建议接口人可以考虑经常与埋点需求或具有开发背景的业务方对接，以便更方便地沟通。
02、埋点设计缺乏整体思维
规划埋点是数据产品的基本工作，但很难真正做好埋点规划。我认为这个链接的痛点是很难从整体角度规划埋点并具有可扩展性。因此，为了后续的可扩展性，我简要列出了一些可供参考的提示：
1、埋点设计应简洁：
这里的简单性是指类似场景下的埋点是否可以合并为埋点规划，如“点击支付按钮”事件，可以在许多页面触发，然后可以将事件规划为埋点，在不同页面点击页面名称或页面ID作为参数，但这些仍然是初步的埋点设计方案，当许多业务属性以参数的形式传输时，如何管理和规划这些参数，当数据RD看到埋点日志时，很容易理解埋点携带了哪些信息，然后引出我想谈的下一点：
2、埋点设计应标准化：
事实上，标准化这个词非常广泛，我们也在讨论如何根据埋点治理的痛点制定标准。以上是关于我们如何管理埋点日志中的参数，我认为这些参数可以根据性质和层次进行简单的划分：
公共参数：每个购买日志报告参数，包括设备信息、报告时间、IP地址等信息（这里不具体，您可以参考神策略、GrowingIO等第三方数据分析工具），因此公共参数设计管理的数据产品体现在规划公共参数，协调各埋点报告格式，降低仓库分析成本
私有参数：又称自定义参数，在不同的场景、不同的操作、不同的逻辑下触发和传递不同的参数，称为私有参数。
这里的级别是指埋藏日志的json级别。如果可以划分json级别，可以根据自己关注的参数分析不同角色的RD，大大降低了解释成本。
公共信息层：如果您阅读上述公共参数，您将很容易理解什么是公共信息层：顾名思义，它是存储公共参数层。
业务信息层：存储自定义参数，对于类似或场景收集信息可以抽象为对象，存储对象中的信息，如上述“点击支付按钮”事件，可以存储页面信息到对象，位置信息存储到对象，以下是一个巨大的简单栗子：
战略信息层：存储在战略服务参数中的原因是战略多变、灵活，最好在同一水平下进行管理。
通信信息层:也建议单独规划这种后端通信前端参数，方便后续链路跟踪等应用。
当埋点设计形成规范时，实际上也完成了埋点最困难的高抽象部分，下一步是基于良好的抽象规范甚至数据模型，抽象思维可以首先关注关键场景：首先设计核心指标相关的核心点或场景复杂点。
3、埋点设计应具有可扩展性：
埋点设计的可扩展性与上述规范密不可分。当规范建立良好的数据产品时，应考虑是否具有较强的可扩展性，以及如何管理和维护以下规范的新变化。
我们应该知道，埋地点不仅服务于指标统计，而且设计和分析产品性能和使用体验的埋地点，如报告启动时间、崩溃事件、页面加载时间等。
03、埋点开发不规范
这个问题也很有趣。数据产品经常有一个问题：为什么我计划的埋点在实际开发或启动后根本不符合预期。这个链接设计了两个角色：数据产品和埋点开发，那么哪一方在沟通和理解方面存在问题呢？
数据产品：技术背景薄弱，对不同的开发环境和生态缺乏了解
埋点开发：了解开发逻辑，用惯用逻辑实现未明确的细节
你有没有注意到，当埋点场景复杂时，由于两个角色的侧重点不同，gap很容易出现。有人问有没有什么好办法可以避免？其实除了上面提到的，不同的角色只能弥补自己的不足，双方一定要多沟通。埋点开发在评估埋点时，要考虑不同的逻辑和异常场景是否会影响埋点报告，在开发埋点之前尽量暴露问题。
04、埋点验收不够全面
埋点验收环节作为埋点上线的最后保证，也很容易踩坑。具体现象不多说，只说验收过程中如何尽量不踩坑:
(1)验收是否多报
(2)验收是否少报
(3)报告验收是否缺乏参数
(4)验收报告参数是否符合预期
(5)验收报告空日志的比例
(6)验收报告不符合预期日志的比例
除上述验收重点外，验收方法必须手动验证 配合平台自动化，最好进行一次回归测试，多方式验收。
05、埋点生命周期缺乏管理
做埋点处理和数据处理的合作伙伴应该有深刻的经验。当缺乏生命周期的管理盲目允许熵增加时，后续治理的成本确实很高，因此埋点生命周期的管理是必不可少的。简单地说，我们应该做好后续的埋点梳理、埋点减肥和埋点升级，定期统计一段时间内低频报告的埋点以及这些埋点的相关指标和报告的访问量，并在此基础上开展埋点生命周期管理。