上线后第一天做什么
产品上线后第一天，不是庆祝结束，而是验证开始。
很多独立开发者上线当天最容易犯两个错误：一个是反复刷数据，什么也不改；另一个是看到一点反馈就立刻大改产品。
第一天真正要做的，是确认产品在线、关键路径可用、数据能看、错误可控、用户反馈有人接住，然后用最小动作修掉最影响体验的问题。
本文参考了前面几篇已经建立的基础设施思路：
- Google Search Console Sitemap report
- Google Analytics 4 Reports
- Sentry Alerts
- Vercel Cron Jobs
第一天不要急着做增长
上线第一天，你最想看的可能是：
来了多少访问 有没有人注册 有没有人付费 社媒有没有转发 搜索有没有收录这些当然重要，但第一天更重要的是确认“系统是否真的能承接用户”。
如果登录失败、支付失败、邮件发不出去、页面打不开、错误没人知道，再多流量也会浪费。
第一天的重点不是放大，而是校准。
先确认线上可用
上线后第一小时，先做最基础检查：
首页能打开 核心页面能打开 移动端显示正常 注册流程能跑通 登录流程能跑通 核心功能能完成 支付或订阅能进入正确流程 邮件能收到 上传或导出能成功 后台能正常查看数据不要只在自己的电脑上看。
至少用：
无痕窗口 移动端浏览器 不同网络 新账号 测试支付方式上线后第一天，很多问题不是代码完全坏了，而是环境变量、域名、回调 URL、权限、缓存、第三方配置没有对齐。
看错误，不要只看访问量
第一天要打开错误监控和日志。
重点看：
生产环境新错误 5xx 接口 前端白屏 注册失败 登录失败 支付失败 Webhook 失败 邮件发送失败 后台任务失败不要只看 PV。
访问量上涨但错误也上涨，说明产品可能正在伤害第一批用户。
Sentry Alerts 这类告警能力可以帮助你在关键错误出现时及时发现，但前提是你已经配置了环境、release 和关键路径告警。
盯住关键漏斗
第一天不要看太多指标。
只看几个关键漏斗：
访问首页 → 查看核心页面 → 注册 注册 → 完成 onboarding → 触发核心功能 查看定价页 → 开始支付 → 支付成功 打开文章 → 阅读 → 点击 CTA如果你还没有足够数据，不要急着算复杂转化率。
先看事件是否正常上报，漏斗是否能跑通，有没有明显断点。
例如：
有人访问但没人开始注册 有人注册但没人完成 onboarding 有人点击支付但支付成功为 0 有人上传但导出失败这些断点比总访问量更值得关注。
收集真实反馈
第一天最宝贵的是早期反馈。
你要主动收集：
用户在哪一步卡住 哪句话没看懂 哪个按钮找不到 哪一步觉得不可信 为什么没有继续 是否愿意再次使用 是否愿意推荐给别人收集渠道可以很简单：
站内反馈按钮 邮件回复 社群私信 表单 客服聊天 日历访谈不要只问“你觉得怎么样”。这个问题太空。
更好的问题是：
你刚才想完成什么？ 哪一步让你犹豫？ 你预期它应该怎么工作？ 如果你不用它，原因是什么？只修高影响问题
上线第一天最危险的事，是看到任何反馈都立刻改。
你应该把问题分级：
P0：产品不可用、支付失败、数据泄露、严重错误 P1：关键路径卡住，明显影响注册、激活、付费 P2：体验问题，但有绕过方式 P3：文案、样式、细节优化第一天优先修 P0 和 P1。
P2 记录下来，P3 不要被它拖走。
上线当天不是重做产品的时候，而是保证第一批用户能顺利走完核心路径。
不要马上重构定位
第一天数据通常很少。
不要因为 20 个访问没有注册，就立刻判断“产品方向不行”。也不要因为 1 个用户说不喜欢，就马上改定位。
第一天更适合验证：
页面是否能解释清楚 入口是否能正常到达 核心路径是否有明显 bug 数据是否能采集 用户是否理解你在解决什么问题方向判断需要更多样本和更长时间。
第一天要做的是排除明显错误，不是推翻全部策略。
更新公开入口
上线后别忘了检查公开入口。
首页 CTA 定价页 文档页 博客文章 RSS Sitemap robots.txt 社媒简介链接 Product Hunt 或其他发布页 邮件签名 导航站提交资料如果你有 SEO 页面，要确认 Sitemap 已更新，并在 Search Console 中检查是否能读取。
如果你有 RSS，要确认 feed 已包含新内容，且rel alternate能被发现。
记录第一天日志
上线第一天要写一份简短记录。
可以包括：
上线时间 版本号 发布渠道 访问量 注册数 激活数 支付数 主要错误 主要反馈 当天修复 未解决问题 下一步动作这份记录以后很有价值。
它能帮助你复盘：哪些渠道有效，哪些问题反复出现，哪些改动真的改善了数据。
一个第一天检查清单
你可以按这个顺序做：
1. 手动跑通首页、注册、登录、核心功能、支付 2. 检查错误监控和日志 3. 检查埋点事件是否上报 4. 看关键漏斗有没有明显断点 5. 检查邮件、Webhook、后台任务 6. 确认 Sitemap、RSS、公开链接 7. 收集第一批用户反馈 8. 修复 P0 / P1 问题 9. 写下第一天上线记录 10. 安排第二天要验证的假设这比盯着实时访问量更有用。
写在最后
上线后第一天，不要急着证明自己成功，也不要急着证明自己失败。
你要做的是把产品从“能部署”推进到“能被真实用户顺利使用”。
第一天的目标很简单：关键路径可用，问题能发现，反馈能接住，修复有优先级，下一步有方向。
从第二天开始，再谈增长、转化、留存和规模化。
下一篇，我们进入第四阶段：为什么产品没人用。
原文链接：上线后第一天做什么 | Harries Blog™