看板天天绿、漏斗却是空的：工具站埋点先过这7道闸 · Day 70

埋点不是「装上统计代码」。是你能不能用同一套事件名，把「谁来了、点了啥、卡在哪、有没有付钱」讲成一条可复算的故事。

昨天 Day 69：合规清单——数据从哪来、存哪、给谁、怎么删。

今天往前半步：你连「用户做了什么」都说不清，合规表也会写成空壳。

很多出海工具站的日常是这样的：

• • 某家统计 / 产品分析后台「看起来在跑」
• • 首页打开次数在涨
• • 一问「免费试用到付费中间掉了哪」——没人答得上来
• • 一问「这个按钮上线后有没有人点」——只能凭感觉

看板绿，不代表漏斗通。 绿只代表采集管道没报错。漏斗通，才代表你的产品叙事在数据里站得住。

同日实体声明

头条是周日踩坑合集（日更流水线闸门），本文只谈出海工具站的产品埋点与事件体系，不写公众号运营后台、不写内容发布脚本。

先说结论（忙的人看这张表）

冰山线：

好的埋点，是一份「产品说明书的数据版」：事件名像按钮文案一样稳定，漏斗像用户路径一样诚实。

证据说明：下文涉及平台能力与命名惯例，优先采用公开文档与多源一致的行业实践；具体数值标 ✅ / ⚠️ / ❌。

一、为什么「装了统计」仍救不了决策

先拆四种常见幻觉。

幻觉 1：有打开量就等于懂用户。

打开量告诉你「页被打开过」。 它不告诉你：工具有没有真正跑完一次、导出有没有成功、付费墙前停在哪。

工具站的价值动作通常不是「浏览」，是完成一次任务（生成、转换、下载、保存、分享）。 你不把「任务完成」定义成事件，看板再漂亮也只是流量温度计。

幻觉 2：事件越多越专业。

行业实践里更常见的建议是：控制事件数量与属性数量，保证团队能读懂字典——例如产品分析侧常见讨论会落到「数十到约两百个事件量级、每事件属性有上限」这类可维护区间（⚠️ 第三方实践总结，非法律标准；以你团队能周复盘为准）。

事件字典没人维护的那天，就是数据死亡日。

幻觉 3：工具默认事件够用了。

自动采集很方便，适合冷启动。 但「注册成功 / 首次生成成功 / 触发付费 / 支付成功 / 退款发起」这类你的业务动词，默认包通常给不全，或名字对不齐你的产品语言。

幻觉 4：名称可以「先随便，以后再改」。

事件名一旦进入历史数据、看板、告警、甚至外部仓库，改名成本极高。 业界反复强调的一条硬规则是：事件名与属性名在代码里应是固定字符串，不要把动态值（用户编号、商品名、错误详情）拼进事件名。（✅ 多源产品分析实践一致；动态信息放属性。）

再补一个冷知识：你以为「以后统一脚本迁移事件名」很轻松，实际上看板、告警、周报截图、同事口癖里的旧名，会跟你纠缠很久。\ 命名便宜的时候不认真，改名的时候最贵。

二、七道闸：从「有数据」到「能决策」

闸门 1：目标先于事件（先写 3 个决策问题）

动笔写 tracking plan 之前，先写三句人话：

1. 1. 本周我要不要加这个功能？看哪个数决定？
2. 2. 付费转化掉在哪一步？
3. 3. 哪个入口带来的用户更会完成核心任务？

写不出这三句，就不要开会「我们再加 20 个点」。

最小集合建议（工具站常见）：

• • 获取：落地页有效访问、来源（在属性里）
• • 激活：完成一次核心工具任务
• • 留存：再次完成任务（可用回访 + 任务事件组合）
• • 收入：开始结账、支付成功、取消/退款（若有）
• • 推荐：分享/复制链接成功（若产品有）

你的站若是纯广告变现，把「收入」换成「达到可计费质量的访问 / 关键页面深度」——但仍然要有「任务完成」，否则广告优化也会漂。

小练习（10 分钟）：

把首页、工具页、定价页各走一遍，用手机备忘录只记动词：打开、开始、成功、失败、导出、升级。 动词列表，就是事件候选池。形容词先丢掉。

闸门 2：一张事件字典，比一百个临时点名重要

字典最少五列：

写字典时强制两问：

• • 这个事件如果少打一次，我会做错什么决策？ 答不上来 → 删
• • 两个工程师听到名字，会不会点到同一个时机？ 会分歧 → 改名或写注释

字典放哪：仓库里一份，在线文档一份也行，但必须有唯一真相源。聊天记录里的「我们口头约定叫 pay_ok」不算数。

闸门 3：命名契约（可读、可聚合、不可飘）

公开材料里较稳定的约定：

• • snake_case（如 form_submit、purchase_completed）在主流分析体系里被广泛推荐（✅ 以各平台公开帮助文档为准）
• • object_action 结构：tool_run_succeeded 比 success1 好懂
• • 固定字符串：plan 是属性，不是 purchase_pro_29 这种事件名分叉
• • 时态一致：要么统一过去式（completed/succeeded），要么统一你团队的一种，禁止混用

反例（常见翻车）：

命名评审可以很粗暴：把事件名念出声。 念着别扭、需要解释三句的，多半不是好名字。

闸门 4：先砌一条核心漏斗，再谈「全站热力」

漏斗分析的产品定义很朴素：多步骤里每一步的到达与流失（✅ 多家分析产品文档对「步骤事件 + 转化窗口」的描述一致）。

工具站最小可用漏斗示例：

1. 1. landing_viewed（或关键落地打开的过滤版）
2. 2. signup_completed（若需登录）
3. 3. tool_run_started
4. 4. tool_run_succeeded
5. 5. checkout_started
6. 6. purchase_completed

规则：

• • 步骤 2–7 个够用；一步太多，没人看
• • 明确转化窗口（例如 1 天 / 7 天内走完才算转化）——窗口不设，复盘会吵
• • 每步必须是同一用户身份能串起来的（登录前后身份合并策略要先定）

没有漏斗的埋点，等于仓库进了货却不摆货架。

实战提示：第一条漏斗宁可「丑但每周看」，不要「完美但没人开」。 丑的漏斗会逼你改产品；完美的方案书只会待在文档夹。

闸门 5：属性白名单，防止「什么都往上挂」

属性是细节，事件是骨架。

建议：

• • 全局公共属性：app_version、locale、env（prod/staging）
• • 业务属性：tool_id、plan、source、error_code
• • 禁止把整段用户输入、整份文件内容、邮箱明文随便塞进属性（这里直接顶上 Day 69 合规：能识别到人的信息要有法务与最小化理由）

属性一多，看板筛选会变成噪音。 宁可 8 个真用的，不要 80 个「以后也许要」。

属性也有生命周期：连续两周没人在复盘里用到的字段，下个月评审时默认进入「待删除候选」。

闸门 6：验收环境——没在调试视图看见，就当没埋上

上线当天才发现事件名为空、触发两次、只在某浏览器打点——都是老剧本。

最低验收清单：

1. 1. 预发环境打开调试/实时视图
2. 2. 亲自走完：落地 → 注册（如有）→ 跑通工具 →（如有）结账沙盒
3. 3. 每个核心事件至少看见 1 次，属性键名与字典一致
4. 4. 刷新/回退是否重复计数——该防抖的防抖
5. 5. 同意管理与第三方脚本：同意前是否仍打了不该打的点（又和合规汇合）

「代码合进主分支了」≠「事件在真实路径上出现了」。

建议把验收清单贴进 PR 模板。没有调试截图，不算完成。

闸门 7：复盘节奏——周看漏斗，月清字典

建议固定两个会（一个人做也行，写在日历上）：

• • 每周 20 分钟：只看核心漏斗 3 个数——到达、逐步转化、本周异常跌点
• • 每月 40 分钟：删僵尸事件、合并同义事件、更新字典版本号

数据信任一旦破过一次（「这数不准」），团队会重新回到拍脑袋。 清字典，是在修信任，不只是修整洁。

周复盘只问三个问题就够：

1. 1. 哪一步掉得最狠？
2. 2. 掉的是新用户还是老用户？
3. 3. 这周产品改动有没有可能解释它？

答完再谈要不要加新事件。顺序反了，字典会胖死。

三、工具站特别容易漏的 6 个点

结合工具站形态，补充清单（按需纳入字典）：

1. 1. 空结果成功：接口返回成功但业务失败——要有 tool_run_failed + error_code
2. 2. 二次运行：同一会话反复点运行——是否算多次激活？先定义
3. 3. 导出/复制：很多工具的「真完成」在复制结果，不在生成结束
4. 4. 额度用尽：quota_exceeded 往往是付费前最强信号
5. 5. 定价页停留与离开：不一定要热力，一次 pricing_viewed 就有用
6. 6. 登录墙前后：匿名身份与登录身份的合并策略写进字典备注

还可以加两条看情况：

1. 7. 分享成功（若增长靠传播）
2. 8. 关键报错弹窗曝光（若体验差在不可见失败）

四、14 天落地节奏（可照抄）

第 1-2 天：决策与字典

• • 写下 3 个决策问题
• • 列出不超过 15 个核心事件（含漏斗步骤）
• • 填事件字典表，评审「触发时机」直到无歧义

第 3-5 天：命名与实现

• • 冻结命名契约（snake_case + object_action）
• • 前端/后端约定：以谁为准打「成功」类事件（优先可信源）
• • 公共属性与用户身份策略定稿

第 6-8 天：漏斗与调试

• • 在分析工具里建好核心漏斗与转化窗口
• • 预发走通验收清单
• • 修重复计数与漏打

第 9-11 天：对照业务

• • 抽若干真实会话路径，看事件序列是否像人话
• • 给「额度用尽 / 失败码」补点
• • 确认付费相关事件与支付回调一致

第 12-14 天：节奏固化

• • 日历写下周漏斗复盘
• • 字典放进仓库或固定文档，改名走变更记录
• • 回顾 Day 69：事件属性里是否混入不该采集的个人数据

两周后你该拥有的不是「更漂亮的看板」，而是：

• • 一张能给新人看懂的字典
• • 一条每周会打开的漏斗
• • 一个「数不准就修字典」的习惯

五、和前后 Day 的衔接

• • Day 69 合规：决定你「能不能采、采多久、怎么删」
• • Day 70 埋点：决定你「采什么才够决策、名字如何不腐烂」
• • 后面若写竞品/增长，没有这两层，复盘只能停留在观感

一句话串起来：

合规管边界，埋点管事实。边界不清会挨罚；事实不清会白干。

也可以记成口诀：

先边界，后事实；先漏斗，后细节；先字典，后报表。

六、一页纸清单

1. 1. 先写 3 个决策问题，再写事件
2. 2. 事件字典五列：名、含义、时机、属性、是否进漏斗
3. 3. 名字：固定字符串 + object_action + 统一风格
4. 4. 动态值进属性，不进事件名
5. 5. 先砌 1 条核心漏斗（2–7 步）+ 转化窗口
6. 6. 预发调试视图走通，再上线
7. 7. 周看漏斗，月清僵尸事件
8. 8. 属性最小化，能识别到人的字段回到合规清单
9. 9. 「成功」以业务真完成定义为准，不是仅接口成功
10. 10. 文档进仓库，改名必留变更记录
11. 11. PR 带调试截图，没看见事件当没做
12. 12. 连续两周不用的属性，进入待删除候选

七、收口

埋点做得好的团队，开会时很少吵「你感觉用户喜欢」。 他们吵的是：「这一步转化掉了，是文案问题还是等待时间问题？」

吵点从感觉换成位置——这就是埋点的复利。

你不需要一开始就上完美数据中台。 你需要的是：一条漏斗、一张字典、一个每周固定打开的复盘。

看板可以继续绿。 但请让漏斗里终于有数。

Day 70 完。

下一篇方向（模块后续）：竞品监测怎么避免「只截图不决策」——仍然服务工具站长期主义，不替代你今天把字典写完。

袁锐钦 · AI产品实操 & 出海工具站日更中。做产品、测工具、跑变现，把试过的路摊开给你看。