从用户第一次访问到付费留存，分 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 事件）。
阶段详细
③ 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%需优化用户体验。
收入趋势（最近30天）
累计收入反映商业化效果。关注收入增长率和ARPU（人均收入）的变化，评估定价策略的有效性。
新用户转化率分析
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。
① 诊断摘要
② 流量全景（桑基图）
从 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 数据未拉取。
真实安装成功率（最近 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 为空 — 修复发布后添加一条以便对照效果 |