/validate-data - 在分享前驗證分析

如果您看到不熟悉的佔位符號或需要檢查已連接哪些工具，請參閱 CONNECTORS.md。

在與利害關係人分享分析結果之前，審閱其準確性、方法論和潛在偏差。生成信心評估與改進建議。

使用方式

/validate-data <要審閱的分析內容>

分析的內容可以是：

對話中的文件或報告
檔案（Markdown、筆記本、試算表）
SQL 查詢與其結果
圖表及其底層數據
方法論與研究發現的描述

工作流程

1. 審閱方法論與假設

檢查：

問題框架：分析是否回答了正確的問題？問題能否以不同方式解讀？
數據選擇：是否使用了正確的資料表/資料集？時間範圍是否合適？
族群定義：分析的族群是否正確定義？是否存在無意的排除？
指標定義：指標是否定義清晰且一致？它們是否符合利害關係人的理解方式？
基準與比較：比較是否公平？時間區間、同類群組規模與背景是否可比？

2. 執行交付前 QA 核對清單

逐步檢查以下清單——數據品質、計算、合理性與呈現方式檢查。

3. 檢查常見分析陷阱

針對下方詳細的陷阱目錄進行系統性審查（Join Explosion、倖存者偏誤、不完整期間比較、分母漂移、平均值的平均、時區不一致、選擇性偏誤）。

4. 驗證計算與彙總

在可能的情況下，進行抽驗：

獨立重新計算幾個關鍵數字
驗證小計是否加總等於總計
檢查百分比是否如預期加總為 100%（或接近）
確認年增率/月增率的比較使用了正確的基準期間
驗證篩選條件是否一致地應用於所有指標

套用下方結果合理性檢查技術（量級檢查、交叉驗證、紅旗偵測）。

5. 評估視覺化

如果分析包含圖表：

軸線是否從適當的值開始（長條圖從零開始）？
比較圖表之間的尺度是否一致？
圖表標題是否準確描述圖表內容？
視覺化是否可能誤導快速瀏覽的讀者？
是否存在截斷軸線、不一致的區間或扭曲感知的 3D 效果？

6. 評估敘述與結論

審閱：

結論是否由所呈現的數據支持
是否承認了其他可能的解釋
不確定性是否已被適當地傳達
建議是否邏輯上遵循研究發現
信心水準是否與證據強度相符

7. 建議改進事項

提供具體、可執行的建議：

能夠強化結論的額外分析
應該註明的注意事項或限制
針對關鍵點更好的視覺化或呈現方式
利害關係人可能需要的缺失脈絡

8. 生成信心評估

分析結果依照三級量表評級：

可分享 -- 分析方法論健全、計算已驗證、注意事項已註明。有輕微改進建議，但無阻擋項目。

需附注意事項分享 -- 分析大致正確，但存在特定的限制或假設，必須向利害關係人說明。列出必要的注意事項。

需修正 -- 發現特定錯誤、方法論問題或缺失的分析，應在分享前處理。按優先順序列出所需的變更。

輸出格式

## 驗證報告

### 整體評估：[可分享 | 需附注意事項分享 | 需修正]

### 方法論審閱
[關於方法、數據選擇、定義的發現]

### 發現的問題
1. [嚴重性：高/中/低] [問題描述與影響]
2. ...

### 計算抽驗
- [指標]：[已驗證 / 發現不一致]
- ...

### 視覺化審閱
[圖表或視覺呈現的任何問題]

### 建議改進事項
1. [改進項目及其重要性]
2. ...

### 提供給利害關係人的必要注意事項
- [必須傳達的注意事項]
- ...

交付前 QA 核對清單

在與利害關係人分享任何分析之前，逐一檢查此清單。

數據品質檢查

來源驗證：已確認使用了哪些資料表/數據來源。它們對於這個問題是否正確？
時效性：數據對於分析來說足夠新。已記錄「截至」日期。
完整性：時間序列中沒有意外的缺口或遺漏的區段。
空值處理：已檢查關鍵欄位的空值率。空值已被適當處理（排除、填補或標記）。
重複資料刪除：已確認沒有因不良 JOIN 或重複的來源記錄而導致的重複計算。
篩選條件驗證：所有 WHERE 子句和篩選條件都是正確的。沒有無意的排除。

計算檢查

彙總邏輯：GROUP BY 包含所有非彙總欄位。彙總層級與分析粒度相符。
分母正確性：比率和百分比計算使用了正確的分母。分母不為零。
日期對齊：比較使用了相同長度的時間區間。部分期間已被排除或註明。
JOIN 正確性：JOIN 類型是適當的（INNER vs LEFT）。多對多 JOIN 未膨脹計數。
指標定義：指標與利害關係人的定義方式相符。任何偏差都已註明。
小計總和：各部分加總等於整體（如預期）。若不然，需解釋原因（例如，重疊）。

合理性檢查

量級：數字在合理範圍內。營收不為負數。百分比介於 0-100%。
趨勢連續性：時間序列中沒有無法解釋的跳躍或下降。
交叉比對：關鍵數字與其他已知來源（儀表板、先前報告、財務數據）相符。
數量級：總營收在正確的概估範圍內。用戶數與已知數據相符。
邊際案例：在邊界情況會發生什麼？空區段、零活動期間、新實體。

呈現檢查

圖表準確性：長條圖從零開始。軸線已標示。不同面板間的尺度一致。
數字格式：適當的精確度。一致的貨幣/百分比格式。需要的地方加上千分位分隔符號。
標題清晰度：標題說明洞見，而不僅僅是指標。指定了日期範圍。
注意事項透明度：已知限制和假設已被明確陳述。
可重現性：其他人可以根據所提供的文件重現此分析。

常見數據分析陷阱

Join Explosion

問題：多對多 JOIN 會默默地倍增資料列，導致計數和總和膨脹。

如何偵測：

-- 檢查 JOIN 前後的資料列數
SELECT COUNT(*) FROM table_a;  -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3,500 (喔喔)

如何預防：

在 JOIN 後務必檢查資料列數
如果計數增加，調查 JOIN 關係（它真的是 1:1 或 1:多嗎？）
在透過 JOIN 計算實體時，使用 COUNT(DISTINCT a.id) 而不是 COUNT(*)

倖存者偏誤

問題：只分析現存的實體，忽略了那些已被刪除、流失或失敗的。

例子：

分析「當前用戶」的行為，忽略了已流失的用戶
查看「使用我們產品的公司」，忽略了那些評估後離開的
研究「成功」結果的特性，而沒有納入「不成功」的

如何預防：在得出結論前，問「誰不在這個資料集中？」

不完整期間比較

問題：比較部分期間與完整期間。

例子：

「一月營收為 $500K，而十二月為 $800K」——但一月還沒結束
「本週註冊人數下降」——在星期三查看，並與一個完整的上一週比較

如何預防：總是篩選出完整的期間，或比較同一天/相同天數。

分母漂移

問題：分母在不同期間發生變化，使得比率無法比較。

例子：

轉換率改善，因為改變了計算「合格」用戶的方式
流失率改變，因為「活躍」的定義被更新了

如何預防：在所有比較期間使用一致的定義。記錄任何定義上的變更。

平均值的平均

問題：當群組大小不同時，對預先計算的平均值再取平均會得到錯誤的結果。

例子：

A 組：100 名用戶，平均營收 $50
B 組：10 名用戶，平均營收 $200
錯誤：平均值的平均 = ($50 + $200) / 2 = $125
正確：加權平均 = (100*$50 + 10*$200) / 110 = $63.64

如何預防：總是從原始數據進行彙總。不要對預先彙總的平均值取平均。

時區不一致

問題：不同的數據來源使用不同的時區，導致資料對齊錯誤。

例子：

事件時間戳使用 UTC，而用戶面向的日期使用本地時間
每日彙總使用了不同的截止時間

如何預防：在分析前將所有時間戳標準化為單一時區（建議使用 UTC）。記錄所使用的時區。

分割中的選擇性偏誤

問題：區段是根據你正在衡量的結果來定義的，造成了循環邏輯。

例子：

「完成入職引導的用戶有更高的留存率」——顯然，他們是自我選擇的
「高價值用戶產生更多營收」——他們正是因為產生營收才成為高價值用戶

如何預防：根據處理前的特徵（而非結果）來定義區段。

其他統計陷阱

辛普森悖論：當數據被彙總與細分時，趨勢可能反轉
將相關性呈現為因果關係，而無支持證據
樣本數過小導致不可靠的結論
離群值對平均值的影響過大（是否應該使用中位數？）
多重檢定 / 選擇性呈現顯著結果
事後諸葛偏誤：使用未來資訊解釋過去事件
選擇性時間範圍：偏向特定敘事

結果合理性檢查

量級檢查

對於分析中的任何關鍵數字，驗證其是否通過「嗅覺測試」：

指標類型	合理性檢查
用戶數	這與已知的 MAU/DAU 數字相符嗎？
營收	這與已知的 ARR 相比，量級是否正確？
轉換率	這是否介於 0% 和 100% 之間？它與儀表板數字相符嗎？
成長率	月增率超過 50% 是否合理，或者數據有問題？
平均值	考慮到您對分佈的了解，這個平均值合理嗎？
百分比	各區段的百分比加總是否約等於 100%？

交叉驗證技術

用兩種不同方式計算同一個指標，並驗證它們是否相符
抽驗個別記錄——挑選幾個特定的實體並手動追蹤其數據
與已知基準比較——與已發佈的儀表板、財務報告或先前的分析進行比對
反向推導——如果總營收是 X，那麼每位用戶營收乘以用戶數是否約等於 X？
邊界檢查——當你篩選到單日、單一用戶或單一分類時會發生什麼？這些微觀結果合理嗎？

需要調查的紅旗

任何週期對週期變化超過 50% 且無明顯原因的指標
計數或總和是精確的整數（表示可能存在篩選條件或預設值的問題）
比率恰好為 0% 或 100%（可能表示數據不完整）
結果完美地證實了假設（現實通常比較混亂）
跨時間區段或區段的相同值（表示查詢忽略了某個維度）

關於可重現性的文件標準

分析文件範本

每個重要的分析都應包含：

## 分析：[標題]

### 問題
[正在回答的具體問題]

### 數據來源
- 資料表：[schema.table_name]（截至 [日期]）
- 資料表：[schema.other_table]（截至 [日期]）
- 檔案：[檔案名稱]（來源：[來自何處]）

### 定義
- [指標 A]：[確切的計算方式]
- [區段 X]：[確定的成員資格判定方式]
- [時間區間]：[開始日期] 至 [結束日期]，[時區]

### 方法論
1. [分析方法的步驟 1]
2. [步驟 2]
3. [步驟 3]

### 假設與限制
- [假設 1 及其合理原因]
- [限制 1 及其對結論的潛在影響]

### 關鍵發現
1. [發現 1 及支持證據]
2. [發現 2 及支持證據]

### SQL 查詢
[所有使用的查詢，附註解]

### 注意事項
- [讀者在據此採取行動前應了解的事項]

程式碼文件

對於任何可能被重複使用的程式碼（SQL, Python）：

"""
分析：每月同類群組留存
作者：[姓名]
日期：[日期]
數據來源：events 表, users 表
最後驗證日期：[日期] -- 結果與儀表板在 2% 內相符

目的：
    根據首次活動日期計算每月用戶留存同類群組。

假設：
    - 「活躍」定義為在該月內至少有一個事件
    - 排除測試/內部帳戶 (user_type != 'internal')
    - 全程使用 UTC 日期

輸出：
    留存同類群組矩陣，行為 cohort_month 欄為 months_since_signup。
    值為留存率 (0-100%)。
"""

分析版本控制

將查詢和程式碼保存在版本控制系統（git）或共享文件系統中
記錄所使用的數據快照日期
如果分析使用更新的數據重新執行，記錄變更了什麼以及原因
連結到週期性分析的先前版本，以便進行趨勢比較

範例

/validate-data 在我發送給高階主管團隊之前，審閱這份季度營收分析：[分析內容]

在你喜歡的 AI 中提問

說明文件