上线后的一周是大多数独立 App 默默死掉的时候——不是代码烂，是开发者慌了、连发一堆乱七八糟更新、追着评论跑。这篇是 90 天的稳健节奏。
问题背景
发布当天的信号都很噪：几个下载、可能一条评论、一点小的排名波动。新手对这些信号过度反应。正确的姿势是慢下来，盯着真正重要的几个指标，按一到两周的节奏稳定发版。App Store 奖励稳定胜过奖励快——每次更新有清晰发布说明的 App 比头一周乱发 5 版的 App 表现好得多。
判断标准
- 上线不到 90 天。
- 一直觉得有压力要发版、回复、改东西。
- 还没建立起发布节奏。
- 下载量不到 1000 但大于 0。
快速结论
前 90 天优先级：关键 bug 修复（48 小时内）、留存测量（持续）、每 2 周一个功能、忽略大部分评论。虚荣指标直接不看。
实操步骤
下面每条都附了：具体指标 + 量化阈值 + 工具操作。打开 RevenueCat / TelemetryDeck / GA4 / App Store Connect 跟着对。
-
上线日（D0）—— analytics 必须出数据。
核查清单：
- [ ] App Store Connect → Trends，过去 24h 安装数 > 0 - [ ] Crashlytics / TelemetryDeck / Sentry 看到非零 session - [ ] 自家事件追踪（"app_open", "onboarding_complete", "first_action"）触发率 > 0 - [ ] 推送 token 注册率 > 70%（如有用推送） - [ ] 内购沙盒已测过；线上是否有真实付款任何一条数据没出，立刻修——后面所有迭代都靠数据。
-
D1-D3：只修 crash，不发其他更新。
阈值：
crash-free user rate < 99.0% → 立即查 crash-free session rate < 99.5% → 立即查 单一 stack trace 影响 ≥ 5% 用户 → 48h 内必出修复Crashlytics / Sentry 入口：dashboard → “Issues” 按 “users affected” 排序。Top 3 拿出来 stack trace 直接对着改。修复 build 走 phased release（App Store Connect → Pricing and Availability → Phased Release for Automatic Updates → 默认 7 天放量，先 1% → 100%）。
-
D4-D7：评论分流。
分流规则：
1 星 + 描述具体 bug → 个人回复 + 进 backlog（"我们已修复在 v1.0.2，请更新") 1-2 星 + 主观抱怨（"难看"） → 不回复（占用情绪精力，不会改变评分） 3-4 星 + 具体建议 → 个人回复 + 进 backlog 5 星 → 不回复（不刷感谢，浪费时间）工具：App Store Connect → “Ratings and Reviews” 直接回。设过滤器
Country: All+Rating: ≤2。 -
W2：发第 1 个真实更新（v1.1.x）。基于第一周反馈选 1 件做：
优先级（按这个顺序选）： 1. 影响 onboarding 完成率的功能 bug（"first_action" 触发率 < 50% 就是 onboarding 有问题） 2. ≥3 个独立用户提到的同一个 missing feature 3. crash 修复（如果还有非 top-3 但反复出现的） 不要做： - 翻新 UI（onboarding 没修好，UI 翻新没用） - 加全新功能模块（用户还没掌握现有的） - 跟潮（"加 AI 功能"，除非真的有具体使用场景）写有版本号的 release note（参考 app-store-listing-copywriting 第 7 步）。
-
W3-W4：跟踪 D1 / D7 留存。
D1 留存（次日打开）： 行业平均（实用工具类）：30-40% 行业平均（社交 / 内容）：20-30% < 20% → onboarding 严重出问题 > 50% → 你的核心承诺命中 D7 留存（一周后打开）： 行业平均：8-15% < 5% → 核心价值没跑通 > 20% → 准备投放工具：
- 免费：TelemetryDeck（隐私友好 + 苹果适配，~$10/月）
- 简单：App Store Connect → Analytics → Retention（数据 lag 较多但够看趋势）
- 强大：Mixpanel / Amplitude（免费档 ~$0-$25/月）
每周一截图存档；横轴是 cohort（上线第 N 周注册的人），纵轴是 D7 留存。
-
W5-W8：核心价值 go/no-go 决定。
决策树：
if D7 留存 ≥ 10% 且 D7 留存有上升趋势: 核心价值跑通了，进入下一阶段（W8-W12 投放节奏） elif D7 留存 ≥ 10% 但持平 / 下降: 价值有一部分跑通，但有用户流失原因 → 用户访谈 + 漏斗分析 elif D7 留存 5-10%: 核心价值勉强，考虑 narrow 受众（"专为夜班护士设计"而非 "for everyone"） elif D7 留存 < 5%: App Store 优化救不了。准备 pivot 或 sunset用户访谈：从最近 7 天活跃用户里随机找 5 个发邮件（用 RevenueCat / Mixpanel 的 export 拿邮件），1 个 $10 Amazon gift card 换 20 分钟视频访谈。问 5 个固定问题：
1. 你是从哪儿听说本 App 的？ 2. 装完后，你期待它能解决什么具体问题？ 3. 第一次打开时，最让你失望 / 困惑的是什么？ 4. 现在你打开它的频率？是哪个具体场景让你打开？ 5. 如果今天必须卸载，你会因为什么？ -
W8-W12：建立两周一发的节奏。日历加循环事件
每两周周二发布 v1.X.0：工作流（每两周一轮）： D0 (周二) 选定 1-3 个变化，写 release note 草稿 D1-D8 开发 + 内部测试 D9 内部 review build D10 (周四) TestFlight 外部测试 50 人 D11-D12 收 TestFlight 反馈 D13 (周一) 提交审核 D14 (周二) 审核通过 → phased release 启动每次发布的 release note 强制 1-3 个变化（不要 10 条）+ 主题（“本次主题：onboarding 重写”）。
-
D90：完整复盘 + 决策。建一份
90_day_review.md：# 90 天复盘 - <App 名> - <日期> ## 核心数据 - 总安装：X - D1 留存：X%（行业均值 Y%） - D7 留存：X%（行业均值 Y%） - D30 留存：X% - 付费转化（如有）：X% - 平均 LTV：$X - CAC（如有投放）：$X ## 渠道分解 | 渠道 | 安装 | D7 留存 | 评分 | 备注 | |---------------|------|--------|------|------| | 自然搜索 | | | | | | App Store 编辑推荐 | | | | | | X / 社交 | | | | | | 朋友 / 圈子 | | | | | ## 决定 [ ] 进入下一季度，主投入：<具体方向> [ ] Pivot：保留 X，重做 Y [ ] Sunset：维护模式，不再加功能 [ ] 放弃：开源 / archive主要决定靠 D7 留存 + 自然增长趋势两条线，不要靠 NPS / 评分这种容易自欺的指标。
容易踩的坑
- 每小时刷 App Store Connect。更新很慢，量小的时候数据噪音很大。
- 回复每条评论。只回复有具体 bug 或指控的；主观负面忽略。
- 一周发 5 个更新因为不停发现小问题。攒在一起发。
- 把下载量当成功指标。下载只有转化成留存用户才有意义。
- 没搞清自然留存就买广告或买量。会在错的漏斗上烧钱。
- 让一条差评影响规划。一条评论就是一个数据点。
这篇适合谁
上线 90 天内的独立 App 开发者。
这篇不适合谁
已经有稳定用户的成熟 App——你需要更复杂的迭代框架。
FAQ
- 多久发一次更新: 每 1-2 周是健康节奏。再少失动力，再多用户觉得混乱。
- 一星评论怎么处理: 提到真实 bug 的，回复修复 ETA；泛泛的（“讨厌这个”）忽略——回复没用，互动反而放大它。
- 什么时候开始付费投放: 有 90 天留存数据、知道自然用户成本之后。在这之前投是赌。
- 怎么判断 App 失败了: 7 天留存低于 10% 且找不到明显解释是最强信号；崩溃率超过 1% 是第二强。两条都没踩到就给它时间。
相关阅读
标签: #独立开发 #App Store #App 上线 #工作流