你要建立的不是“上线日志”，而是一个增长实验账本：每次产品动作都必须写清楚：我改了什么、为了影响哪个指标、预计多久生效、用什么数据源看、用什么方法判断、最后是否保留。

最关键的一句话：

动作日志记录因，指标系统记录果，中间必须有时间窗口、对象范围、控制组、版本号。否则几周后数据变了，你根本不知道是你做对了，还是市场风向、SEO 波动、数据延迟、季节性、广告、竞品、Google 算法一起在演你。

你的 AI SaaS Web 上线指标系统可以先按这张 cheatsheet 做：

GSC 的 Performance report 里核心指标就是 clicks、impressions、CTR、average position，其中 CTR 是 clicks / impressions；GA4 里“key event”是你标记为对业务重要的事件，比如注册、购买、表单提交、订阅开始。Search Console 更偏“用户到达你网站之前发生了什么”，GA4 更偏“用户进入你网站之后做了什么”，这两个东西必须拼起来看。(Google 支持)

先讲一个小故事：为什么你现在觉得日志重要，其实说明你快到增长第二阶段了

一个 AI SaaS 创始人做了一个“PDF 转商业计划书”的网站。

第一周，他改了首页标题，从：

AI Business Plan Generator

改成：

Turn any messy idea into an investor-ready business plan in 60 seconds

他很兴奋。第二周 GSC impressions 涨了，CTA 点击也涨了。他说，兄弟，文案神了。

第三周，他又发现注册转化率跌了。他开始怀疑是不是按钮颜色错了，于是把蓝色按钮改成绿色。第四周，SEO clicks 涨了，但付费没涨。第五周，他又觉得 pricing 太贵，把价格砍半。第六周，他发现退款率上升，API 成本爆了。

最后他问：到底哪个动作有效？

答案是：不知道。

因为他犯了一个非常典型的错误：他把所有动作都当成“努力”，但没有把动作变成“可归因的干预”。

真正高手的做法是：每一次动作上线之前，就写一张 action card：

今天改首页 H1，只影响首页 hero，不动 pricing，不动 onboarding；假设是提升 SEO CTR 和 hero CTA click；预计 GSC CTR 2 到 4 周观察，hero CTA 24 小时观察，signup CVR 7 天观察；如果 CTA 涨但 signup 跌，就说明文案吸引了错误人群；如果 GSC impressions 涨但 CTR 跌，就说明标题覆盖面变宽但匹配度变差。

你看，差距不在“看不看数据”，差距在于：普通人看结果，高手在动作发生前就定义结果。

第一性原理：AI SaaS Web 增长不是“做动作”，而是“控制变量”

你要把网站当成一个复杂系统。它至少有三种时钟。

第一种是用户时钟。UI 改了，用户当天就能点，CTA、signup、表单、支付这些指标很快就能看到。

第二种是系统时钟。API 变了，延迟、错误率、token 成本几分钟就能看到。Google SRE 里经典的四个监控信号是 latency、traffic、errors、saturation，这个特别适合你监控 AI SaaS 的接口健康。(Google SRE)

第三种是搜索时钟。SEO 改了，Google 要重新抓取、理解、排序。Google 官方文档明确说，有些改动几天能看到效果，有些可能几个月；一般建议等几周再用 Search Console 分析改动是否影响排名。(Google for Developers)

第四种其实是最阴险的，叫数据管道时钟。GA4 BigQuery 日表会因为设备延迟上报，在事件日期之后最多继续更新 3 天；Search Console 的 24 小时视图可能几小时延迟，但新鲜数据点之后会被最终数据替换；Search Console 接入 GA 后，数据通常在 Search Console 收集后 48 小时可用，且最多包含 16 个月数据。(Google 支持)

所以你不能今天改了 SEO，明天看 GSC，然后说没用。那不是分析，那是焦虑。

金句来了：

增长不是多做事，而是让每一次做事都能留下证据。没有证据的努力，最后都会变成创始人的玄学。

你真正要做的是一套 Intervention Ledger

我建议你把这个系统叫：

AI SaaS Launch Intervention Ledger

中文就是：上线动作干预账本。

它不是单纯 changelog。changelog 只说你改了什么。intervention ledger 还要说：

我为什么改；
想影响什么；
预计什么时候影响；
影响谁；
用什么指标判断；
什么情况算成功；
什么情况必须回滚；
几周后复盘结果是什么。

你可以先不用很复杂，Notion、Airtable、Google Sheet 都可以。重点是字段必须对。

动作日志表应该长什么样

先建一张表，名字叫 action_log。

字段这样设计：

这里面最重要的是 hypothesis、primary_metric、guardrail_metrics、expected_lag、control_group。

没有这几个字段，你后面就会变成“我觉得这个动作好像有效”。

第二张表：指标字典 Metric Registry

很多创业者数据混乱，不是因为没有数据，而是因为每个人对同一个词的定义不一样。

比如 CVR，到底是：

访问到注册？
注册到激活？
访问到付费？
trial 到付费？
Google organic landing page 到 key event？

所以你必须建第二张表，叫 metric_registry。

尤其要注意，Search Console 的 clicks 和 GA4 的 sessions 不会完全一致。官方也明确说两者计算方式不同，趋势更重要；差异可能来自 tracking、cookie consent、timezone、attribution、canonical URL、非 HTML 页面、bot traffic 等因素。(Google for Developers)

小故事来了。

有个创始人看到 GSC clicks 是 1000，GA4 organic sessions 是 620。他第一反应是：GA4 坏了。

后来一查，很多用户从 Google 点进来后，页面加载慢、tag 没加载完、cookie 拒绝、还有 canonical URL 归并问题。最后不是数据坏了，是他拿两个不同世界的数字硬结婚。

数据像人，不能强扭，强扭出来的瓜不甜，还会误导你烧钱。

第三张表：实体映射表 Entity Map

你要把所有数据源串起来，必须有统一的 ID。

最小版本需要这些 ID：

为什么 page_id 很重要？

因为 Search Console 会把页面各种变体的数据归到 Google 选择的 canonical URL 上；如果你用 GA4 里的原始 landing page URL 去拼 GSC，很容易错。(Google 支持)

第四张表：每日指标事实表 Daily Metric Fact

你最终要让所有指标都变成统一粒度：

date + entity + segment + metric

比如：

这张表的价值是：你可以在 dashboard 上画一条时间线，然后把 action_id 作为竖线插进去。

你会看到：

5 月 18 日改了首页 H1；
5 月 19 日 CTA click 上升；
5 月 21 日 signup CVR 没变；
6 月 3 日 GSC CTR 上升；
6 月 10 日非品牌 clicks 上升；
6 月 17 日 paid CVR 没涨。

这时候你不会说“成功了”或者“失败了”，你会说：

这个动作提高了搜索点击和浅层兴趣，但没有提高商业转化。下一步不是继续改标题，而是检查 landing page 和 onboarding 的价值承接。

这叫有脑子地增长。

数据源怎么接：从轻量版到进阶版

起步版：先别装逼，上来就能跑

你第一版可以这样：

Notion / Airtable：动作日志
GA4：访问、事件、key events
GSC：SEO clicks、impressions、CTR、position
PostHog / Mixpanel：产品行为、funnel、feature flag、session replay
Vercel / Cloudflare / server logs：API 延迟、错误、流量
Stripe / Lemon Squeezy / Paddle：付费、退款、订阅
简单爬虫或 Screaming Frog 类工具：页面状态、title、meta、canonical、schema
一张 Google Sheet：每周复盘结果

Segment 的数据采集建议是先从少量、直接绑定业务目标的事件开始，不要一开始追踪无限多动作；Mixpanel 也把事件和属性字典作为让团队理解数据含义的重要机制。(Twilio)

进阶版：你要开始做自动化增长复盘

BigQuery / warehouse：统一存 GA4、GSC、product events、server logs
dbt：做指标模型
Looker Studio / Metabase / Retool：dashboard
Feature flag：PostHog / LaunchDarkly / Statsig
Experimentation：A/B、holdout、diff-in-diff
LLM observability：记录模型、token、latency、prompt version、eval score
Alert：API error、CVR 下跌、SEO 大跌、token 成本异常

Feature flag 很关键，因为它让你可以对特定用户、群组或流量百分比打开功能，不用每次重新部署，也适合灰度、A/B、kill switch。LaunchDarkly 的文档也强调，deployment 和 release 是两回事：代码上线不等于用户体验改变；feature flag 会让你必须同时追踪部署和发布。(PostHog)

这一点太重要了。

很多人说“我今天上线了新功能”。其实代码昨天就部署了，只是今天把 flag 从 0% 调到 50%。真正影响用户的是今天，不是昨天。你的 action log 必须记 release，而不只是 deploy。

AI 产品要额外记录什么

普通 SaaS 看点击、转化、留存。AI SaaS 还要看模型这一层。

你要记录：

OpenTelemetry 已经有 GenAI 相关语义约定，包括 token usage、operation duration、time to first token 等指标；Phoenix 文档也把 AI 输出评估定义为衡量准确性、groundedness、安全性、相关性等质量维度的方式，因为 LLM 输出不像传统软件那样只靠简单断言测试。(OpenTelemetry)

小故事。

一个 AI 简历生成器把模型从便宜模型换到高级模型。创始人只看到了用户满意度涨了，以为赚了。一个月后账单来了，毛利率被吃掉一半。

如果他当时 action log 里写了：

primary metric：output_acceptance_rate
guardrail：cost_per_activated_user、paid_cvr、gross_margin
expected lag：quality 1-3 天，paid 7-14 天，margin 30 天

他就不会被一个漂亮的“满意度提升”骗了。

AI 产品的增长不是让模型更聪明，而是让聪明变得可盈利。

你应该怎么定义事件：不要追踪一万个垃圾事件

你要先画出用户路径：

访问首页
看懂价值
点击 CTA
注册
第一次生成
看到结果
编辑或重试
导出 / 复制 / 分享
进入 pricing
开始 checkout
支付成功
第二天回来
第七天还在用

然后事件就这么埋：

这里重点不是事件多，而是每个事件都能回答一个增长问题。

generation_started 到 generation_completed 掉了，说明 API 或模型问题。
generation_completed 到 output_accepted 掉了，说明 AI 输出质量问题。
output_accepted 到 checkout_started 掉了，说明价值感和定价承接问题。
checkout_started 到 subscription_started 掉了，说明支付、价格、信任、条款问题。

SEO 指标怎么和产品指标合并

GSC 负责“进门前”，GA4 / 产品事件负责“进门后”。

你要这么连：

GSC query → GSC page → GA landing page → signup → activation → paid

比如一条 SEO 页面：

/ai-business-plan-generator

你要看：

Google 官方也建议把 Search Console 和 GA 一起看，因为前者解释用户如何在 Google Search 发现你，后者解释用户进入网站后如何互动；如果要最详细地减少差异，官方建议通过 Search Console bulk export 和 GA4 BigQuery export 在 BigQuery 合并。(Google for Developers)

你还可以做一个 SEO 四象限：

Search Console 的 bubble chart 思路也类似：用多个指标和维度一起看 query 表现，而不是只盯一个排名数字。(Google for Developers)

具体观察窗口：别把 SEO 当实时指标

你可以用这个节奏：

D0：上线当天，只看风险

看这些：

API error rate
p95/p99 latency
AI generation failure
checkout failure
页面 404 / 500
JS error
核心 funnel 有没有断
token cost 有没有爆
feature flag 是否按比例生效

不要在 D0 判断 SEO。最多看 Search Console 24 小时视图有没有异常，但它是监控，不是最终判断。Search Console 的 24 hours view 会以几小时延迟提供最近 24 小时数据，且为了尽快展示，会在数据未完全收集时先展示数据点。(Google for Developers)

D1 到 D3：看用户行为和数据稳定

看：

CTA click
signup started
signup completed
first generation success
activation within 24h
API latency
AI output accepted
rage click / session replay
support ticket

GA4 BigQuery 日表可能会继续补迟到事件最多 3 天，所以关键分析最好有 D+3 的成熟窗口。(Google 支持)

D7：看浅层增长是否真的转化

看：

signup CVR
activation rate
free-to-trial
trial usage
output accepted
checkout started
checkout success
cost per activated user
cohort quality

D14 到 D28：看商业指标

看：

paid CVR
D7 retention
repeat generation
subscription started
refund
support burden
gross margin
用户细分质量

W2 到 W8：看 SEO 初步结果

看：

GSC impressions by page
CTR by query cluster
average position
non-branded clicks
indexed pages
canonical 是否正确
organic signup
organic activation
organic paid

Google 对搜索流量下降的排查文档里也说，改动生效可能从几天到几个月不等，一般要等几周再分析 Search Console 里排名位置是否受益。(Google for Developers)

W8 到 W12+：看内容和权威信号

看：

query 覆盖范围
long-tail clicks
页面组表现
内链结构效果
内容更新后长期趋势
品牌词增长
comparison page / template page 是否带来付费

Web Vitals 和 UX 怎么放进动作日志

对 AI SaaS，速度很重要，但不能只看 Lighthouse 分数。

你要看：

LCP：首屏主要内容加载速度
INP：交互响应速度
CLS：布局稳定性
TTFB：后端首字节
JS error
Hydration error
API p95 latency
AI time to first token
AI total completion time

Core Web Vitals 通常用第 75 百分位衡量，并且要区分 mobile 和 desktop；web.dev 也强调实验室测量适合开发前发现问题，但不能代替真实用户现场数据。INP 已在 2024 年替代 FID 成为 Core Web Vitals 的响应性指标。(web.dev)

小故事。

一个 AI 工具首页 Lighthouse 从 62 分优化到 95 分，创始人高兴坏了。结果注册率没怎么动。

后来发现问题不在首页速度，而在“生成结果页”加载慢。用户点完生成后等了 11 秒，看见一个空白 loading，没有进度，没有示例，没有取消，没有 fallback。首页再快也没用。

所以你要记住：

用户不是在 Lighthouse 里买单，用户是在焦虑里买单。

AI 产品尤其如此。用户可以接受等，但不能接受“不知道还要等多久”。

API 指标怎么做：别只看接口通没通

AI SaaS 的 API 监控要至少有 5 层。

第一层：基础健康

requests per minute
success rate
error rate
5xx
4xx
timeout
retry
fallback_used

第二层：延迟体验

p50 latency
p95 latency
p99 latency
time_to_first_token
time_to_complete
queue_time
model_provider_latency
database_latency

OpenTelemetry 的 HTTP metrics 语义约定里包括 server request duration、active requests、request body size、response body size 等，这类标准化字段有利于跨工具过滤和对比。(OpenTelemetry)

第三层：AI 成本

input tokens
output tokens
cached tokens
billable tokens
cost per request
cost per signup
cost per activated user
cost per paid user

第四层：质量

regeneration rate
manual edit rate
copy/export/download rate
negative feedback
support complaint
hallucination report
eval score

第五层：商业护栏

paid CVR
gross margin
refund
churn
support cost
API abuse
free quota burn

AI SaaS 很容易被一个指标骗。比如“生成次数涨了”不一定是好事，可能是用户反复重试，因为第一次结果太烂。你要看的是：

生成成功 → 输出被采纳 → 用户回来 → 用户付费。

不是“模型调用次数越多越好”。调用多但不付费，那叫烧香，不叫增长。

怎么判断一个动作到底有没有效果

最低级：上线前后对比

适合小产品早期，但要小心误判。

公式：

上线后 7 天指标均值 - 上线前 7 天指标均值

问题是它容易被季节性、广告、搜索波动、其他上线动作污染。

好一点：同类控制组对比

比如你改了 10 个 SEO 页面 title，另外保留 10 个类似页面不动。

效果：

目标页面变化 - 控制页面变化

也就是：

(after_target - before_target) - (after_control - before_control)

这叫 diff-in-diff 的直觉版。对 SEO 很实用，因为你不能把同一个用户随机分配到 Google 搜索结果里的不同 title，但你可以找相似页面或相似 query cluster 做控制。

更好：A/B 测试

UI、pricing、onboarding、CTA、banner、modal、AI output layout，都尽量做 A/B。

A/B 的关键不是“分两组”，而是：

随机分配
提前定义主指标
提前定义护栏指标
不要中途偷看乱停
不要同时改太多东西
样本不够别装统计学大师

Kohavi、Tang、Xu 的《Trustworthy Online Controlled Experiments》是 A/B 测试领域很经典的实践书，作者来自 Microsoft、Google、LinkedIn，主题就是如何做可信的在线实验。(Cambridge University Press & Assessment)

SEO / 内容 / 大版本：用 CausalImpact 或时间序列

当你不能随机实验，比如一次性改了整个内容策略，可以用 CausalImpact 这类方法，用未受影响的市场、页面、查询、站点作为控制时间序列，估计如果没有这次干预，指标本来会怎么走。CausalImpact 文档也强调，这类非实验因果推断依赖强假设：控制时间序列不能被干预影响，且干预前建立的关系在干预后仍稳定。(google.github.io)

人话就是：

你可以用，但别迷信。模型很聪明，但你喂它垃圾控制组，它也只能优雅地胡说八道。

一个完整研究案例：AI SaaS “PitchPilot” 上线 8 周增长日志

下面是一个虚构但非常接近真实的案例。

产品：PitchPilot
功能：把一句创业想法生成 pitch deck、商业计划书、投资人邮件
目标：从 0 到稳定获取 organic signup
主要页面：
/ai-pitch-deck-generator
/business-plan-generator
/investor-email-generator
/startup-idea-generator

Week 0：上线前

创始人先建了 action log 和 metric registry。

他没有一上来埋 100 个事件，只埋了这些：

page_viewed
cta_clicked
signup_started
signup_completed
generation_started
generation_completed
generation_failed
output_accepted
checkout_started
subscription_started

他定义激活为：

新用户 24 小时内成功生成 1 次，并 copy/export/download 任意一次。

这个定义非常好。因为生成成功不等于用户觉得有用。用户把内容复制、导出、下载，才更接近真实价值。

Week 1：首页 hero 改版

动作：

H1 从：

AI Pitch Deck Generator

改成：

Create an investor-ready pitch deck from one startup idea in 60 seconds

假设：

更具体的价值主张会提高 CTA click 和 signup CVR。

观察窗口：

CTA click：1 到 3 天
signup CVR：7 天
GSC CTR：2 到 4 周

结果：

D3：CTA click 从 5.1% 到 7.8%
D7：signup CVR 从 2.4% 到 2.9%
D14：paid 没变
D28：GSC CTR 从 3.2% 到 4.1%

判断：

保留，但还不能庆祝。因为 paid 没动，说明它更多提升了浅层兴趣。

学习：

下一步要优化 first generation，而不是继续改首页文案。

Week 2：AI 输出页改版

动作：

生成结果页增加三个按钮：

Copy investor email
Export pitch deck outline
Improve with more traction details

假设：

用户更容易把输出带走，会提升 output accepted 和 activation。

结果：

D3：output accepted 从 38% 到 54%
D7：activation 从 21% 到 31%
D14：trial started 从 3.2% 到 4.0%
API 成本没变

判断：

保留。这个动作比首页文案更接近产品价值。

小故事：创始人原本想继续改 SEO title，但数据告诉他：真正堵点在结果页。这个时候能忍住不改 SEO，是一种高级能力。

增长最难的不是想新招，是克制自己别乱动。

Week 3：模型升级

动作：

把 pitch deck 生成从便宜模型切到更强模型，20% 用户灰度。

假设：

质量提升会降低 regenerate rate，提高 output accepted。

护栏：

latency
token cost
paid CVR
gross margin

结果：

D1：latency 从 3.2s 到 6.8s
D3：output accepted 从 54% 到 61%
D7：regenerate rate 从 29% 到 18%
D14：paid CVR 小幅提升
成本上涨 2.4 倍

判断：

不全量。改为 hybrid routing：免费用户便宜模型，trial 用户强模型，付费用户强模型 + fallback。

学习：

模型不是越强越好。模型要按用户价值分层。

Week 4：SEO title 改版

动作：

对 8 个 SEO 页面改 title 和 meta，4 个同类页面保留作为控制组。

假设：

更强 intent title 提升 CTR。

观察：

GSC CTR、clicks、average position、query cluster、organic signup。

结果：

W2：目标组 CTR +18%，控制组 +3%
W4：目标组 clicks +22%，控制组 +6%
signup 没涨

判断：

SEO 点击质量不够，可能吸引了“免费找模板”的用户，而不是愿意付费的创业者。

下一步：

增加页面内 use-case 分流：fundraising、student project、small business、agency client。

Week 5：pricing 页面改版

动作：

pricing 从三个 plan 改成两个 plan，并加上 “Best for founders preparing investor outreach”。

假设：

降低选择困难，提高 checkout started。

结果：

checkout started +15%
subscription started +5%
refund +9%

判断：

表面成功，实际危险。用户买了，但预期不准。

下一步：

在 pricing 加更清楚的限制说明，而不是继续诱导购买。

这个故事很重要。

不是所有转化率上涨都值得开心。坏收入比没收入更可怕，因为它会带来退款、差评、客服、口碑伤害。

Week 6 到 Week 8：复盘

最终他们发现：

首页文案提升浅层意图
结果页改版提升激活
模型升级提升质量但伤毛利
SEO title 提升点击但没有提升商业转化
pricing 提升购买但带来退款风险

真正有效的组合不是某一个动作，而是：

更具体的首页文案
更可采纳的 AI 输出页
按用户价值分层的模型策略
SEO 页面按意图分流
pricing 明确预期

这就是为什么你需要 action log。

没有 action log，这些学习都会混在一起，最后变成一句废话：

我们最近增长不错。

有 action log，你会知道：

哪一类动作对哪个指标有效，滞后多久，副作用是什么，下次怎么复用。

Dashboard 应该怎么设计

不要做那种密密麻麻 200 个图的 dashboard。那是给人看的坟场。

你要做 4 层。

第一层：Today Safety

今天有没有炸。

API error
p95 latency
AI failure
checkout failure
signup broken
token cost spike
404/500
deploy/release timeline

第二层：Weekly Growth

这一周增长有没有动。

sessions
organic clicks
signup CVR
activation
trial started
paid CVR
D7 retention
cost per activated user

第三层：SEO Control Tower

SEO 专门看。

GSC clicks
impressions
CTR
average position
query cluster
page group
device
country
indexed/canonical
organic key events

第四层：Action Review

按 action_id 看。

动作
假设
主指标
护栏指标
实际结果
结论
下一步

最重要的是 dashboard 上一定要有一条上线动作时间线。没有时间线的数据图，只能看趋势，不能做因果分析。

你要设哪些报警

报警不要太多，否则最后你会麻木。

建议先设这些：

API error rate 连续 15 分钟超过阈值
p95 latency 超过基线 30%
generation_failed 突增
checkout_success 跌破基线
signup_completed 跌破基线
token cost per generation 超过阈值
GSC clicks 连续多日异常下跌
核心页面 404 / noindex / canonical 异常
organic signup CVR 大跌
refund rate 上升

Google 排查 Search traffic drops 的文档也提醒，流量下降可能来自算法更新、技术问题、安全/垃圾内容问题、季节性、兴趣变化、迁移等，不要一看到掉量就立刻认定是某个动作导致。(Google for Developers)

隐私和日志：别把自己埋进坑里

AI 产品很容易记录用户输入、prompt、生成结果。这里要小心。

原则：

只记录必要数据
能 hash 就 hash
能聚合就聚合
不要裸存密码、密钥、支付信息
用户 prompt 先脱敏再入库
敏感字段做权限隔离
设置 retention
提供删除机制
日志不要变成泄密仓库

OWASP 的 Logging Cheat Sheet 强调，应用日志对安全、运营、业务流程监控、性能监控都重要，但日志要一致、可关联、可管理。GDPR 的 data minimisation 原则也强调只收集和保留实现特定目的所必要的数据。GA4 也提供数据保留和用户删除相关控制。(cheatsheetseries.owasp.org)

说狠一点：

你不是因为记录少而失败，你更可能因为记录了一堆不能用、不能删、不能解释、还可能泄密的数据而失败。

最常见的 12 个坑

第一，一天改太多东西。首页、pricing、SEO title、模型、注册流程一起改，后面谁有效完全不知道。

第二，只有 changelog，没有 hypothesis。只写“优化首页”，这不叫日志，这叫日记。

第三，只看主指标，不看护栏。CVR 涨了，但退款涨、成本涨、质量跌，那是假胜利。

第四，SEO 观察太急。SEO 是慢变量，3 天没动就乱改，是平庸之辈最常见的焦虑型操作。

第五，把 GSC clicks 和 GA sessions 当成必须相等。这俩本来就不是同一种计算口径。

第六，没有版本号。prompt 改了十次，没人知道用户看到的是哪版。

第七，没有 user segment。免费用户、trial 用户、付费用户混着看，结论大概率错。

第八，没有 query cluster。SEO 不能只按单个关键词看，要按意图群看。

第九，没有 baseline。上线前没有 14 到 28 天基线，后面所有分析都像在雾里开车。

第十，没有 control group。尤其 SEO 和内容策略，没有控制组很容易把市场趋势当成自己的功劳。

第十一，把平均值当真相。平均延迟没问题，p95 可能已经炸了；整体 CVR 没变，mobile 可能已经崩了。

第十二，不写 decision。动作上线后没人复盘，下一次又从零开始瞎猜。

给你一个最小可执行版本：7 天搭起来

Day 1：建三张表

action_log
metric_registry
entity_map

只要先在 Notion 或 Airtable 建出来。

Day 2：定义北极星和 5 个核心事件

北极星可以先用：

weekly activated users
或者
activated trial users
或者
paid users who generated accepted output

核心事件：

signup_completed
generation_completed
output_accepted
user_activated
subscription_started

Day 3：接 GSC + GA4

看：

GSC page/query/country/device/date
GA4 landing page/source/medium/session/key event
Search Console + GA 的差异先接受，不要强行对齐。

Day 4：接 API / AI logs

记录：

endpoint
model
prompt_template_id
latency
error
tokens
cost
fallback
user_segment
action_id / release_id

Day 5：做第一个 dashboard

只做 4 个页面：

Safety
Growth Funnel
SEO
Action Review

Day 6：开始用 feature flag

任何大改版，先 5%、20%、50%、100%。

不要裸奔。

Day 7：跑第一次周复盘

每个 action 只问 5 个问题：

原假设是什么？
指标到了观察窗口吗？
主指标变了吗？
护栏坏了吗？
保留、回滚、继续观察、还是迭代？

一个可以直接复制的 Action Card 模板

Action ID:
Date:
Owner:
Action Type:
Surface:
Target Entity:
Release ID:
Feature Flag:
Variant:
Traffic Allocation:

What changed:
Why now:
Hypothesis:
Primary Metric:
Guardrail Metrics:
Leading Indicators:
Lag Window:
Baseline Window:
Analysis Window:
Data Sources:
Control Group:
Measurement Method:
Expected Result:
Rollback Rule:
Decision Date:
Final Decision:
Learning:
Next Action:

示例：

Action ID: ACT-20260518-001
Date: 2026-05-18
Owner: Founder
Action Type: ui_hero_copy
Surface: homepage
Target Entity: /
Release ID: deploy_92ac
Feature Flag: homepage_hero_v2
Variant: treatment
Traffic Allocation: 50%

What changed:
Homepage H1 changed from "AI Pitch Deck Generator" to "Create an investor-ready pitch deck from one startup idea in 60 seconds".

Why now:
CTA click rate is below baseline and users may not understand the product outcome.

Hypothesis:
A more concrete outcome-based H1 will increase hero CTA click and signup CVR.

Primary Metric:
hero_cta_click_rate, signup_cvr

Guardrail Metrics:
activation_rate, bounce_rate, paid_cvr

Leading Indicators:
scroll depth, CTA click, signup_started

Lag Window:
UI: 1-3 days
signup: 7 days
SEO CTR: 2-4 weeks

Baseline Window:
Previous 28 days

Analysis Window:
D3, D7, D28

Data Sources:
GA4, PostHog, GSC

Control Group:
No control for homepage. Compare against same weekday baseline and non-home landing pages.

Measurement Method:
Before-after + guardrail check

Rollback Rule:
Rollback if signup CVR drops more than 15% for 3 consecutive days while traffic mix is stable.

Decision Date:
2026-06-15

Final Decision:
Pending

Learning:
Pending

最后给你一句狠的

你要日入十万刀，光会“上线”不够。上线只是动作，不是资产。

真正的资产是：

你知道哪类动作，在什么用户、什么页面、什么搜索意图、什么模型版本、什么时间窗口下，会稳定带来什么结果。

这才是增长系统。

普通创业者是这样活的：

今天有灵感，明天改页面，后天看数据，大后天焦虑，下一周推倒重来。

高手是这样活的：

每一次动作都是实验，每一次实验都有证据，每一次证据都进入系统，每一次系统都让下一次判断更准。

增长的本质不是冲动，而是复利化的判断力。

SOP Checking List + 5W2H

SOP Checking List：上线前

• 这次动作有唯一 action_id

• 写清楚 action_type：SEO / UI / UX / API / AI model / pricing / onboarding / content

• 写清楚 target_entity：页面、接口、prompt、功能、价格页、query cluster

• 写清楚 release_id / commit / deploy id

• 如果是用户可见功能，必须有 feature flag

• 写清楚假设，不允许只写“优化体验”

• 定义 primary metric

• 定义至少 2 个 guardrail metrics

• 定义 leading indicators

• 定义 expected lag window

• 定义 baseline window，最好 14 到 28 天

• 定义 analysis window：D1、D3、D7、D14、D28、W8

• 定义 control group，没有也要写“无控制组，结论低置信度”

• 定义 rollback rule

• 确认事件已埋点

• 确认 key event 已标记

• 确认 UTM 规则正确

• 确认 GSC 页面和 GA landing page 能通过 page_id 对齐

• 确认 API logs 里有 endpoint、model、prompt version、latency、error、tokens、cost

• 确认隐私字段已脱敏

• 确认 dashboard 已能看到上线前基线

SOP Checking List：上线当天

• 记录实际 release time

• 记录实际 traffic allocation

• 检查 404 / 500 / JS error

• 检查 API p95 / p99 latency

• 检查 error rate

• 检查 generation_failed

• 检查 checkout 是否正常

• 检查 signup funnel 是否断

• 检查 token cost 是否异常

• 检查 feature flag 是否命中目标用户

• 不在当天判断 SEO 成败

SOP Checking List：D1 到 D3

• 看 CTA click

• 看 signup_started

• 看 signup_completed

• 看 generation_completed

• 看 output_accepted

• 看 API 成本和错误

• 看 session replay / rage click

• 看移动端和桌面端是否分化

• 只做安全和早期信号判断，不做最终结论

SOP Checking List：D7 到 D14

• 看 signup CVR

• 看 activation rate

• 看 paid intent

• 看 checkout started

• 看 support ticket

• 看 refund early signal

• 看免费用户和付费用户分层

• 和 baseline / control group 对比

• 写初步 learning

SOP Checking List：W2 到 W8

• 看 GSC impressions

• 看 GSC clicks

• 看 GSC CTR

• 看 average position

• 看 query cluster，而不是只看单个关键词

• 看 page group，而不是只看单页

• 看 organic signup

• 看 organic activation

• 看 organic paid

• 检查 indexed / canonical / sitemap / noindex / robots

• 检查是否有 Google 算法、季节性、趋势变化干扰

• 做最终 decision：keep / rollback / iterate / inconclusive

5W2H

最终标准只有一个：

每次上线之后，团队必须能在 2 到 8 周后回答：这次动作是否有效，证据是什么，副作用是什么，下一次怎么复用。