# Ai 产品saas web的上线动作日志 - 状态 / Status: 草稿 / Draft - 时间 / Time: 2026-05-19T20:17:02+08:00 - 作者 / Author: 良辰美 - 主题 / Topics: AI / AI, 流量 / Traffic, 方法论 / Methodology 你要建立的不是“上线日志”，而是一个增长实验账本：每次产品动作都必须写清楚：我改了什么、为了影响哪个指标、预计 --- 你要建立的不是“上线日志”，而是一个 增长实验账本 ：每次产品动作都必须写清楚： 我改了什么、为了影响哪个指标、预计多久生效、用什么数据源看、用什么方法判断、最后是否保留 。 最关键的一句话： 动作日志记录因，指标系统记录果，中间必须有时间窗口、对象范围、控制组、版本号。否则几周后数据变了，你根本不知道是你做对了，还是市场风向、SEO 波动、数据延迟、季节性、广告、竞品、Google 算法一起在演你。 你的 AI SaaS Web 上线指标系统可以先按这张 cheatsheet 做： 模块 你要记录的动作 你要看的指标 多久看一次 常见误判 API / AI 模型 新模型、新 prompt、新 fallback、新接口、新限流 p95/p99 延迟、错误率、成功率、token 成本、首 token 时间、用户重试率、输出采纳率 5 分钟、1 小时、24 小时 API 变快了，但输出变差，CVR 反而跌 GSC / SEO 新页面、标题改写、description、结构化数据、内链、sitemap、canonical、内容更新 impressions、clicks、CTR、average position、query cluster、indexed/canonical 状态 24 小时仅监控，2 到 8 周判断 第 3 天没涨就乱改，是菜鸟行为 UI / UX 首页 hero、CTA、导航、pricing、onboarding、表单、demo flow 点击率、滚动深度、signup start、signup complete、activation、rage click、session replay 当天到 7 天 只看按钮 CTR，不看后面的注册/付费 CVR / 激活 免费试用、支付页、额度策略、模板推荐、AI 结果页 signup CVR、trial activation、paid CVR、D1/D7 留存、refund、support ticket 1 到 28 天 转化率涨了，但低质量用户也进来了 内容 / SEO 长线 新 landing page、use case、comparison、template、programmatic SEO 非品牌点击、query 覆盖、页面组点击、lead、key event 2 到 12 周 把 SEO 当广告，想今天投明天收 归因分析 action_id、release_id、page_id、feature_id、query_cluster_id action 前后变化、控制组差异、A/B 实验、CausalImpact 每周复盘 没有控制组，靠感觉说“这个动作有效” 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 。 字段这样设计： 字段 解释 示例 action_id 每个动作唯一 ID ACT-20260518-001 action_date 上线时间，统一时区 2026-05-18 10:30 PT action_type 动作类型 seo_title_change / ui_hero_copy / api_model_change / pricing_change surface 影响区域 homepage / pricing / onboarding / api_generate_plan target_entity 具体对象 /ai-business-plan-generator release_id 代码版本 / commit / deploy ID deploy_9fd23a flag_key feature flag new_homepage_hero_v2 variant 版本 control / treatment traffic_allocation 流量比例 20% users owner 负责人 founder hypothesis 假设 更具体的 H1 会提升 SEO CTR 和 CTA click primary_metric 主指标 GSC CTR by page + hero_cta_click_rate guardrail_metrics 护栏指标 signup CVR、API error、bounce、paid CVR expected_lag 预计滞后 UI 1-3 天；SEO 2-6 周 baseline_window 基线窗口 上线前 28 天 analysis_window 分析窗口 上线后 7/14/28 天 measurement_method 判断方法 A/B / before-after / diff-in-diff / causal impact control_group 控制组 similar pages: /ai-proposal-generator data_sources 数据源 GA4、GSC、PostHog、API logs rollback_plan 回滚条件 signup CVR 跌超 15% 且 error 正常 decision_date 复盘日期 2026-06-15 decision 保留/回滚/迭代/不确定 keep learning 学到什么 CTR 涨，但激活没涨，说明吸引的是浅层用户 这里面最重要的是 hypothesis 、 primary_metric 、 guardrail_metrics 、 expected_lag 、 control_group 。 没有这几个字段，你后面就会变成“我觉得这个动作好像有效”。 # 第二张表：指标字典 Metric Registry 很多创业者数据混乱，不是因为没有数据，而是因为每个人对同一个词的定义不一样。 比如 CVR，到底是： 访问到注册？ 注册到激活？ 访问到付费？ trial 到付费？ Google organic landing page 到 key event？ 所以你必须建第二张表，叫 metric_registry 。 字段 示例 metric_id signup_cvr metric_name 访问到注册转化率 formula signup_completed_users / landing_page_sessions source GA4 + product DB grain daily / page / channel owner growth freshness_lag D+3 caveat GA4 session 和 GSC click 不能直接一一对应 primary_dimension page_id、channel、device used_for homepage、SEO landing page、pricing 尤其要注意，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： ID 用途 page_id 把 URL、canonical URL、GSC page、GA landing page 对齐 query_cluster_id 把相似搜索词聚成组，比如 ai resume writer、ai cv generator feature_id 把产品功能统一，比如 ai_generate、template_library、export_pdf api_endpoint_id 把接口统一，比如 POST /api/generate prompt_template_id 把 AI prompt 版本统一 release_id 把代码部署统一 flag_key 把功能开关统一 experiment_id 把 A/B 测试统一 user_segment_id free、trial、paid、new_user、returning_user action_id 把动作和结果连起来 为什么 page_id 很重要？ 因为 Search Console 会把页面各种变体的数据归到 Google 选择的 canonical URL 上；如果你用 GA4 里的原始 landing page URL 去拼 GSC，很容易错。(Google 支持) # 第四张表：每日指标事实表 Daily Metric Fact 你最终要让所有指标都变成统一粒度： date + entity + segment + metric 比如： date entity_type entity_id segment metric_id value source 2026-05-18 page homepage mobile_us gsc_clicks 120 GSC 2026-05-18 page homepage mobile_us gsc_ctr 0.041 GSC 2026-05-18 page homepage mobile_us signup_cvr 0.032 GA4 2026-05-18 api generate_plan all p95_latency_ms 1800 API logs 2026-05-18 prompt plan_v7 trial_users output_acceptance_rate 0.62 product DB 这张表的价值是：你可以在 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 还要看模型这一层。 你要记录： 指标 为什么重要 model_provider 不同模型质量、成本、延迟不同 model_name 版本切换会影响输出 prompt_template_id prompt 改动就是产品改动 input_tokens 成本和延迟来源 output_tokens 成本和用户体验来源 total_cost 每次生成成本 time_to_first_token 流式体验的关键 total_generation_time 完整等待时间 retry_count 用户不满意的信号 regenerate_count 输出质量信号 edit_after_generation 输出可用性信号 export/download/copy 输出被采纳信号 user_rating 显性质量反馈 eval_score 自动评估质量 safety_refusal_rate 安全和可用性平衡 hallucination_reported AI 产品特有风险 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 支付成功 第二天回来 第七天还在用 然后事件就这么埋： 阶段 事件名 关键属性 访问 `page_viewed` page_id、channel、device、utm 意图 `cta_clicked` page_id、cta_id、copy_version 注册 `signup_started` source、page_id 注册完成 `signup_completed` auth_method、plan_intent AI 生成 `generation_started` feature_id、prompt_template_id、model AI 成功 `generation_completed` latency、tokens、cost、output_type AI 失败 `generation_failed` error_type、model、fallback_used 输出采纳 `output_accepted` action: copy/export/download 重试 `generation_regenerated` reason、attempt_number 激活 `user_activated` activation_rule_version 付费 `checkout_started` plan、price_version 支付 `subscription_started` plan、coupon、billing_period 留存 `user_returned` days_since_signup 这里重点不是事件多，而是每个事件都能回答一个增长问题。 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 你要看： 层级 指标 SERP 曝光 impressions SERP 吸引力 CTR SERP 位置 average position 到站质量 engagement rate / bounce / scroll 意图质量 CTA click 注册 signup CVR 产品价值 first_generation_success 商业结果 paid CVR Google 官方也建议把 Search Console 和 GA 一起看，因为前者解释用户如何在 Google Search 发现你，后者解释用户进入网站后如何互动；如果要最详细地减少差异，官方建议通过 Search Console bulk export 和 GA4 BigQuery export 在 BigQuery 合并。(Google for Developers) 你还可以做一个 SEO 四象限： 情况 意味着什么 动作 高 impressions，低 CTR 页面有曝光，但标题/描述不吸引或意图不准 改 title、meta、rich snippet 高 CTR，低 signup 搜索结果吸引人，但 landing page 承接差 改 hero、demo、CTA 高 signup，低 activation 用户被吸引注册，但产品第一步失败 改 onboarding、模板、AI 输出 高 activation，低 paid 用户有价值感，但商业转化卡住 改 pricing、额度、付费触发点 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 维度 你要问的问题 标准答案 Why 为什么做这个动作？ 因为某个指标或用户路径存在明确瓶颈，不是因为创始人突然手痒 What 到底改了什么？ 一个可描述、可定位、可回滚的具体干预，比如首页 H1、pricing CTA、prompt v7 Who 影响谁？ 哪类用户、哪类流量、哪个国家、哪个设备、哪个 plan、哪个 cohort When 什么时候上线，什么时候看？ 上线时间、数据成熟时间、短期窗口、长期窗口全部写清楚 Where 影响哪个位置？ 页面、接口、prompt、funnel step、SEO query cluster、feature flag How 怎么判断有没有效果？ A/B 优先；不能 A/B 就控制组；不能控制就时间序列；都没有就低置信度 before-after How much 成本和收益是多少？ 不只看 CVR，也看 token 成本、毛利、退款、客服、留存、长期 SEO 收益 最终标准只有一个： 每次上线之后，团队必须能在 2 到 8 周后回答：这次动作是否有效，证据是什么，副作用是什么，下一次怎么复用。