公开数字前先把「公开」理解成一套编辑流程，而不是一次社交媒体冲动。独立开发者最常见的坑不是数字太小，而是把 Stripe、Plausible、Simple Analytics 或后台订单截图原样发出去，顺手暴露了客户、邮箱、账户余额、地理位置和谈判筹码。

这套 SOP 只处理已经发生的产品级数字。未签合同、未到账款项、投资条款、客户名单、家庭住址、税务身份、银行余额都不进入公开素材库。

先定义数字口径，还是先截图？

先定义口径。截图只是证据，口径才决定别人能不能正确理解你的业务。

Stripe Billing analytics 把 MRR 视为 active 和 past_due 订阅的月度归一化价值，并排除试用、税费、免费计划和部分用量计费。客户取消最后一个订阅或被标记为 unpaid 后，相关收入不再计入 MRR。

所以公开前要写清 4 个字段：

  • 时间范围：过去 30 天、自然月、最近 7 天，三者不能混写。
  • 收入类型：MRR、ARR、一次性收入、GMV、到账现金，不要统称「营收」。
  • 扣除规则：是否扣退款、税费、折扣、失败付款和平台手续费。
  • 统计工具：Stripe Billing、ChartMogul、自建 SQL、Plausible 或 Simple Analytics。

如果你只发「$2,000 revenue」，读者无法判断这是 10 个年付订单、200 个一次性订单，还是一个尚未扣税的平台流水。

哪些数字可以公开？

公开数字的默认粒度是「产品级、聚合、已发生」。能让读者学到运营判断，又不会把客户或自己置于风险里。

指标推荐公开粒度公开文案模板内部记录
MRR产品级总额，月度更新「5 月 MRR 从 $420 到 $610，新增来自 7 个月付客户」Stripe 原始报表、退款、优惠券
ARRMRR × 12 的年化口径「当前 ARR run-rate 约 $7.3K，不等于今年已到账收入」年付、月付拆分
付费客户数总数或区间「付费客户 28 个，其中 22 个是月付」客户邮箱、公司名、合同
转化率匿名漏斗百分比「试用到付费 18%，样本是 50 个试用结束用户」用户 ID、事件日志
流失月度聚合原因「本月 3 个取消：2 个价格原因，1 个功能缺口」取消邮件、访谈记录
访问量聚合趋势「官网 30 天访客 +32%，主要来自 3 篇 SEO 文章」IP、城市、referrer 明细
里程碑已完成事实「第 10 个付费客户来自 Indie Hackers 帖子」对话记录、折扣码

早期产品可以公开小数字。$83 MRR 比「我们增长很快」更可信，但前提是你承认样本小，不把它包装成可复制增长模型。

哪些数字不该公开？

有些数字一旦发出去，删除截图也没用。独立开发者尤其要保护 5 类信息。

  1. 客户级信息：客户名、邮箱、公司域名、订单号、Invoice ID、对话截图。
  2. 账户级信息：Stripe balance、银行尾号、提现记录、后台 URL、管理员头像。
  3. 合同与投资信息：未签 MOU、报价单、单客户 ACV、投资条款、估值谈判。
  4. 个人安全信息：住址、常驻城市、家人照片、护照、税号、公司注册文件。
  5. 可被反推的技术细节：风控规则、告警阈值、数据库表结构、API key 前后缀。

GDPR Article 5(1)(c) 的数据最小化原则要求个人数据只保留与目的相关、必要且有限的部分。即使你不在欧盟，也可以把这条当作公开截图的最低标准：能裁掉就裁掉，能打码就打码，能用聚合数就不用明细。

MRR、收入、用户数怎么写才不误导？

公开数字时最容易混淆的是 MRR、现金收入和用户数。

MRR 是经常性订阅收入的月度口径。年付订单要摊到每月，一次性服务费不应混入 MRR。

ARR 通常是 MRR × 12 的 run-rate，不代表银行账户已经收到 12 个月现金。

Revenue 要写清是 gross revenue、net revenue、cash collected 还是 recognized revenue。早期创始人公开时建议用「本月到账现金」或「订阅 MRR」二选一，不要混合。

Active subscribers 在 Stripe 口径里可配置为订阅开始时或首次付款收到时计入；免费计划、试用用户和 MRR 为 0 的订阅不该被包装成付费客户。

Churn 要分取消和降级。ChartMogul 把 contraction MRR 视为现有客户降级带来的 MRR 损失，把 churn MRR 视为客户取消最后一个订阅带来的损失。公开「流失」时最好写成「取消 2 个、降级 1 个」，比一个百分比更有信息量。

截图发布前要检查什么？

截图要服务于一个观点：证明某个运营动作发生过，而不是证明你有多会赚钱。

发布前按这份 checklist 过一遍：

  • 裁掉浏览器地址栏、书签栏、账号头像和工作区名称。
  • 打码客户名、邮箱、订单号、Invoice ID、Session ID、付款方式尾号。
  • 隐藏账户余额、提现记录、银行信息、税务表单和公司注册信息。
  • 标出时间范围，例如 2026-05-01 至 2026-05-31。
  • 写明统计工具和口径，例如 Stripe Billing analytics 的 MRR。
  • 不展示单客户收入，除非客户已书面同意公开案例。
  • 保留原图到内部 evidence 文件夹，公开版只存打码图。
  • 发出前让自己隔 10 分钟重看一次，确认没有顺手暴露个人信息。

Plausible 和 Simple Analytics 这类隐私友好分析工具会强调无 cookies、无个人数据、聚合统计。即便如此，公开截图时仍要裁掉小样本地理位置、referrer 详情和能识别单个客户的搜索词。

发布节奏应该多频繁？

公开数字的频率越高，越容易被数字牵着走。早期 SaaS 建议用「周动作、月数字、季度复盘」。

节奏公开内容不公开内容
每周本周 ship 了什么、访谈了几个人、修了哪个漏斗MRR 每日波动、单个客户对话
每月MRR、付费客户数、取消/降级原因、一个关键学习账户余额、税务、未签合同
每季度定价调整、渠道表现、产品方向取舍投资条款、runway、单客户 ACV
重大节点第 1 个付费客户、第 10 个客户、第一次退款复盘客户身份、支付截图明细

不要用日更 MRR 当内容主线。日度收入对小样本产品噪音太大，今天一个年付订单会让你虚高，明天一个退款会让你误判。

客户、投资人和竞品会怎么读这些数字？

客户看公开数字，关心的是你是否稳定、是否会泄露他们的信息。你公开客户截图越随意，越难拿到 B2B 客户信任。

投资人看公开数字，会把它当成增长连续性、留存和定价能力的线索。融资或并购前，过度公开下滑原因、runway 和大客户依赖，会削弱谈判空间。

竞品看公开数字，通常不会因为你公开 MRR 就立刻复制产品。更敏感的是你的获客渠道、关键词、定价实验和高转化落地页。渠道数据可以讲方法，不要把完整关键词表、广告组和转化最高的邮件模板一起放出来。

公开时用这条规则：能帮助潜在用户信任你的数字，可以发；只会帮助旁观者围观或对手复刻的细节，留内部。

30 天 operating routine 怎么跑？

下面这套 30 天 routine 适合从 $0 到 $5K MRR 的单人 SaaS。团队更大时，把审批人和法务检查补进去。

日期动作产出
Day 1建一个 metrics ledger，列出 MRR、客户数、试用、取消、访问量口径1 张 Notion / Sheet 表
Day 2-3从 Stripe、Plausible、Simple Analytics 导出基线数据内部原始截图
Day 4写公开白名单和黑名单公开限制文档
Day 5-7发第一条无收入数字的过程帖：问题、假设、下周动作1 条过程帖
Day 8-14每天记录 1 个产品动作，不发账户截图7 条内部日志
Day 15汇总半月指标，只公开趋势，不公开明细半月复盘帖
Day 16-21访谈取消、试用未转化或沉默用户3-5 条原因标签
Day 22选一张可公开截图，做打码版public screenshot v1
Day 23-26写月度复盘草稿，标出口径和样本大小复盘草稿
Day 27检查客户、投资人、竞品三个风险视角发布前检查表
Day 28发月度数字：MRR、付费客户数、一个失败教训月度公开帖
Day 29收集反馈，不实时解释每个质疑评论记录
Day 30更新下月目标，只承诺动作，不承诺增长曲线下月公开计划

这套 routine 的重点是可重复：每月固定同一天取数、同一套口径、同一张表。数字变好时不夸大，数字变差时不消失。

可直接复制的公开模板

把下面模板存成每月复盘草稿，发布前删掉不适用的行。

Month: 2026-05
Product: [产品名]
Metric source: Stripe Billing analytics + [analytics tool]
MRR definition: active / past_due subscriptions, excluding trials, free plans and taxes

Public numbers:
- MRR: $___ → $___
- Paid customers: ___ → ___
- Trial-to-paid conversion: ___% over ___ ended trials
- Churn/contraction: ___ canceled, ___ downgraded
- Main channel: ___

What changed:
- Shipped: ___
- Learned: ___
- Next 30 days: ___

Not shared publicly:
- Customer names
- Account balance
- Invoice IDs
- Contract terms
- Investor conversations

数字公开不是越透明越高级，而是让外界看到你如何做判断。能长期坚持同一口径、保护客户、承认样本限制，才是 Build in Public 真正能积累信任的部分。

相关阅读