這篇定義什麼叫「可以拿去開會的數字」
Lantide 不要求形式上的華麗管線;它要求 Report 內容站得住腳。作為 PM,你可以在 Execute 前用下面清單把關,Execute 後用同一標準驗收。
Execute 前:Plan 必審項
在分析師按 Execute 之前,Plan 裡應能回答:
| 檢查項 | 問自己 |
|---|---|
| 目標 | 這份 Plan 要回答哪個決策問題? |
| 分母 | 轉化率 / 率的分子分母各是什麼?取消、退款、重複用戶怎麼處理? |
| 粒度 | 按訂單還是按用戶?會不會 join fan-out? |
| 時間窗 | 起訖日期、時區、是否含 partial day? |
| Stage 定義(漏斗類) | 每一階段篩選條件是否業務可理解? |
| Checkpoint | 有沒有「先驗再往下」的 sanity check? |
任一項含糊 → 批註澄清,不要 Execute。Execute 後改口徑成本更高。
草擬 Plan 後,Agent 也可能先用短問答幫分析師把分母/邊界寫進 Plan,再請你審——這不取代上表檢查,而是減少「看起來完整、其實假設未對齊」的情況。見 分析師:Plan 流程。
Execute 後:Report 驗收項
| 檢查項 | 合格長相 | 不合格長相 |
|---|---|---|
| 具體數字 | 「1,623 單,占 1.63%」 | 「某階段流失較嚴重」 |
| 定義可追溯 | stage / 分母在 Report 有寫 | 只有結論沒有定義 |
| limitations | 明說資料缺什麼、假設是什麼 | 完全沒寫限制 |
| 因果謹慎 | 區分相關與因果 | 直接寫「A 導致 B」 |
漏斗類分析還應有 最大流失 stage 與 各 stage counts / rates(見 USER_GUIDE §2.7)。
什麼不是品質底線
以下 不能 代替上面內容:
- SQL 拆了很多步
- 有血緣圖 / Source Run
- 對話很長、Agent 看起來很忙
- 產了 HTML 報告但數字空洞
這些可能是 加分,但不是「可以簽核」的最低標準。
團隊規範建議(可直接貼 wiki)
- 對外數字 必須來自 Executed 的 Plan 對應 Report
- Execute 前 PM 或指定 reviewer 批註過 Plan(小團隊可分析師自審 + 第二人 spot check)
- Quick 探索結果 預設 非正式,不得直接進財務或對外 PR
- Report limitations 必填;缺則退回修訂