首充转化率暴跌根因分析（深挖修正版）
口径：新注册用户 2h 内完成首次充值 ｜ 数据源：production PostgreSQL + DebugBear RUM + GA4 + SigNoz + 本地双版本对照实验 ｜ v2 修订 2026-07-27
⚠️ 本版为深挖修正版：初版报告将「充值页前端性能劣化」列为主因。深挖后该结论被本地双版本对照实验推翻（v4.6.3 vs HEAD 渲染链行为零差异），且 LCP 恶化（07-24 起）与转化破位（07-25 起）时间解耦。本版给出修正后的结论。
TL;DR：首充转化率 07-25 = 17.5%、07-26 = 14.8%（基线 ~25%，相对 -40%），下跌是真实的、所有用户子群同步下跌。
深挖穷尽后确认：全部技术链路（支付、取号、页面、接口、资源交付）工作正常，没有任何一个技术故障能解释下跌。
最强剩余嫌疑是 07-25 20:31 无灰度全量硬推的 dashboard 购买流程 redesign + 推荐排序变更（时间与影响面吻合，但视觉改版导致 -40% 的归因强度不足）；
同时 GA4 归因 07-26 起大面积断裂造成流量质量盲区，无法排除渠道内低意愿流量涌入的叠加。可操作的裁决手段只有一个：redesign 灰度回滚 / A/B 验证 + 修复 GA4 归因。
一、跌幅事实（不变）
| 日期(北京) | 星期 | 注册数 | 2h内创建充值单
(意愿层) | 2h内首充成功
(最终转化) |
|---|
| 07-21~24 基线 | 周二~周五 | ~610/天 | ~42% | 23.0~27.8%（均值 ~25%） |
| 07-25 | 周六 | 595 | 34.5% | 17.5% |
| 07-26 | 周日 | 710 (+18%) | 29.9% | 14.8% |
- 修正：初版称「07-24 白天已在跌」——错，那是 4h 桶噪声。日粒度看 07-24 全天 26.0% 完全正常，破位起点是 07-25。
- 意愿层（注册→创建充值单 42%→30%）是大头；完成层（nihaopay 首充 46%→37%）次之。
- 周末效应真实存在但不够：与上周六/日（24.8% / 20.2%）同周期对比仍差 5~7pp。
二、深挖排除清单（本次调查的核心产出）
每一项都有独立数据反证，可复查：
| 假设 | 反证据 |
|---|
| 充值页前端代码劣化（初版主因） | 本地双版本对照实验：v4.6.3 与 HEAD 同环境同条件，渲染链瀑布结构完全一致（hydrate→auth/me→config→表单，无新增串行环节）；chunk 数量相同（34 个）、体积 HEAD 反而小 21KB；LCP candidate 序列一致。且 RUM LCP 恶化始于 07-24 08h 而转化 07-24 正常——时间解耦 |
| majorphones fan-out 拖慢取号 | 订单分配延迟 p50=0s / p90=0.09s 全程无恶化，分配成功率反升（48%→68%）；INVALID_COUNTRY 失败是毫秒级、fallback 无感。它只是烧供应商 API 成本（#665 已修，07-27 部署后应归零） |
| v4.7.3 topup_poller 影响充值确认 | nihaopay 支付确认延迟 p50 稳定 22~36s，部署时点（07-25 16:56）前后无阶跃 |
| 支付网关故障 | 服务端 error 日志全时段仅 5 条；nowpayments/stripe 完成率稳定；nihaopay 无 checkout 生成失败 |
| 流量 mix-shift / bot 稀释 | 6 个子群（邮箱域名×OAuth）内部转化全部同跌；邮箱模式/验证速度/OAuth 占比（66→73%）无异常 |
| 价格/供给展示污染 | 热门组合最低价无突变；金额档位（$3.15 主档）未变；订单 e2e 成功率反升（11%→16%）；服务分布无剧变 |
| 后端接口变慢 | topups/config p75=1ms、auth/me p50=940ms（07-20 起恒定）、catalog 接口 p95 平稳——全程无趋势变化 |
| bundle/字体/第三方脚本 | HTML 55.3KB 恒定；Geist Variable 可变字体单文件；PostHog sessionRecording=false；GTM 环境参数为设计内配置；Next.js 16.2.10 是 07-04 就上线的 |
三、修正后的结论
最强嫌疑 · 需 A/B 裁决v4.7.5/4.7.6-force-frontend：购买流程 redesign + 推荐排序变更，无灰度全量硬推
- 时间吻合：07-25 20:22/20:31 上线（
-force-frontend 强推）；07-25 显著恶化集中在 16 时后（18.2%/19.6%），07-26 全天最深（14.8%，晚间 12.3%）。
- 影响面吻合：改的是新用户注册后第一屏（接码三步流程视觉全换：编号面板/卡片/提示条/角标），叠加 favicon pipeline 的推荐排序变更（hasLogo 优先，无 logo 服务沉底）——推荐位是本项目已知的敏感杠杆（历史上有推荐位自我强化闭环教训，团队共识是改排序需 A/B）。
- 归因保留：redesign 文档确认交互逻辑未变（纯视觉+排序）。视觉改版单独解释 -40% 强度不足——这正是需要实验裁决而不是继续读代码的原因。
并行事故 · 阻塞排查GA4 归因断裂（07-26 起），流量质量成盲区
- 07-26 起
(not set)/(not set) session 从 ~100/天暴涨至 527/天，真实渠道（google/bing/direct）等比缩水，国家构成不变——测量断裂而非流量变化。断裂窗口对齐 v4.7.7（07-26 00:24）~ v4.7.8（07-26 11:17）。
- 后果：注册量 +18% 的增量来自哪里、质量如何，当前无法回答——「渠道内低意愿流量涌入」这个与 redesign 并列的候选解释因此无法排除。修归因是解锁流量侧排查的前提。
- 排查起点：GTM 容器 07-26 前后的版本发布记录；v4.7.8 删除的
createConsentSelection（静态零引用已验证，需确认 GTM 容器自定义模板无运行时引用）；redesign 对 dashboard 首屏时序的改变与 GTM 注入时序（#617 曾修过）的交互。
背景因子周末 + nihaopay 完成率轻度下滑
周末贡献约 3~5pp 的自然回落（不解释同比恶化）；nihaopay 首充完成率 46→37% 与意愿层同源（到达支付环节的用户群体质量/意愿变化的下游表现），无独立网关故障证据。
四、时间线（修正版，北京时间）
07-24 08:53 · v4.6.6
前端 #643 纯死代码删除。
当天转化 26.0% 正常（初版误判此处开始恶化）。RUM LCP 测量口径从当天起漂移（hard-load 构成变化），与转化无因果。
07-25 00:00 · v4.7.0
majorphones enable → INVALID_COUNTRY 无效 fan-out 开始（纯成本问题，用户无感，#665 已修）。
07-25 20:22/20:31 · v4.7.5 / v4.7.6-force-frontend
购买流程 redesign + favicon pipeline（含推荐排序 hasLogo 优先）无灰度全量上线。07-25 晚起转化显著走低。
07-26 00:24 / 11:17 · v4.7.7 / v4.7.8
此窗口内
GA4 归因断裂爆发（not-set 527/天）。当天转化 14.8% 触底（晚间 12.3%）。
07-27 · 进行中
转化未回升（不成熟口径 ~9-10%）。#665（国家预过滤）随下一次部署生效。
五、行动建议（修正版，按优先级）
- P0 · 裁决实验：对 v4.7.5/4.7.6 的 redesign（含推荐排序 hasLogo 变更）做灰度回滚或 50/50 A/B，跑 2~3 天看意愿层（注册→创建充值单）是否回升。这是唯一能终结「redesign vs 流量质量」之争的手段——代码侧已读尽，没有更多可读的了。
- P0 · 修 GA4 归因：不修，流量侧永远是盲区，后续任何转化波动都无法归因。排查方向见上文。
- P1 · 独立性能债（非本次根因，但深挖顺带确认的高价值优化）：
/api/auth/me p50=940ms 且每次页面冷加载串行调用 2 次（本地瀑布实测）——每个冷加载用户白等 ~2s，慢网用户放大到 4s+。降到 100ms 级或去重合并，全站冷加载体验立升。- topup 详情页（支付回跳落地页）LCP p75 = 8s——用户付完钱要盯 8 秒骨架屏才能确认到账，重复支付/焦虑风险。
- P1 · majorphones 价值评估：上线两天 1163 次调用换 1 个成功单；#665 部署后确认 fan-out 归零，并评估该供应商去留。
- P2 · 流程复盘：本次 5 天内 9 个 tag、redesign 用
-force-frontend 无灰度硬推、推荐排序变更未走 A/B（违背团队既有共识）——建议 user-facing 大改版强制走灰度/AB 门槛。
六、深挖方法记录（供复查）
- 本地双版本对照：
git worktree 挂 v4.6.3 与 HEAD 各自 next build + next start，同一浏览器/同一 DB/后端统一不可用（fallback 路径一致），PerformanceObserver buffered 采集 LCP candidate 序列 + resource timing 瀑布对比。
- RUM 元素级归因：慢样本（
span.font-medium，6.2s）FCP 完全正常（2.58s）→ 劣化在 FCP 后阶段；delta 单峰 ~3s 平滑分布（串行往返 × RTT 形态，非超时）。
- SigNoz traces 反证：
topups/config / auth/me / dashboard/catalog 三组接口 07-18~27 全程平稳。
- chunk graph 对比：client-reference-manifest 提取 topup 页 34 chunks，两版本数量一致、体积 573KB→552KB。