AI 事件收件箱发布：全埋点开始自己提议事件名

每个埋点方案都始于良好的愿望，停在同一个地方：得有人给事件起名，跟三个团队谈拢，再找工程师加上。与此同时网站在变。全埋点解决了工程那一半：不写代码就记录每一次点击和表单提交。今天发布的 AI 事件收件箱解决起名那一半：它读全埋点的数据流，提议事件名，合并重复项，放进一个几分钟就能批完的列表。

起名是埋点方案停下来的地方

问任何一个埋点方案做了一半的团队停在哪儿，答案都是那张表：四十行提议的事件，一半有三种叫法，等着开会。全埋点靠自动记录交互去掉了对工程的依赖，却制造了新问题。数据在那儿，名字却是 click: button.btn-primary "免费开始" 这样的，没人想在一个 CSS 选择器上搭漏斗。

收件箱的存在，就是把这股数据流变成一套词汇。它先打草稿，会议就变成批准名字，而不是发明名字。

收件箱做什么

每天，收件箱看一遍前一天全埋点记录的交互，问三个问题。哪些交互看起来是同一个动作，哪怕选择器或页面不同（五个页面上的「免费开始」按钮是一个事件）？根据按钮文字、页面、表单名和跳转地址，人会怎么叫它？它有多重要，按量和它出现在转化之前的频率来衡量？结果是一张排好序的提议列表，每条带建议的名字、出现的页面、昨天的次数和依据。

批准、改名、忽略

每条提议有三个按钮。批准会创建一个带分组规则的命名事件，之后匹配规则的交互立刻计入这个名字，历史全埋点数据也会回填。改名让你在批准前改好名字，收件箱会从改名里学你的习惯（蛇形命名、动词开头，随你用什么）。忽略会藏起这条提议和所有长得像它的；一个你永远不想跟踪的装饰性链接从此消失。

批准是有意保留的人工步骤。收件箱不会自己创建事件，因为事件词汇是一门共用的语言，每个团队成员都应该能相信一个命名事件就是它字面的意思。实际上一个工作区第一周会批准十到二十个事件，之后随着网站变化每月批几个，是几分钟的复核，不是一场规划会。

批准的事件就是普通事件：和代码发来的事件一样出现在漏斗、分群、告警和接口里。定义存成一条你读得懂的规则，不是一个你得信任的模型：

{
  "name": "start_free_clicked",
  "match": {
    "type": "click",
    "element": "a, button",
    "label": ["免费开始", "Start free"],
    "href_contains": "/register"
  },
  "pages": "any",
  "approved_by": "[email protected]",
  "backfill_from": "2026-07-01"
}

收件箱永远看不到的东西

全埋点记录的是交互，不是内容。它存元素类型、可见文字、页面和目标地址，从不存输入框里打的值、从不存密码、从不存标记为敏感的字段里的任何东西。收件箱基于同样的数据，所以提议是从「免费开始」「订阅」这样的标签建出来的，不是从访客写了什么。表单提交只记录提交了哪个表单，不记录字段。如果你需要一个值（订单金额、套餐名），用代码里的 track() 显式发送，那里由你完全控制什么离开页面。数据平台页精确列出了全埋点采集什么，安全页讲了保留期。

上线安排与下一步

收件箱将在接下来两周内向所有开启了全埋点的工作区推送；不需要配置，没有你的批准什么都不会生效。它在数据分析里是事件旁边的一个新标签页。接下来的计划：从经常按顺序出现的已批准事件里提议漏斗；一个已批准事件在网站发布后量掉到零时发出提醒，那通常意味着一个按钮坏了。两项都请关注更新日志，四步流程见全埋点概览。

如果你已经有一张埋点方案的表格，留着它：收件箱里和表格匹配的提议，用你已有的名字批准；其余的当作一份你的方案没想到的交互清单。大多数团队发现后一半更有意思。