运行
上线后先定一个核心指标，再决定埋哪些事件
上线之后该看什么数据：定一个能指导决策的核心指标，拆成 5-10 个事件，用统一命名和属性词表，再验证数据真的到达。
结论
先定义什么算好、什么算坏，再决定埋哪些事件。顺序反过来的话，你会得到一堆没人看的数据，以及几个月后才发现漏埋的关键动作。
一个刚上线的产品，5 到 10 个事件足够支撑决策。事件少的好处是每个都能验证到位，属性命名不会各写各的，半年后回头看还认得出含义。
这篇讲的是指标怎么定、事件怎么设计。GA4 这一个工具的具体配置和验证步骤在 让 GA4 数据能用的配置清单。
第一步：定义什么算好
一个产品只留一个核心指标
先确定产品的价值体现在用户的哪个动作上，那个动作就是核心指标。
几个常见的例子：社交软件是每天发送的消息数，旅行预订软件是预订的房晚数，音乐软件是听歌时长。共同点是这个动作发生了，用户就拿到了他要的东西。
指标定下来还要配一条判断标准：什么情况下需要调整方向，什么情况可以继续。标准不一定准确，但必须存在。一个不能指导任何行动的指标，追踪它没有意义。
把口径收紧到”用户真的拿到了结果”
我的一个付费产品最初把”支付成功”当作核心指标，后来收紧为”完整内容呈现给用户”。原因是出现过支付成功但内容交付失败的情况，用支付口径统计，这些用户在数据里显示为成功。
定口径的时候往用户实际得到东西的那一刻收，比往系统状态流转的那一刻收更可靠。
两类会让人做错决定的指标
只增不减的绝对数。注册总数、下载总量、粉丝数，这类数字每天都在变大，看着舒服，指导不了任何决定。能指导决定的是可比较的比率：留存率、转化率、活跃占比。
互相拉扯的指标。让点击率上升有很多种办法，强制弹窗和强制跳转都能做到，代价是使用体验和留存。只盯一个指标，很容易在别处付出看不见的成本。定核心指标的同时记下一到两个约束指标，用来发现这种情况。
第二步：把指标拆成事件
四类事件
- 页面浏览：分析工具自动采集，不用手动写。
- 用户主动操作：按钮点击、表单提交、筛选、搜索。
- 系统状态变化：注册完成、购买完成、订阅变更、退款。
- 自己定义的成功动作：漏斗终点，通常就是核心指标对应的那个动作。
落地页和产品内部关注的事件不同
落地页关注转化：cta_clicked、form_submitted、signup_completed。产品内部关注使用行为：onboarding_step_completed、feature_used、purchase_completed、subscription_cancelled。
我这两个产品的实际事件清单可以直接参考：
| 产品 | 形态 | 核心事件 |
|---|---|---|
| TrakToken | 工具站 | model_compared（比了哪几个模型）、pricing_table_filtered（用了哪个筛选条件）、outbound_click（点去哪个厂商站点） |
| PageGrok | 浏览器插件 | extension_installed、feature_used（feature_name 区分摘要／翻译等）、extension_uninstalled（能采集到时带 reason） |
两份清单都在 10 个以内，每个事件都能对应一个具体的判断。
第三步：命名和属性
事件名固定格式
用 object_action，全小写下划线：signup_completed、button_clicked、checkout_payment_completed。
同一类动作用一个事件名加属性区分场景。页面上有三个位置的按钮都通向注册，埋一个 cta_clicked 带 location 属性，比埋 hero_cta_clicked、footer_cta_clicked、nav_cta_clicked 三个事件好用得多。合并之后想看总量直接看，想看分位置加一个筛选条件，拆开则要每次手动相加。
属性也要有统一词表
属性大致分四类：页面类（page_title、page_location）、用户类（user_id、plan_type）、来源类（UTM 那五个参数）、业务类（product_id、price）。
同一个概念全站只用一个属性名。新增属性先查词表，词表里有的直接用，没有的先补词表再写代码。枚举类属性写死取值范围，出现范围外的值上报 unknown，并当作埋点缺陷处理。
字段缺值的时候上报一个固定值（比如 not_set），别让它变成空。我在 QuantFull 的做法就是这样，缺值不会把一条漏斗拆成两套统计口径。
把约定写进一份文档
事件名、触发时机、属性、取值范围写在一份独立的 Markdown 文档里。写代码的时候照这份文档埋，做分析的时候照这份文档查，两边用同一套定义。
我在 TrakToken 上把这份文档写到 600 行，包含核心指标定义、工具分工、17 个事件的完整规格、属性词表和验证方法。前期看着重，好处是后面不会再出现”这个事件到底算什么”的争论，AI 写埋点代码时也有一份可以照着的依据。
第四步：验证数据真的到了
代码调用了埋点函数，不代表数据进了分析系统。这是最容易被跳过的一步，也是数据误差最常见的来源。
客户端采集会少多少
广告拦截规则会影响 25% 到 40% 的客户端流量（分析厂商估计值，未经独立审计）。我自己产品的实测是：Vercel Analytics 记录的访问用户比 GA4 多 30% 到 40%，差异来自地理位置拦截和浏览器插件拦截。
浏览器插件类产品受影响更明显。PageGrok 早期同时遇到 GA4 请求被广告过滤规则拦截、缺少安装事件、匿名 ID 不稳定三个问题，处理办法是自建上报中转、补上安装数作为分母、稳定匿名 ID、密钥放到服务端保管。
客户端和服务端各埋一遍
推荐做法是客户端自动采集做基线，服务端手动埋点覆盖 10 到 20 个核心指标。注册、支付这类关键动作两边各埋一次，用不同的事件名区分，避免重复计数。
上线前逐个触发一遍
新事件发布前，在浏览器里逐个触发，在分析平台的实时视图里确认事件出现，再逐个字段核对属性名和取值，重点看枚举类属性有没有出现范围外的值。
第五步：口径对齐
同一件事，三个系统三个数
我的一个付费产品里，Stripe 的支付成功事件、后端的订单状态、前端的内容解锁页面都记录”支付成功”。三者的含义各不相同：Stripe 记的是扣款完成，后端记的是订单状态流转，前端记的是用户实际看到了内容。三者之间有时间差和状态不一致，同一天的数字在三个地方对不上。
处理办法是指定一个唯一口径，这里选的是”用户实际看到内容”，另外两个降级为过程监控。
多个工具的数字对不上是正常的
给每个指标指定它归属的那一层，跨层的数字不做加减。我在 TrakToken 上的分工是：
| 问题 | 以哪个工具为准 |
|---|---|
| 站点有多少流量 | Vercel Analytics |
| 流量从哪来、新老用户占比 | GA4 |
| 用户做了什么、漏斗转化 | PostHog |
PostHog 的服务器在海外，面向中国大陆用户的产品采集会有延迟，后台交互步骤也偏多，配置一套漏斗要点开的层级比较深。选它之前先按这两条约束判断是否合适。
差值本身也值得监控。Vercel 通常比 GA4 高 30% 到 40%，这个比例突然变化说明采集链路出了问题。
自动化流量
站点流量里有一部分来自爬虫和自动化访问，AI 相关的抓取近年明显增多。看到流量上涨时先确认涨的是不是真实会话，有条件的话在分析时做一层爬虫过滤。
第六步：让数据回到改动决策
我的做法是用价格曝光、支付意图、取消支付、内容解锁这几个事件的数据评估定价方案和挽留策略，改完再看下一轮数据。
早期产品数据量小，A/B 测试通常跑不出统计意义。这时候数据的作用是缩小判断范围，最后一步的决定还是靠人做。指望数据替你做决定，在这个阶段不现实。
别漏掉搜索这一层
产品内的事件之外，还要看流量从哪来。我的产品有大量流量来自 Bing，超过 Google 和百度，因为 Bing 的索引同时是 Microsoft Copilot 的数据源，也是部分 AI 搜索产品的检索来源之一。它在 2026 年 2 月上线了 AI Performance 面板，能看到哪些页面被 AI 回答引用。
搜索这一层的数据在 Search Console 和 Bing Webmaster Tools 里，和产品事件不在同一个系统。诊断顺序见 上线后没人来：先确认搜索引擎读得到你的页面。
延伸阅读
最后验证日期：2026-08-30。文中 TrakToken、PageGrok、QuantFull 的事件清单和数据差异为我自己产品的实际记录，采集时间为 2026-07 至 2026-08。广告拦截比例引自分析厂商估计，未经独立审计。各分析工具的免费额度和功能可能变化，使用前请核对官方文档。