背景：H5 项目，原本都是人工埋点，即按需在部分元素的点击事件加入触发上报的代码，此过程较为繁琐容易遗漏，且如果临时需要看某一元素的点击事件，发现没有还得临时加。
目的：实现自动埋点上报，尽可能减少人工埋点，例如按钮、对话框、链接等元素点击时自动上报，供后台进行漏斗分析、事件组合分析。
监听所有点击事件并上报这个本身并不难，主要让我困扰的是以下这一点
我们针对的并不是监控用户行为回溯操作路径这类对数据唯一性要求不高的场景，而是数据分析，所以统计数据需要干净可靠，当所有元素都加了点击事件，那么如何对每个元素进行唯一标识供后台筛选组合？光靠按钮名称、元素路径这种肯定是不行的，因为很容易变化。目前能想到的就是在元素上加额外的 data-track-id 属性，那么又无法 100%解决人工埋点的痛点（虽然上报操作是可以自动了）。
或者说在这种场景下，是否有必要全埋点，有没有更好的方案？
目的：实现自动埋点上报，尽可能减少人工埋点，例如按钮、对话框、链接等元素点击时自动上报，供后台进行漏斗分析、事件组合分析。
监听所有点击事件并上报这个本身并不难，主要让我困扰的是以下这一点
我们针对的并不是监控用户行为回溯操作路径这类对数据唯一性要求不高的场景，而是数据分析，所以统计数据需要干净可靠，当所有元素都加了点击事件，那么如何对每个元素进行唯一标识供后台筛选组合？光靠按钮名称、元素路径这种肯定是不行的，因为很容易变化。目前能想到的就是在元素上加额外的 data-track-id 属性，那么又无法 100%解决人工埋点的痛点（虽然上报操作是可以自动了）。
或者说在这种场景下，是否有必要全埋点，有没有更好的方案？
13 条回复 • 2025-06-10 06:48:02 +08:00
 |
1
sirthisman 7 天前
参考下神策的全埋点方案试试？
|
 |
2
shunia 7 天前
这种问题不是应该在报告端解决吗？如果路径变了，上线后就要更新报告了，把新老两条路径合到一个口径的数据里。
既然都要求这么高了，数据报告平台应该有这个能力吧？ track-id 之类的方案，如何应对动态创建的元素？出了 bug 咋整？ 另外数据统计大部分情况下是统计趋势，绝对数字影响相对很小，综合考虑你们的实际需求看看吧。 |
 |
3
Leoon 7 天前
GTM ？各种基本事件都会留痕了，硬找也能找着
|
 |
4
Torpedo 7 天前
我总觉得全自动埋点花费的经理，不如直接手动埋了
|
 |
5
tcper 7 天前
记得以前公司几乎每个需求都有埋点的要求，然后最多两三周有人关注，之后几乎没人关注
埋点，除了核心流程，关键步骤，比如付费，跳出之类的真正有意义，加那么多埋点纯属没事找事 在代码里还能看到两三年前的埋点，相关需求的产品经理都离职不知道几轮了，路径变化，业务逻辑变化，那数据早乱了，有谁关心？甚至根本没人知道。 搞这个东西别真上头，三个月前的埋点数据你看看有谁关心。 |
 |
6
Charbo OP  1
@tcper 太真实了，跟我们这一模一样，然而就是人工埋点太乱，导致想看的数据没有埋点，临时加又得等几天才能看数据，没用的埋点代码又越堆越多。老板就想着搞成自动的，只能说的确能解决一部分问题吧
|
 |
7
shadowyue 7 天前
神策吧，交给专业的
|
 |
8
duanxianze 7 天前
楼上说的太真实了，所谓埋点除了刚做好那几天以后根本无人关注
|
 |
9
cytsui 7 天前
推荐 GTM
|
 |
10
yutong16 7 天前
还是推荐 GTM ，把上报配置结构固定好， 自定义事件结构固定好。产品想要什么埋点，自己去加，解放研发资源。
|
 |
11
h1298841903 7 天前
如果是简单的标识唯一元素，那就不建议使用 data-track-id 属性，可以维护一个平台，维护元素路径和元素的关系。可以等到用的时候，再进行映射规则编写。当然，也可以结合 data-track-id 属性，对于重要的元素，也可以根据 data-track-id 来锁定其他元素路径。
我现在遇到的问题，其实是如何携带额外的参数，比如点击页面的任务 ID 、工单类型等非标准化的值，每个埋点要上报的数据还都不太一致，和业务相关。 |
 |
13
riceball 6 天前
从系统上约定好 id 命名规范，比如: 'btn_RootCategory_SubCategory_MeaningfulName' 这样后期分析就好做些,这个是公司层面的问题。底层开发者无法解决.
|
Select Language