工具产品看数据

这篇写给已经过了 PMF、准备放大的产品。刚起步、还在验证有没有人要的，先读 PMF 验证与第一批用户。

SEO 的监测 看到的是「人来了没」：抓取、收录、展示、点击、到站。这篇接着往下看：来了以后用上没、回来没、付钱没、这钱赚得划不划算。怎么做运营见 工具产品出海运营，这篇只讲数据。

GSC / Cloudflare        GA4                    PostHog（产品分析）         支付平台
────────────────       ────────────           ─────────────────────      ────────────────
搜索里有没有你    →    从哪来、落在哪页  →    用上没、回来没、卡在哪  →   付钱没、留下没、赚多少

后面先画指标树，再讲工具和埋点，然后按漏斗一段一段讲公式，最后是出了问题怎么查、实验怎么判断、每周看什么和周报模板。

一、先画指标树

数据看不明白，大多是因为没有先想清楚要看什么。先定一个北极星指标，再把它拆开。

1. 北极星指标

北极星指标要满足三个条件：用户拿到了价值、和收入正相关、团队每周能推动它。工具产品一般选：

每周完成核心动作的用户数（Weekly Active Value Users）

「核心动作」就是 Aha 时刻那个事件：图片处理成功、格式化成功、生成内容被导出。不要选注册数（注册了不用没有意义），也不要选页面访问量（大部分是一次性访客）。

使用周期是一个月的工具，把「每周」换成「每月」。

2. 拆开

每周价值用户
= 新激活用户                             ← 获客 × 激活
+ 老用户里本周回来的                       ← 留存
+ 回流用户（流失后又回来的）                ← 召回

收入（MRR）
= 付费用户数 × ARPU
= 激活用户 × 付费转化率 × ARPU − 流失

展开成一棵树：

                           MRR
            ┌───────────────┼────────────────┐
         新增 MRR        扩张 MRR         流失 MRR
            │          （升级、加量）    （取消、降级）
     新付费用户 × ARPU
            │
   激活用户 × 付费转化率
            │
   注册 / 使用用户 × 激活率
            │
       访客 × 注册率
            │
  ┌─────────┼──────────┬──────────┬──────────┐
自然搜索   AI 推荐    引荐 / 目录    社区      直接
（GSC）

**每个数掉了，都要能在树上找到是哪一枝掉的。**做不到，说明埋点缺了。

二、工具：各管一段，一个 ID 串起来

小团队不用全上。起步用 GSC + GA4 + PostHog + 支付平台后台就够了。

最重要的一件事：用同一个 user_id 把它们串起来。

匿名访客：PostHog 的 distinct_id（匿名 ID）
   │ 注册 / 登录时
   ▼
posthog.identify(user_id)          ← 匿名阶段的行为自动并到这个用户上
gtag('set', {user_id: user_id})     ← GA4 也设置
   │ 付费时
   ▼
支付平台的 customer 带上 metadata.user_id
Webhook 回来时，用 user_id 发服务端事件 subscription_started

串起来之后，才能回答「从 Reddit 来的用户，付费率是多少」这类问题。

三、埋点

1. 命名规则

事件名：对象_动作，小写，下划线，过去时
        tool_used、file_uploaded、export_completed、subscription_started
属性名：小写，下划线
        tool_name、file_type、plan、source

规则定下来就不改。事件名改一次，历史数据就断一次。

2. 最小事件表

工具产品有这十几个事件就能把漏斗画完整：

和钱有关的事件一律从服务端发。前端事件会被广告拦截插件挡掉，开发者工具的用户里，装拦截插件的比例很高，丢掉三成以上并不奇怪。

GA4 那边只需要把 tool_succeeded、signup_completed、subscription_started 标成关键事件，用来比较渠道。细的行为分析都在 PostHog 里做。

3. 用户属性

注册时写进用户属性，以后所有报表都能按它切：

first_utm_source / first_utm_medium / first_utm_campaign   首次触达的渠道
first_landing_page                                          首次落地页
first_referrer                                              首次来源域名
signup_country                                              国家
signup_tool                                                 注册前用的是哪个工具
plan                                                        当前套餐

首次触达的 UTM 要在用户第一次访问时存进 cookie 或 localStorage，注册时再读出来写进去。GA4 的会话来源只记得本次会话，用户第一次从 Reddit 来、三天后直接输网址来注册，GA4 会把这个注册算给「直接」。

4. 问一句「你从哪知道我们的」

注册后问一个可选的单选题：

你是从哪里知道我们的？
○ Google 搜索   ○ ChatGPT / Claude / Perplexity 等 AI   ○ Reddit
○ X / Twitter   ○ YouTube   ○ Product Hunt   ○ 朋友推荐   ○ 其他：____

这个数据叫自报归因。AI 的手机 App、微信和 Slack 里转发的链接、朋友口头推荐，这些都不带来源，在 GA4 里全算成「直接」。自报归因是唯一能看到它们的办法。它和 GA4 的归因经常差很多，两个都看。

5. UTM 规范

所有你能控制的链接都带 UTM。定一套规则，全团队只用这一套：

utm_medium 必须用固定列表，大小写要统一。GA4 按 medium 归类默认渠道组，写成 Social 和 social 会被当成两个，写个 sns 就直接落进「未分配」。

站内链接永远不要带 UTM，会把本来的来源覆盖掉。

四、获客：哪个渠道值得继续做

SEO 那段看 SEO 的监测。这里是所有渠道放在一起比较。

1. 渠道质量表

每月填一次，所有渠道放在一张表里：

按 first_utm_source / first_referrer 分组，数据来自 PostHog 或者数据库。

判断一个渠道，看的是付费数和投入，不是访客数。Product Hunt 当天带来 5000 个访客，付费 3 个；一个小众论坛每月 200 个访客，付费 5 个。后者更值得长期做。

2. 公式

使用率     = 触发 tool_used 的访客 ÷ 落地访客
访客付费率  = 付费用户 ÷ 新访客                     按渠道算，看 30 天内
渠道 ROI   = 渠道 30 天新增 MRR × 12 ÷ 渠道投入     粗算，投入的时间按时薪折成钱

3. 落地页

每个工具页就是一个落地页。按落地页看：

使用率低：第一屏没看到工具，或者看不懂怎么用。 成功率低：工具本身有问题，去看 tool_failed 的 error_code。 使用率高、注册率低：付费墙或者注册的触发点不对，或者免费版已经够用了。

五、激活：用上没

1. 公式

激活率          = 到达 Aha（tool_succeeded）的新用户 ÷ 新用户           按天或按周的新用户群算
到达时间 TTV    = 第一次 tool_succeeded 的时间 − 第一次访问的时间       看中位数，不看平均
工具成功率      = tool_succeeded ÷ tool_used

「新用户」按产品的形态定：先用后注册的工具，分母用新访客；必须注册才能用的，分母用新注册。定了就别改。

TTV 看中位数：少数用户隔了几天才回来用，平均值会被拉得很大。

2. 漏斗

在 PostHog 里建一个漏斗，时间窗口设 1 天：

page_viewed（工具页）
  → tool_opened
  → tool_used
  → tool_succeeded
  → export_completed
  → signup_completed

看每一步的流失，找流失最大的那一步。按 tool_name、国家、设备、来源拆开看，常常是某一个工具、某一类设备特别差。

移动端要单独看。很多工具在手机上根本没法用（比如要上传大文件、要拖拽），手机用户的激活率低很正常，这时候就别让手机用户进入付费漏斗来拉低数字，改成「发到邮箱，回电脑上用」。

3. 看会话录屏

漏斗告诉你在哪一步掉，没告诉你为什么。在流失最大的那一步，找 10–20 个会话录屏看一遍，比猜一周都有用。PostHog 自带录屏，也可以用 Microsoft Clarity（免费）。录屏前要遮住输入框，隐私政策里写上。

六、留存：回来没

1. 队列表

留存要按**队列（cohort）**看：同一周第一次激活的用户算一组，看这组人之后每周还有多少比例回来完成核心动作。

                  W0      W1      W2      W3      W4      W8
2026-08-03 组    100%     28%     21%     18%     17%     15%
2026-08-10 组    100%     31%     24%     20%     19%
2026-08-17 组    100%     35%     27%     23%
2026-08-24 组    100%     33%     26%
2026-08-31 组    100%     36%

两个方向都要看：

• 横着看：一组人的留存曲线最后有没有走平。走平了，说明有一批人真的离不开你，这就是产品和市场匹配的信号。一路降到 0，说明还没有人非用不可。
• 竖着看：同一列（比如 W1）从上往下，有没有在变好。变好说明最近的改动有用。

2. 公式

第 N 周留存（固定周期）   = 第 N 周完成过核心动作的人 ÷ 这组的总人数
第 N 周留存（累计）       = 第 N 周及以后任何时候回来过的人 ÷ 这组的总人数

高频工具用固定周期，低频工具用累计。月结类的工具看固定周期的周留存会很难看，但累计留存可能很健康。

回来的定义用核心动作，不用「打开过页面」。打开页面可能只是误点，完成核心动作才算真回来。

3. 使用频率

除了留存率，还要看回来的人用得多不多：

DAU / MAU          每月活跃的用户里，平均每天有多少比例在用。日常工具 20% 以上算高，周用工具 10% 左右正常
L28 分布            过去 28 天里，每个用户有几天用过。画成直方图，看右边有没有一批重度用户

L28 直方图如果在右端翘起来（有人 20 天以上都在用），这批人最有可能付费，访谈就找他们。

七、付费：钱从哪来，从哪漏

1. 转化

免费→付费转化率    = 队列中 N 天内付费的人 ÷ 队列激活用户数          按注册周算，N 取 30 或 60
试用转化率        = 试用结束后付费的人 ÷ 开始试用的人
付费墙转化率      = checkout_started ÷ paywall_viewed，按 trigger 拆
支付完成率        = subscription_started ÷ checkout_started

付费墙转化率按 trigger 拆非常有用。「额度用完」触发的和「想批量」触发的，转化率可能差几倍。转化率高的触发点，就是用户真正愿意付钱的地方，定价和额度都照着它调。

支付完成率低于 50%，先查付款页：是不是不支持当地的付款方式、是不是价格突然加了税、是不是要求填太多信息。

2. MRR

MRR（月经常性收入）是订阅产品的主数字：

MRR = Σ 每个在订阅中的用户每月付的钱
      年付的按 ÷ 12 折成月，一次性付款不算进 MRR

光看 MRR 总数不够，要拆成四块：

本月 MRR = 上月 MRR
         + 新增 MRR          新付费用户
         + 扩张 MRR          升级、加量
         − 缩减 MRR          降级
         − 流失 MRR          取消、支付失败后没恢复

这样拆开，MRR 不涨的时候，才知道是新增少了还是流失多了。两种情况的解法完全不一样。

买断和点数包的收入不进 MRR，单独记一条「非经常性收入」。

3. 流失

用户流失率（月）   = 本月流失的付费用户 ÷ 月初付费用户
收入流失率（月）   = (缩减 MRR + 流失 MRR) ÷ 月初 MRR
净收入留存 NRR     = (月初 MRR + 扩张 − 缩减 − 流失) ÷ 月初 MRR      只算月初就在的老用户

流失拆成两类：

• 主动流失：用户自己点了取消。取消时问一个原因（太贵、不需要了、换了别的、功能不够、只是临时用一下），按原因统计
• 被动流失：信用卡过期、余额不足导致扣款失败。这类可以救回来：打开支付平台的自动重试（dunning）、发邮件提醒更新卡。被动流失常常占总流失的两三成，是最容易捡回来的钱

「只是临时用一下」占比高，说明这是一次性需求，别跟它硬拼月订阅，加一个按次付费或者短期套餐。

4. 单位经济

ARPU           = MRR ÷ 付费用户数
毛利率 GM       = (收入 − 支付手续费 − 服务器 − AI 调用成本) ÷ 收入
LTV            = ARPU × GM ÷ 月用户流失率
CAC            = 渠道投入（钱 + 折算的时间） ÷ 这个渠道带来的新付费用户
回本周期（月）   = CAC ÷ (ARPU × GM)

算个例子：ARPU 12 美元，毛利 80%，月流失 6%。

LTV = 12 × 0.8 ÷ 0.06 = 160 美元

一个付费用户能带来大约 160 美元的毛利。要让 LTV ÷ CAC 在 3 以上，获客成本就得压在 53 美元以下。低价工具靠广告很难做到这个数，这就是为什么工具产品要靠 SEO、插件商店、口碑这些不花钱的渠道。

AI 类工具一定要把调用成本算进毛利。免费用户的调用成本也要算，算成获客成本的一部分。

**早期流失率不稳定，LTV 算出来会很离谱。**付费用户不到 100 人、跑不满 6 个月的时候，LTV 只当参考，看回本周期更实在。

八、数字掉了怎么查

按树从上往下找，哪一段先断，问题就在哪一段。

1. 先排除假警报

• 是不是统计坏了：最近是否发过版、改过埋点、改过 GA4 设置、换了 Cookie 弹窗。去 PostHog 和 GA4 看实时事件，几个关键事件还有没有在进来
• 是不是日历效应：周末、节假日（美国感恩节、圣诞到新年）、月初月末。和上周同一天比，和去年同期比
• 是不是一个大号走了：一个大客户或者一次性的流量高峰走了，看的是平均数就会掉
• 样本是不是太小：一周只有 20 个付费，少了 5 个就是 −25%。量小的时候看 4 周移动平均，看置信区间（下一节）

2. 沿着树往下找

MRR 掉了
├─ 流失 MRR 涨了？
│    ├─ 被动流失涨了 → 支付平台的扣款失败率、dunning 设置
│    └─ 主动流失涨了 → 取消原因分布变了没；最近改过价格 / 功能 / 额度没
└─ 新增 MRR 掉了
     ├─ 付费转化率掉了？
     │    ├─ paywall_viewed 少了 → 额度 / 触发条件被改了？
     │    ├─ checkout_started / paywall_viewed 掉了 → 定价页、价格改了？
     │    └─ 支付完成率掉了 → 付款页报错、某国家的付款方式出问题
     └─ 激活用户少了
          ├─ 激活率掉了 → 工具成功率掉了？按 tool_name、浏览器、设备拆
          └─ 新访客少了 → 按渠道拆
                ├─ 自然搜索掉了 → 按 SEO 的监测里的漏斗查：抓取 → 收录 → 展示 → 点击
                ├─ 某个引荐源掉了 → 那个目录站 / 帖子是不是没了
                └─ 全部渠道一起掉 → 回到第 1 步，多半是统计坏了

3. 按维度切开

任何一个数掉了，先按这几个维度拆一遍，看是不是集中在某一块：

渠道 → 落地页 / 工具 → 国家 → 设备 → 浏览器 → 新 / 老用户 → 套餐

总数掉 10%，拆开常常会发现是某一个维度掉了 60%，其他都没动。

九、实验：改动到底有没有用

1. 能不能做 A/B 测试

A/B 测试需要的样本量，粗算：

每组样本量 n ≈ 16 × p × (1 − p) ÷ δ²

p 是现在的转化率，δ 是你想看出来的变化（绝对值）。这个公式对应的是常用的 95% 显著性和 80% 的把握。

例子：注册率 5%，想看出它变成 6%（相对提升 20%）：

n ≈ 16 × 0.05 × 0.95 ÷ 0.01² = 7,600    每组

两组一共要 15,200 个访客。一周 2,000 个访客的站，要跑将近两个月。

所以：

**做 A/B 时不要中途偷看结果就停。**每天看一眼，一看到显著就停下来，假阳性会多好几倍。开始之前算好样本量，跑够再看。

2. 小样本的时候，给数字带上误差

转化数很少的时候，一个比例后面要跟着它的置信区间。用 Wilson 区间：

p̂ = 转化数 ÷ 样本数 n，z = 1.96（95%）

中心 = (p̂ + z²/2n) ÷ (1 + z²/n)
半宽 = z × √( p̂(1−p̂)/n + z²/4n² ) ÷ (1 + z²/n)
区间 = 中心 ± 半宽

例子：这周 200 个访客，12 个注册，注册率 6%。算出来 95% 区间大约是 3.5% 到 10.2%。上周 4.5% 在这个区间里面，所以不能说这周变好了。

这就是建模时的习惯：数字要带误差。周报里比例类的指标，样本不到几百的都这么标一下。

3. 前后对比怎么做才靠谱

不能 A/B 的时候：

• 改之前记下 4 周的基线，改之后看 4 周。不要只比一周
• 同一时期只改一件事。同时改了标题和价格，涨了也不知道是谁的功劳
• 找一个没改的对照：只改了 A 工具页，就同时看没改的 B 工具页。两个一起涨，多半是大盘在涨
• 在 GSC、GA4、PostHog 都加上注释

十、常见的参考区间

下面这些是各种 SaaS 报告和独立开发者公开数据里常见的量级，来源不同、口径也不同，只能当刚起步时的起点。跑两三个月以后，用自己的数据替换掉。

和别人比没有太大意义，和自己上个月比才有意义。

十一、看板和节奏

1. 一个看板

在 PostHog 里建一个看板，从上到下按漏斗排，每一格一个数，都带上周对比：

┌──────────────┬──────────────┬──────────────┬──────────────┐
│ 每周价值用户   │ MRR          │ 新增付费       │ 流失付费       │
├──────────────┴──────────────┴──────────────┴──────────────┤
│ 新访客（按渠道堆叠）                                          │
├─────────────────────────────┬─────────────────────────────┤
│ 激活漏斗（最近 7 天）          │ 工具成功率（按 tool_name）     │
├─────────────────────────────┼─────────────────────────────┤
│ 周留存队列表                  │ 付费墙转化（按 trigger）       │
├─────────────────────────────┴─────────────────────────────┤
│ MRR 拆分：新增 / 扩张 / 缩减 / 流失（按月）                     │
└───────────────────────────────────────────────────────────┘

看板只放要做决定的数。放了但从来不会因为它做任何决定的数，删掉。

2. 节奏

每天（5 分钟）

• 看板第一行：有没有哪个数和上周同一天比变了 ±30%
• tool_failed 有没有突然变多
• 支付平台：有没有新的拒付、退款、扣款失败
• SEO 那部分的每日检查，见 SEO 的监测

每周（1 小时）

• 填周报（模板在下一节）
• 找出本周变化最大的一个数，沿着指标树拆到原因
• 看新一周的留存队列
• 流失最大的那一步，看 10 个录屏
• 更新实验池，挑下周的实验

每月（2–3 小时）

• 渠道质量表
• MRR 拆分、NRR、流失原因分布
• 单位经济：ARPU、毛利（含 AI 调用成本）、LTV、CAC、回本周期
• 自报归因和 GA4 归因对比
• 付费墙按 trigger 的转化，考虑调额度和定价
• 找 3–5 个付费用户和 3–5 个流失的用户聊 15 分钟

每季度

• 重看北极星指标和阶段目标（见 工具产品出海运营 的分阶段表）
• 重看参考区间，换成自己的数据
• 渠道组合：哪个渠道停掉，哪个加码

十二、周报模板

每周一份，和 SEO 周报放在同一张表里往下追加。

比例类的指标，分母不到几百的，在后面标上 95% 区间。告警线跑一两个月后，按自己的波动范围调。

十三、数据多了以后

PostHog 可以直接写 SQL（HogQL），也可以把事件导到 BigQuery、ClickHouse、Postgres。支付平台的数据用 Webhook 写进自己的数据库。下面两段 SQL 按 Postgres 写，别的数据库改一下日期函数；表名和字段按实际情况改。

1. 周留存队列

-- events(user_id, event, ts)
-- 以第一次 tool_succeeded 的那一周为队列，看之后每周还有没有 tool_succeeded
WITH first_value AS (
  SELECT user_id, DATE_TRUNC('week', MIN(ts)) AS cohort_week
  FROM events
  WHERE event = 'tool_succeeded'
  GROUP BY user_id
),
activity AS (
  SELECT DISTINCT user_id, DATE_TRUNC('week', ts) AS active_week
  FROM events
  WHERE event = 'tool_succeeded'
)
SELECT
  f.cohort_week,
  EXTRACT(DAY FROM a.active_week - f.cohort_week) / 7 AS week_n,
  COUNT(DISTINCT a.user_id) AS users,
  COUNT(DISTINCT a.user_id) * 1.0
    / MAX(COUNT(DISTINCT a.user_id)) OVER (PARTITION BY f.cohort_week) AS retention
FROM first_value f
JOIN activity a USING (user_id)
WHERE a.active_week >= f.cohort_week
GROUP BY f.cohort_week, week_n
ORDER BY f.cohort_week, week_n;

week_n = 0 那一行就是这组的总人数，所以用它做分母。

2. MRR 拆分

-- mrr_monthly(user_id, month, mrr)：每个用户每个月月末的 MRR，没订阅就没有这一行
WITH m AS (
  SELECT
    COALESCE(cur.user_id, prev.user_id) AS user_id,
    COALESCE(cur.month, prev.month + INTERVAL '1 month') AS month,
    COALESCE(prev.mrr, 0) AS prev_mrr,
    COALESCE(cur.mrr, 0) AS cur_mrr
  FROM mrr_monthly cur
  FULL OUTER JOIN mrr_monthly prev
    ON cur.user_id = prev.user_id
   AND cur.month = prev.month + INTERVAL '1 month'
)
SELECT
  month,
  SUM(CASE WHEN prev_mrr = 0 AND cur_mrr > 0 THEN cur_mrr END)                  AS new_mrr,
  SUM(CASE WHEN prev_mrr > 0 AND cur_mrr > prev_mrr THEN cur_mrr - prev_mrr END) AS expansion_mrr,
  SUM(CASE WHEN prev_mrr > 0 AND 0 < cur_mrr AND cur_mrr < prev_mrr THEN prev_mrr - cur_mrr END) AS contraction_mrr,
  SUM(CASE WHEN prev_mrr > 0 AND cur_mrr = 0 THEN prev_mrr END)                 AS churned_mrr,
  SUM(cur_mrr)                                                                   AS mrr
FROM m
GROUP BY month
ORDER BY month;

流失后又回来付费的用户，在这里会被算进新增 MRR。想单独看，再加一类「回流 MRR」：prev_mrr = 0，但更早的月份付过钱。

参考资料

指标与增长

• Amplitude: The North Star Playbook
• Lenny’s Newsletter: What is good retention
• Andrew Chen: The Power User Curve (L28)
• a16z: 16 Startup Metrics

工具

• PostHog Docs: Product analytics
• PostHog Docs: Identifying users
• Google Analytics: Custom campaigns (UTM)
• Google Analytics: User-ID
• Stripe: Revenue recovery / Smart Retries

实验与统计

• Evan Miller: Sample Size Calculator
• Evan Miller: How Not To Run an A/B Test
• Wikipedia: Wilson score interval