从用户第一次访问到付费留存，分 6 阶段看整条链路。每个节点点击跳到对应详细 section。
数据窗口：累计（自 telemetry 上线以来全部去重 install_id；AE 数据保留上限 90 天）。tui_active_24h 节点是 24h 滚动窗口（"截至现在还活跃"）。
Master Funnel — 用户生命周期 Sankey（累计）
每个节点的数字 = 历史累计到达该阶段的去重 install_id 数（自 telemetry 上线起；AE 上限 90d；之后突破上限要等 Phase 0 持久化）。
例外：tui_active_24h 节点是 24h 滚动窗口（"截至现在还活跃"），用来对照"累计装上的人里现在还在用的"。
灰色 terminal 节点 = 累计在该阶段流失（再没到下一阶段）。
红色 placeholder 节点 = 数据待补：registered 等 CC 内部 telemetry 上线；topped_up 等 install_id↔user_id 映射。
点击节点跳到对应阶段详细 section。
⚠️ 关于"累计"与"tui_active_24h"两个时间窗：
其余节点都是累计（自 telemetry 上线起的去重 install_id；AE 上限 90d，再老的事件 evict）。所以 install_start 这条数字会随时间一直涨，不会回落。
tui_active_24h 是 24h 滚动：过去 24h 内 wrapper 被执行 且 command 是空字符串或 chat 的去重 install_id 数 —— 即用户敲 lucky（无参，进 TUI 主界面）或 lucky chat。这条数字会涨会跌。
不算进 TUI 的调用：只用子命令的（lucky billing/recharge/auth 等）；side commands（--version/doctor/update，wrapper 直接跳过埋点）；设了 LUCKY_DISABLE_TELEMETRY=1 的用户（完全不可见）。
节点 value = 累计首次启动 且 24h 内进过 TUI 的去重人数（"累计装机里还活着的"）。
caveat：launch 是 session start 不是使用时长 — 一个 lucky session 挂 8 小时只算 1 次 launch；要测真实活跃时长得等 Phase 2（CC 内部 tengu_* heartbeat 事件）。
⓪ Node Gate — install.sh 启动后 node 版本检测
fix-5（2026-05-28 14:07 北京）上线 install.sh / install.ps1 的 node preflight：
缺 node → emit node_missing + 输出平台安装教程；node<18 → node_too_old；通过 → node_ok。
历史上 inner_missing_node（内层 bridge installer 发现）是头号失败模式（7d 745 条），
fix-5 应该让外层 gate 接管这部分人 → 看 inner 曲线塌陷 + 教程把人拉回来再装。
Node Gate 三态分布（24h）
node_ok = 通过；node_missing / node_too_old = 终止安装并显示教程。
两者占比 = "安装前被 node 卡住"的人。
fix-5 前 / 后 cohort 对比
同口径 start → success 转化率对比。after 窗口随时间长大，样本少时数字波动大，看趋势就行；2-3 周后才稳定。
Node Gate 分平台堆叠（7d）
linux / wsl 通常是 node 缺失高发；macOS / Windows 多数自带 node。
inner_missing_node 小时趋势（7d）
内层 bridge installer 发现 node 缺失的事件数。fix-5 后应该塌陷（外层 gate 接管），残留 = 旧版 install.sh 缓存 / mirror / 第三方 fork 还在跑老脚本。
阶段详细
③ Activate — 首次启动
装上后多快被打开，决定了产品"首因效应"。TTV (Time-to-Value) 是 install 到 first_run 的延迟；装→启动转化率是有多少装上了的人最终启动了 wrapper。
TTV 分布（14d 窗口）
从 inner_install_success 到 lucky_wrapper_first_run 的延迟分布。P50 = 中位数。
⑤ Convert — 注册 / 登录漏斗
数据源 = cc_auth_events（lucky #198 / claude-zh.cn #23, 2026-05-25 上线）。Lucky CC 内部 BridgeLocalAuthFlow 的 13 个 tengu_bridge_* 事件。
⚠️ Join key 未对齐：cc_auth_events.user_id (CC 自生成 64-hex, getOrCreateUserID()) 和 wrapper_events.install_id (install.sh 生成) 是两套独立 ID，无法直接 join。所以这个 section 的所有数字只能在 cc_auth_events 内部串起来，不能算 "今天 install 成功的人里多少最终注册了"。Master Funnel 的 registered 节点也因此没有从 first_launched 连线过来。
要打通必须 CC 改代码 emit 一次 install_user_link 事件（已草拟 follow-up issue，待提）。
注册 / 登录漏斗 Sankey（累计；按 user_id 去重）
菜单 → choice → login_attempt/register_attempt → success/failed → token_install_success。
红色 terminal 节点 = 累计流失。choice_idle 含选了 browser/cancel/reset 的（未真按 login/register）。
auth_choice intent 分布（累计）
用户选了什么路径：login / register / reset / browser / cancel。看主要诉求。
Routing path × event 分布（累计）
direct (绕过 bridge，#193 灰度) vs bridge (走 bridge.annealing.cn) 在终态事件上的对比。
目前 prod 仍是 bridge 中介模式（#193 灰度未开），direct 数应该为 0。
失败原因 top（24h）
22 个 reason enum（wrong_credentials / verification_code_invalid / turnstile_challenge / rate_limited_by_upstream / token_pickup_failed / ...）。按 event × reason 聚合。
看到 unknown 命中即 reason 映射有漏（应该 0；#191 acceptance 要求）。
Duration 分位数（24h，ms）
*_attempt → *_success/_failed 端到端 wall time。P50/P90/P99。
Identifier 查询（PII; debug 用）
最近 7d 最活跃的 top 20 identifier（username/email）。用于 user-reported 问题排查：用户报告 screenshot 里有 email，直接到这里看他经历了什么。
identifier 是 PII，禁止公开分享 dashboard URL/截图给非内部人员。
核心指标
用户增长趋势
用户增长趋势（最近30天）
展示每日新增用户、活跃用户和付费用户的变化趋势。关注新增用户的稳定性和付费用户的增长速度。
DAU 趋势（最近30天）
每日活跃用户数（DAU）反映产品的用户粘性。持续上升表示用户留存良好，波动较大需关注用户流失原因。
留存与转化趋势
留存率趋势（最近30天）
7日留存率：7天前活跃的用户中今天仍活跃的比例。留存率高于40%表示产品粘性强，低于20%需优化用户体验。
新用户转化率分析
Phase 2
新用户转化率趋势（最近30天）
按首次使用日期分组，追踪新用户在不同时间窗口内的付费转化率。D3转化率是核心指标，反映新用户在3天内的付费意愿。D0转化率低但D3转化率高，说明用户需要时间了解产品价值，应优化前3天的引导流程。
复购率分析
Phase 2
分层复购率分布（历史累计）
根据充值次数将付费用户分为4个层级：单次充值（1次）、低频复购（2-5次）、中频复购（6-20次）、高频复购（>20次）。高频用户虽然占比小，但贡献大量收入，需要重点维护。单次充值用户占比高，说明有巨大的复购提升空间。
复购用户数量分布（历史累计）
展示各复购层级的用户数量。用于识别不同价值层级的用户规模，制定差异化运营策略。
注册激活分析
Phase 3
累计注册 vs 累计激活趋势
展示累计注册用户和累计激活用户的增长趋势，两条线之间的差距即为未激活用户池，代表潜在的增长机会。
整体激活率趋势
整体激活率 = 累计激活用户 / 累计注册用户，反映产品对注册用户的吸引力。激活率下降说明新用户质量下降或产品体验问题。
用户价值分层
用户分层分布（历史累计）
根据调用量将用户分为未付费、轻度、中度、重度四类。重度用户（>100次调用）是核心价值用户，需重点维护。
激活点分析（历史累计）
不同调用次数区间的付费转化率。15次调用是关键激活点，超过此阈值的用户付费意愿显著提升。
渠道分析
渠道新增用户排行（历史累计）
各渠道（首次使用模型）带来的新增用户数。识别高价值渠道，优化资源投放策略。
渠道转化率对比（历史累计）
各渠道的付费转化率（总付费用户/总新增用户）。高转化率渠道说明用户质量好，应加大投入。仅显示新增用户≥10的渠道。
模型使用分析
模型调用排行 Top 10（历史累计）
各模型的总调用次数。热门模型反映用户需求偏好，可作为产品优化和定价策略的参考。
未配置 CF_AE_READ_TOKEN / CF_ACCOUNT_ID，本 tab 数据未拉取。
配置方法见仓库 .env.example。
⓪ 官方路径核心面板 post-#31 (2026-06-02 18:48 北京)
口径：claude-zh.cn/scripts/install.sh 自 PR #31 起不再 delegate lucky，纯走 npm install -g @anthropic-ai/claude-code。本面板数据全部限制在 #31 cutoff 之后；Lucky 路径数据在「安装（Lucky 路径）」tab。
官方 vs Lucky 占比（最近 7 天，按 install_id 用户数）
两路径 install_id 独立 mint 不重叠。Started 用户绝对数对比，看现阶段官方推广 vs lucky 自然增长的力量对比。
官方安装漏斗（最近 7 天）
用户级（DISTINCT install_id）从 start → node_ok → npm_install_start → 成功/失败。最大流失通常在 node_*（系统没装 node 直接劝退）和 npm_install（包源 / 网络 / 权限）。
24h 小时趋势（北京时间）
Started / Success / Failed 用户数 + Pass Rate 折线。空桶填 0。
Node Gate 24h（官方独有）
Lucky 路径不查 node。这里 node_missing = 系统没装 node 被劝退（最大流失源），node_too_old = node < 18。
↓ 以下区块是历史 install tab 的内容，基于 start/success/failed 全窗口数据（pre-#31 含 lucky delegate 混入）。
① 诊断摘要
② 流量全景（桑基图）
从 start 到完成的用户流向
每条带子宽度对应人数。分叉点 = 卡点，越粗的分流到「失败 / 中途流失」越说明该处有问题。
install_id 还在累积，目前是按阶段计数估算；后续会切换为按 install_id 精确 join。
③ 核心漏斗与趋势
转化漏斗（最近 7 天）
用户从触达 → 环境检查 → bridge installer → 安装成功 4 个阶段的转化。
宽度对应人数；百分比 = 该阶段 / start。鼠标悬停可看「占上一阶段」转化率，最能精确定位卡点。
阈值参考：任一相邻阶段转化率 < 80% 即视为明显卡点。
每日 start / success / failed（最近 30 天）
红色 failed 突增通常预示 bridge installer 或下游故障；start 长期下行说明引流有问题。
④ 分平台对比（最近 7 天）
各平台 start / 进入 bridge / 成功率
横轴是平台，左侧条形是绝对人数（start vs success），右轴是成功率折线。
阈值参考：单平台成功率 < 60% 且 start ≥ 5 → 诊断面板报 critical。
⑤ Windows git 自动安装链路
Windows 用户 git 检测 + 镜像 fallback + 安装结果
仅 install.ps1 上报。Windows 没装 git 时脚本按顺序尝试 npmmirror → npmmirror_cdn → tuna → github 四个镜像；任一成功即继续。
阈值参考：总失败率 > 30% 触发警告，需检查镜像可用性或换默认源。
⑥ 最近失败明细（最多 30 条）
查看失败用户特征：是否集中在同一国家、同一 shell、同一架构。聚集 = 系统性问题；分散 = 个例。
| 时间 (北京) | 脚本 | 平台 | 架构 | Shell | 国家 | install_id |
| 暂无数据 |
附：维度分布（最近 7 天 start 事件）
未配置 CF_AE_READ_TOKEN / CF_ACCOUNT_ID，本 tab 数据未拉取。
⓪ Lucky 路径核心面板 bridge.annealing.cn / install.sh (inner_*)
口径：用户从 post-install 提示里复制
curl bridge.annealing.cn/install.sh | sh 跑的 Lucky wrapper 安装。Lucky 路径不查 node（假设系统已经能跑 cli.mjs），跟
官方路径 install_id 独立 mint。
Lucky vs 官方 占比（最近 7 天，按 install_id 用户数）
两路径 install_id 独立 mint 不重叠。Lucky 走 bridge installer 装 wrapper，官方走 npm install -g。Started 用户绝对数对比。
Lucky 安装漏斗（最近 7 天）
用户级（DISTINCT install_id）从 inner_start → inner_download_success → 成功/失败。失败堆积通常在下载（网络 / 镜像）或装包（checksum / npm / payload missing）。
24h 小时趋势（北京时间）
Started / Success / Failed 用户数 + Pass Rate 折线。空桶填 0。
失败原因 top 24h
Lucky 不查 node，所以这里看的是装包阶段失败：缺命令 / 下载 / checksum / npm / payload。下一个 hotfix 该打哪个。
↓ 以下区块是历史 Lucky 监控的内容（按平台拆 / 30d 趋势 / wrapper 活跃度 / auto-update / install_id drill-down）。
真实安装成功率（最近 7 天）
基于内层 install.sh 的 inner_install_success / inner_start。真正下载并装上 lucky 才算 success，与下方"流程触达率"区分。
流程触达率（最近 7 天）
外层 install.sh 的 success / start。统计的是"有多少人走完了整个 install 流程"，包括下载脚本、平台检测、git 检查、delegate 到内层等步骤 — 不代表真的装上了。
每日成功率趋势（最近 30 天）
L / WSL / macOS 每日成功率 + 修复发布标记
每条线是一个平台当日 success / start 百分比。竖虚线 = markers.json 里登记的修复发布；修复后看对应平台曲线是否上扬即可判断是否有效。
样本太小会被剔除：当日 start < 3 的点用空值，避免极端值干扰判断（如 1/1=100%）。
如何添加 marker：编辑服务器 /root/newapi_export/dashboard/markers.json，每条 {date, label, note, platforms?, time?}，刷新页面即可。
热补丁监控（最近 72 小时，小时粒度）
L / WSL / macOS 每小时成功率 + 修复发布标记
专门用于看刚发的热补丁前后是否有变化。每个点是当小时 success / start 百分比（北京时间整点对齐）。
实线 = 真实安装成功率（内层）；虚线 = 流程触达率（外层）。点 legend 可关闭某条。
样本太小会被剔除：当小时 start < 2 的点用空值。
竖虚线 = markers.json 里登记的修复发布；marker 若带 time 字段（HH:MM 北京时间）会落到对应小时桶。
失败原因 top（最近 24 小时）
按 inner stage × 平台聚合
基于 install_events 内层失败 stage：inner_missing_* / inner_*_failed / inner_checksum_failed / inner_payload_* / inner_bad_* / inner_metadata_unavailable。按平台堆叠。
哪个 reason 数最大，下一个 hotfix 就该打哪个。
每日 start / success 绝对量（最近 30 天）
Linux
柱=start, 线=success；line 跟不上柱意味着失败堆积。
WSL
柱=start, 线=success；line 跟不上柱意味着失败堆积。
L / WSL 失败明细（最近 7 天，最多 50 条）
只看 Linux/WSL 的失败事件。若 install_id 重复，说明同一用户反复重试 —— 是修复后回归测试或老问题持续。
| 时间 (北京) | 平台 | 架构 | Shell | 国家 | install_id |
| 暂无数据 |
Wrapper 活跃度（wrapper_events）
装完真的在用 — 统计 wrapper 每次启动。和 install 数对比能看出"装机留存率"。子命令调用可看用户用 lucky 做什么。版本分布能找出 stale wrapper（没 auto-update 上来的）。
活跃 wrapper / 启动次数（14d）
活跃 = 去重 install_id；启动 = 事件总数。两者差距大 = 单个用户高频启动。
版本分布（7d，按 install_id 去重）
如果有人卡在老版本，说明 auto-update 没在他那跑通。
OS 分布（7d, 按 install_id 去重）
子命令 top（24h）
用户最常调的子命令 — billing / auth / chat / ...
Auto-Update 健康（update_events）
wrapper 内 auto-update 链路是否健康 — check / available / start / success / failed 比例 + 升级耗时分位数。失败要看 reason 分布。
失败原因分布（24h）
lucky_auto_update_failed + lucky_auto_update_check_failed 的 reason 取值（download_failed / installer_exit_N / metadata_unavailable / version_missing）。
版本滞后（24h 内 check 出来的 current → latest 配对）
按 install_id 去重。多少人还卡在哪个版本没升上来。
| current_version | latest_version | install_id 数 |
|---|
| 暂无数据 |
Install ID 深挖（drill-down）
取最近 24h 最活跃的 top 20 install_id，跨 install / wrapper / update 三个 dataset 拼时间线。
选一个 ID 看它的完整经历 — 装没装上、有没有 launch、有没有 auto-update。debug 单个用户问题时直接用。
已登记修复发布
从 markers.json 读取：手动 markers（你 curate 的关键 fix 发布）+ 自动 markers（每 6h cron 拉 piglet12138/claude-code merged PR 自动塞进来；title 以 fix/feat/hotfix/perf/chore(release) 开头）。
趋势图上的竖虚线：深棕 = 手动 / 浅米 = 自动。
| 日期 (北京) | 标签 | 说明 | 来源 | 影响平台 |
| markers.json 为空 — 修复发布后添加一条以便对照效果 |
⑥ Lucky 充值漏斗 — 严格 lucky-only 口径
所有数字按 trade_no 限定到 lucky CC 客户端 emit 过的订单（不含 NewAPI 网页直充等）。
主指标 = 昨天（NewAPI T+1 对齐）；趋势看 24h / 30d；订单明细含 install_id ↔ user_id 映射。
数据 10min cron 更新，
昨天 Lucky 主指标 (NewAPI T+1 对齐)
24h 小时趋势 (北京时间)
Lucky 小时收入 + 订单
绿色柱 = success 订单；橙色柱 = pending；黑色折线 = 转化率 %；蓝色折线 = 收入 ¥（右轴）。
按 lucky trade_no 过滤的 payment_events 行，北京时间整点聚合。
30 天日趋势
Lucky 每日收入 + 订单 + 转化率
每日按 lucky-only 口径展示 paid / pending 订单数、收入和转化率。fix-* marker 自动叠。
数据从 2026-05-30 (PR #238 部署) 起填充。
转化漏斗 (7d)
Client 5 stage → Paid (lucky-only orders)
Activation (首次 /v1/messages 成功) → Engagement (看 /billing) → Intent-A (看套餐) → Intent-B (生成二维码) → Paid (lucky trade_no 中 success 订单数)。
口径混合：client 5 stage 按 blob6 = CC install_id 去重（bridge mode 用户 NewAPI user_id=0 全 collapse，不能用 double1）；paid 末端按 trade_no success 订单数（order-level，非 user）。
最近 20 笔 Lucky 订单 (install_id ↔ user_id 映射)
客户端订单明细
按 client 创建时间倒序。status=waiting_truth 表示 truth 流（NewAPI 5min cron）还没轮到 / 用户刚下单。
install_id 是 CC 端 64-hex；user_id 是 NewAPI int —— 通过 trade_no 关联。
web_traffic.json 未就绪（CF AE 配置缺失或上一次抓取失败），等待下一轮 cron 生成（每 10 分钟）。
claude-zh.cn 官网真人访问流量（pageview beacon → CF Analytics Engine web_traffic）。
PV = 页面浏览数，UV = 去重访客（localStorage 匿名 ID）。已剔除 bot/爬虫与测试探针。
时区：北京时间 UTC+8。
24h 小时趋势（北京时间）
PV / UV 每小时；空桶填 0。
来源类型分布（7d）
search=搜索引擎 / social=社交媒体 / direct=直接访问 / internal=站内跳转 / external=其他外链。
每日 PV / UV 趋势（最近 30 天）
柱 = PV，线 = UV。看增长大盘与异常尖峰。
热门页面 top（7d，按 PV）
哪些页面最被看。安装引导页应是大头；某 guide 异常高/低提示内容或 SEO 机会。
来源域名 top（7d）
外链来源主机（不含 direct/站内）。看哪个搜索引擎/社区在导流。
新 vs 回访（7d，UV）
new=首访发生在本窗口。