Vivi 怎么知道自己活得好不好：北极星 = 日消息量；三层告警（基础设施 / 应用异常 / 业务指标）；DailyLoop 每天自动跑一轮分析推 Lark + 写 Bitable。这一页讲清楚每个工具的分工，PM 看完就能直接用 dashboard。
消息量直接反映用户真实粘性 · DAU 只说明用户打开了 App，不代表互动 · 已并入 daily_monitor，每日 Lark 卡片同步
conversations / transactions 表查的就别加新事件。
不同性质的故障走不同通道，避免单点失效：
HTTP monitor 拨测 /health（间隔 1 min），失败立即推 Lark Vivi-Bot 红色卡片 + @野荞。Heartbeat 监 DailyLoop 是否如期跑完。
SDK 捕获 unhandled exception，issue alert 配 webhook → Lark 红色卡片 + @野荞。SDK 条件初始化（SENTRY_DSN 存在才激活）。
每天 09:00 + 10:00 自动跑两条 GHA workflow，写 Bitable 五张表，向多个 Lark 群推卡片。这是 PM 最常看的产出。
另外还有 UptimeRobot（独立冗余）每 5 分钟邮件告警，和 Microsoft Clarity（前端录屏 + 热图，无告警，按需查）。
Better Stack 拉的 /health 不是简单 200，而是依次探四个依赖：
每探 2s 单超时，5s 总硬上限。任一失败 → 503 + errors[]。Better Stack 只要看到 503 就 fire 告警。
DailyLoop 是 Vivi 的"每日自动化产品 Office"。每天两条 GHA workflow 串行触发：
09:00 UTC clarity_report.yml → Clarity Dashboard API → Bitable 表二（用户行为）
10:00 UTC daily_monitor.yml → 四阶段分析 → Bitable 五表 + Lark 卡片 + Remote Trigger 开 PR
并行拉 Adsgram + Clarity MCP + PostHog 三个数据源
generate_product_requirements() 交叉分析 → 触发 REQ-XX 列表
generate_code_prompts() → 含文件路径的 Claude Code 可执行 prompt
Bitable 五表写入 + Lark 卡片 + Remote Trigger 开 PR
| REQ ID | 触发条件 | 类型 | 含 code prompt |
|---|---|---|---|
REQ-FUNNEL-01 | 转化率 < 50% | 前端优化 | ✅ |
REQ-UX-01 | Dead click > 5% 或 Rage click > 2% | 前端优化 | ✅ |
REQ-PAY-01 | 付费转化率 < 30% | 前端优化 | ✅ |
REQ-PAY-02 | 0 次付费点击 且 用户 > 10 | 前端优化 | ✅ |
REQ-MOBILE-01 | Mobile 占比 < 50% | 前端优化 | ✅ |
REQ-PERF-01 | Script Error > 1% | 前端优化 | ✅ |
REQ-PERF-02 | 活跃时间比 < 50% | 前端优化 | ✅ |
REQ-ADS-01 | Adsgram 余额 ≤ 0 或 < 5 | 运营动作 | — |
REQ-ADS-02 | CTR < 0.8% | 运营动作 | — |
REQ-CHAR-01 | Top 角色占 > 50% 流量 | 运营动作 | — |
REQ-GROWTH-01 | 日活 < 10 | 运营动作 | — |
Base 名"Vivi 产品自动化"，已开放组织内可编辑，bot 可读写。每张表都按日期降序默认视图：
| 序号 | 表名 | 数据源 | 用途 |
|---|---|---|---|
| 一 | 广告投放 | Adsgram | 每日投放数据 / CTR / 余额 |
| 二 | 用户行为 | Clarity Dashboard API | 设备 / 国家 / dead click / rage click |
| 三 | 付费漏斗 | PostHog TrendsQuery | 各档转化率 / 付费用户数 |
| 四 | 产品需求点 | AI 交叉分析 | 触发的 REQ-XX 列表 + 数据依据 |
| 五 | 代码提示词 | 需求 → Claude Code prompt | 含文件路径的可执行 prompt |
访问入口（Lark 内）：Vivi 产品自动化 Base。
不同性质的消息推不同 Bot，避免噪音淹没重要告警：
msg_type: "interactive"），不要用纯文本或 post 格式。@提醒只 @野荞（open_id 239e82d1），不要 @all。表格信息要么用 column_set 多列布局，要么不展示 —— Lark 不渲染 Markdown 表格。
前端埋点事件名 与 监控脚本查询名 必须 100% 对齐，否则永久返回 0：
| 事件名 | 触发位置 | 关键属性 |
|---|---|---|
plan_subscribe | 订阅页档位点击 | tier, package_id |
gems_purchase_click | Gems 商店档位点击 | package_id, gems |
invoice_callback | tg.openInvoice 回调 | status (paid / cancelled / failed) |
energy_exhausted | 能量耗尽 popup 弹出 | messages_in_session |
image_request | 📷 按钮点击 | char_name, story_id |
image_complete | 生图完成 | duration_ms, char_name |
image_error | 生图失败 | error_type, char_name |
locked_character_click | 付费锁角色点击 | char_name |
paywall_shown | 付费墙曝光 | messages_in_session |
session_end | 会话关闭（含 sendBeacon） | duration, messages |
content / 消息正文（NSFW 合规），只传 message_length / message_indexchar_name，让 PM 能识别哪个角色带来转化identify() 调用时携带 subscription_tier / gems_balance / energy / total_messages_sent，解锁分群能力用户在 Telegram WebView 里大量装广告拦截器，PostHog 直连容易丢事件。Vivi 做了三层兜底：
api_host = vividreams.fly.dev/phog，后端 app/api/posthog_proxy.py 转发到真实 PostHog。绕过 ISP/DNS 拦截。Analytics.track() 双发到后端 /api/events，后端用 posthog-python SDK 转发。事件带 $source: "server" 标记。没用 Langfuse —— 因为 NSFW 数据流经第三方有合规风险，且 Prompt 架构稳定不需要 trace 调试。当前实现：
app/llm/openrouter.py 的 LLMMetrics dataclass 追踪 model / tokens_in / tokens_out / latency_ms / is_fallbackroutes.py 的 _track_llm_metrics() 把每次调用打 llm_request 事件到 PostHog录屏 + 热图 + Dashboard API：
list-session-recordings、query-analytics-dashboard| 看什么 | 去哪 |
|---|---|
| 北极星 / 日消息量 | Daily Lark 卡片 (Vivi-PM 群) |
| 付费漏斗 / 转化率 | PostHog Project 377981 → Funnel Insight |
| 角色流量 Top N | PostHog → Trends 按 char_name 分组 |
| 生图失败率 | PostHog → image_error 事件率 |
| 用户行为录屏 | Microsoft Clarity Dashboard |
| 异常报错 | Sentry → vividreams 项目 |
| 服务可用性 | Better Stack 拨测页 |
| 每日营收 | Admin Dashboard / Daily Lark 卡片 |
| 需求列表 / 代码 prompt | Bitable 五表（Vivi 产品自动化） |