讀時間： 約 6 分鐘 · 系列： 業務與運營實踐 · 上一步： 怎麼審 Plan · 下一步： Report 轉 HTML
Report 出來了，你要看什麼
Execute 完成後，分析師會交付 Report。你的任務不是挑 SQL 語法，而是判斷：這份 Report 能不能支持你要做的決策、有沒有誠實說明限制。
驗收四項
| 檢查項 | 合格長相 | 不合格長相 |
|---|---|---|
| 具體數字 | 「1,623 單，占 1.63%」 | 「某階段流失較嚴重」 |
| 定義可追溯 | stage / 分母在 Report 有寫 | 只有結論、沒有定義 |
| limitations | 明說資料缺什麼、假設是什麼 | 完全沒寫限制 |
| 因果謹慎 | 區分相關與因果 | 直接寫「A 導致 B」 |
漏斗類分析還應有 最大流失 stage 與 各 stage counts / rates（見 USER_GUIDE §2.7）。
用 Compare view 對照 Plan（建議）
驗收 Report 時，可將同專案 Plan 開入 Compare view，與主視窗 Report 並列對照口徑與數字。Compare view 內批註唯讀，但可 View changes 檢視已 Resolve 批註的修改對照。操作見 USER_GUIDE §11.10 與 分析師：Plan 流程。
若 Report 由外部 Agent 協作產生，最低驗收仍是同一份已核准 Plan、正式 SQL evidence、具體數字與 limitations。請分析師再用 External MCP Activity 說明哪些 artifacts 被修改；外部聊天中的「已完成」不能取代這些證據。需要了解連線與 Activity 邊界時，讀 外部 Agent Integration。
limitations 怎麼讀
limitations（限制與注意事項）不是推卸責任，而是告訴你 這個數不能拿來做什麼。常見內容：
- 資料未含退款、部分渠道延遲入庫
- 樣本期太短、活動期與平日不可比
- 相關性分析，不能當因果結論
若 limitations 與你的決策風險相衝（例如你要對外宣稱 GMV，但 Report 寫未扣退款），應 退回要求新 Plan 重跑，而不是只改 Report 措辭。
批註 Report vs 要求重跑
| 情況 | 建議做法 |
|---|---|
| 用詞、排版、補充業務背景 | 在 Report 上批註，請 Agent 修訂措辭 |
| 口徑錯了（分母、stage、時間窗） | 新 Plan，重新 Execute |
| 數字缺關鍵維度（例如沒按渠道拆） | 新 Plan 或同專案 follow-up Plan |
你現在可以做的一件事
打開最近一版 Report，先找 limitations 段落：若沒有或過於空泛，批註請分析師補上「資料未涵蓋什麼、假設是什麼」。