GA4 BigQuery 資料品質檢查：確保分析基礎準確的 4 大核心維度

為什麼要在 BigQuery 檢查 GA4 資料品質？（效益與前提）

GA4 串接 BigQuery 的核心價值，在於將原始事件資料完整保存，突破 GA4 介面僅保留 14 個月資料的限制。這份原始資料是後續所有分析的基礎，其品質直接決定了洞察的可信度與決策的品質。若資料本身有誤，後續的視覺化與模型預測也難以產出可靠結果，因此從源頭建立檢查機制至關重要。

根據媒體報導，GA4 串接 BigQuery 提供一定額度的免費儲存與查詢空間。然而，這項免費額度並非無限，當資料量因異常事件（例如機器人流量暴衝）而急遽成長時，將可能加速消耗免費額度，甚至衍生額外的成本。這種情況不僅影響分析的正確性，也會反映在帳單上。因此，主動檢查資料品質，確保進入 BigQuery 的是乾淨、有效的資料，是控制成本、讓每一分分析資源都花在刀口上的關鍵。

若能先建立「原始資料可能藏有雜訊」的認知，便能在後續分析流程中更謹慎地看待資料。關於原始事件資料在分析上的更多可能性，可參考GA4 BigQuery 原始事件資料分析與報表差異一文，瞭解其在精細化分析上的潛力。

評估 GA4 資料品質的 4 大核心維度

要系統性地檢查 GA4 資料品質，可以從四個核心維度建立評估框架：完整性、準確性、一致性與唯一性。這四個維度能協助你快速定位問題，判斷資料是否可信賴。

完整性：欄位是否有遺漏？

完整性關注的是「資料缺了什麼」。最常見的檢查是特定欄位的空值比例，例如 user_id 若有大量空值，代表許多事件無法與已登入的使用者綁定，這將影響跨裝置的使用者分析，甚至無法正確計算使用者生命週期價值（LTV）。此外，事件參數的遺漏也屬於此範疇。例如，電子商務事件 purchase 若缺少 value 參數，收益數據便不完整，所有與營收相關的報表都會失真。

準確性：欄位數值是否合理？

準確性評估的是「數值是否正確」。以 event_value 為例，一筆購買金額為 1,000 元的事件，若在 event_value 欄位中被記錄為 100 或 1,000,000，這筆交易不僅會影響平均訂單價值的計算，也可能在數據匯出後，造成自訂報表或機器學習模型的誤判。除了數值範圍，格式正確性也是準確性的一環，例如日期格式是否統一、貨幣代碼是否一致等。

一致性：跨平臺的事件定義是否統一？

一致性著重於資料的「定義與結構是否統一」。在 Web 與 App 並行的情況下，最常見的品質問題是同一事件（例如 sign_up）在網頁版與行動版的事件名稱、參數命名或結構不相同。Web 版可能命名為 sign_up，而 App 版可能命名為 signup 或 register。這會導致後續的合併分析無法有效彙整，路徑分析與漏斗分析也會出現斷點，無法呈現真實的用戶旅程。

唯一性：事件是否被重複記錄？

唯一性要求資料「每筆事件都獨一無二」。網路不穩定或用戶快速多次點擊按鈕，都可能導致 SDK 重複發送相同的事件資料。重複的事件會讓所有事件計數指標（如頁面瀏覽次數、按鈕點擊次數）虛增，直接污染流量分析與行銷成效評估。

這四個維度是相互關聯的。例如，user_id 空值率高可能代表埋點不完整（完整性），也可能是不同版本的事件追蹤程式碼設定不一致（一致性）所導致。若想深入理解 GA4 資料表的欄位結構，以便更精確地檢查這些維度，可參考GA4 BigQuery 資料表結構解析：欄位命名與三層架構。

BigQuery 中常見的 GA4 資料品質問題

以下列出從 GA4 匯入 BigQuery 後最常見的幾種資料品質問題，你可以將此作為初步檢查的清單，快速比對自身資料是否出現相同狀況。

• 事件重複記錄：因用戶快速多次點擊、頁面重新整理或網路重傳，導致同一事件被多次寫入資料表。這會影響所有事件計數與使用者行為路徑的正確性。
• 關鍵欄位空值率過高：例如 user_pseudo_id 或自訂參數（如 product_id）出現大量空值。若 user_id 的整合不完整，將導致跨裝置分析無法串聯；若產品 ID 遺漏，則產品成效與銷售分析將無法進行。
• 時間戳記異常：事件時間（event_timestamp）出現跳躍式差異，例如某事件的時間與其他事件相比，提前或延後了數小時。這可能是裝置本地時間設定錯誤或閏秒補償機制所造成的，會嚴重幹擾依賴時間順序的漏斗分析與使用者旅程還原。
• 事件架構不一致：同一個事件名稱在不同日期或不同平臺（Web/App）的參數結構不相同。例如，click_btn 事件，今天送出的參數名為 button_name，昨天卻命名為 btn_name。這類型態的問題會讓後續查詢維度時出現大量空值，甚至直接讓查詢無法運作。

這裡列出的清單並非窮舉，但若能針對上述情境進行例行檢查，已可涵蓋多數網站或應用程式常見的資料品質問題。接下來，將說明如何使用 SQL 在 BigQuery 中實際進行這些檢查。

實戰教學：使用 SQL 檢查你的 GA4 資料表

在 BigQuery 中檢查資料品質，最直接的方式就是撰寫 SQL 查詢。透過查詢 events_* 這類每日一張的資料表，你可以快速掌握資料的全貌。以下提供三個可直接套用的 SQL 範例。

SQL 範例 1：計算 user_id 欄位的空值比例

第一步，先確認資料表的基本資料量，再針對重要欄位進行空值檢查。user_id 是後方個人化分析與跨裝置追蹤的重要基礎，因此建議優先檢查。

-- 檢查 user_id 欄位的空值比例
SELECT
  COUNT(*) AS total_events,
  COUNTIF(user_id IS NULL OR user_id = '') AS events_without_user_id,
  SAFE_DIVIDE(COUNTIF(user_id IS NULL OR user_id = ''), COUNT(*)) * 100 AS null_percentage
FROM
  `your_project.your_dataset.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN '20240101' AND '20240107' -- 調整查詢日期範圍

-- 檢查 event_params 中特定參數（如 page_title）的遺漏情形（適用於巢狀結構）
SELECT
  COUNT(*) AS total_events,
  COUNTIF(page_title.value.string_value IS NULL) AS missing_page_title
FROM
  `your_project.your_dataset.events_*`,
  UNNEST(event_params) AS page_title
WHERE
  page_title.key = 'page_title'
  AND _TABLE_SUFFIX BETWEEN '20240101' AND '20240107'

這個查詢會回傳指定日期範圍內的事件總數、缺少 user_id 的事件數量，以及空值比例的百分比。透過這個數據，可以快速評估身分識別的資料是否健全。

SQL 範例 2：偵測重複事件的方法

重複事件的偵測，重點在於找出「看起來相同的紀錄」。一般會以 event_timestamp、event_name、user_pseudo_id 這三個欄位的組合做為判別基準。若這三欄都相同，極有可能是重複傳送的資料。

-- 找出可能重複的事件記錄（基於 event_timestamp、event_name、user_pseudo_id 組合）
SELECT
  event_date,
  event_timestamp,
  event_name,
  user_pseudo_id,
  COUNT(*) AS duplicate_count
FROM
  `your_project.your_dataset.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN '20240101' AND '20240107'
GROUP BY
  event_date,
  event_timestamp,
  event_name,
  user_pseudo_id
HAVING
  COUNT(*) > 1
ORDER BY
  duplicate_count DESC

執行上述查詢，若回傳的資料列數大於零，則代表這些條件組合下存在重複資料。從 duplicate_count 的數字可以瞭解重複的嚴重程度。若想進一步查看是哪一天的重複率最高，可將 event_date 加入查詢欄位進行分羣統計。

若你是 SQL 新手，對於 UNNEST 處理巢狀欄位等語法還不熟悉，建議先閱讀GA4 BigQuery SQL 查詢：基礎語法與巢狀欄位處理實戰，建立基礎後再回來執行上述檢查。

進階方案：利用 Dataplex 建立自動化品質掃描規則

手動執行 SQL 查詢適合用於一次性或不定期的檢查。然而，若要確保資料品質長期穩定，手動執行的效率就略顯不足。此時可以考慮使用 Google Cloud 的 Dataplex 服務，它提供資料剖析（Data Profiling）與資料品質（Data Quality）任務，能協助你建立自動化的監控機制。

何時需要設定自動化掃描？

當你的 GA4 資料具有以下特徵時，就建議導入自動化掃描：資料量大且每日持續穩定成長、資料表數量多需逐一檢查、分析團隊對於定期檢查的執行頻率與人力負擔難以負荷。此外，若你的資料會提供給多個部門或對外作為決策依據，建立可持續監控的自動化規則，也能確保健診的標準一致，並留下歷史軌跡供日後追溯。

設定 Dataplex 資料品質規則的步驟簡述

在 Dataplex 中建立品質檢查，大致可分為三個階段：建立資料品質規則、建立掃描任務、查看報告。

• 建立規則：在 Dataplex 的「資料品質」頁面中，可以為 BigQuery 資料表設定規則。規則包含內建的維度類型（如 Nullness、Uniqueness）或使用自訂 SQL 進行驗證。
• 建立掃描任務：設定規則後，建立一個掃描任務，指定要執行檢查的資料表範圍與執行時間排程（例如每日上午 9 點執行）。
• 查看報告：每次掃描完成後，Dataplex 會產生一份報告，顯示各規則的通過與失敗狀態。你可以設定失敗警示（如透過 Cloud Monitoring 通知），以便在第一時間掌握異常。

Dataplex 的設定介面能直接對應到前述提到的完整性（Nullness）、唯一性（Uniqueness）等維度，不需要撰寫程式碼，就能以圖形化方式建立規則，技術門檻較低。此方案特別適合需要定期監控資料品質、且希望減少人工介入的團隊。

當 GA4 報表顯示異常時，如何到 BigQuery 排查根本原因？

GA4 介面上的報表是經處理後的結果，而 BigQuery 存放的是原始的資料流。當兩者出現明顯差異或 GA4 報表指標異常時，到 BigQuery 查詢原始事件是找出問題根源的有效方式。以下列舉兩個常見的排查案例。

案例：從「轉換數」異常追溯到 BigQuery

假設 GA4 介面顯示某日轉換數突然暴增為平日的數倍，但行銷活動並無調整。此時，可直接到 BigQuery 查詢該日 purchase 事件（或你定義的轉換事件）的明細。透過 SQL 過濾出該事件的 event_timestamp、user_pseudo_id、event_value 等欄位，並依時間排序。若發現大量轉換事件集中在同一秒或同一分鐘內被記錄，且 event_value 重複，這極有可能是一次資料重複傳送的異常，而非真實的轉換。

案例：從「使用者數」差異追溯到 user_pseudo_id

當 GA4 介面的活躍使用者數與 BigQuery 中 user_pseudo_id 的去重計算數有出入時，可從資料表結構差異來解釋。GA4 介面可能會排除已知的機器人流量，而 BigQuery 的原始資料表中則包含了這部分資料。你可以撰寫 SQL，計算前後兩個日期區間中，user_pseudo_id 的去重數量，並比對 GA4 介面顯示的數字。同時，也檢查是否有特定 user_pseudo_id 在極短時間內（如數秒）產生了大量不同事件，這高度符合機器人行為的特徵。

若需要更深入的資料分析應用手法，可參考GA4 BigQuery 能做什麼？原始事件資料分析與報表差異一文，內含更多實際操作指引。

整體而言，檢查 GA4 BigQuery 資料品質，可視為確保數據分析可靠度的必要流程。雖然看似增加工作量，但長期而言，能大幅降低資料錯誤帶來的決策風險。下表整理了常見的檢查方法，方便你依自身需求選擇合適的執行方式。

檢查方法	適用情境	技術門檻	自動化能力
BigQuery SQL 手動查詢	一次性專案、針對特定問題進行深度調查、確認資料表欄位結構。	需具備 SQL 基礎	無，需人工操作
BigQuery SQL + 排程	有定期的檢查需求（如每週），但預算或人力有限，尚未導入進階工具。	需具備 SQL 與 BigQuery 排程操作知識	可透過 BigQuery 排程查詢（Scheduled Queries）自動執行，但需設定結果發送
Dataplex 自動化掃描	資料量大、需長期穩定監控品質的團隊，或希望建立集中化的資料治理流程。	熟悉 GCP 介面操作即可，無需撰寫 SQL	高度自動化，可設定掃描頻率並觸發警示

先從手動查詢著手，待熟悉常見的資料問題型態後，再逐步導入自動化監控，是比較平穩的推進方式。務必記得，檢查出問題後，應回到追蹤碼或事件設定端修正，避免同樣的問題持續發生。

Q: GA4 串接 BigQuery 後，資料是即時的嗎？這會影響品質檢查的時機嗎？

根據 BigQuery 資料串流導出的說明，資料會有近乎即時的延遲（通常在分鐘級）。品質檢查建議在資料穩定後（例如隔天）進行，以避免檢查到未完整匯入的資料。

Q: 我該多久檢查一次 BigQuery 中的 GA4 資料品質？

建議至少在數據架構變動（如新增事件、修改參數）、行銷活動高峯期後，或定期（如每週或每月）進行檢查。可透過 H2-6 提到的 Dataplex 或 SQL 排程來實現自動化。

Q: 除了 SQL，有沒有不寫程式碼就能檢查資料品質的方法？

有的。如 H2-6 所述，可以使用 Google Cloud 的 Dataplex 工具，它提供圖形化介面來設定資料品質規則與掃描，無需直接編寫 SQL。

Q: BigQuery 中的 GA4 資料和 GA4 介面報表的數字不同，是資料有問題嗎？

不一定完全代表「有問題」。兩者處理邏輯不同：BigQuery 是原始事件資料，GA4 介面是經處理、整合後的報表（可能包含取樣、歸因模型調整）。差異是正常的，但「異常的波動」或「邏輯矛盾」則需要像 H2-7 描述的那樣去排查。

Q: 檢查出資料品質問題後，我可以修正 BigQuery 裡的歷史資料嗎？

一般不直接修改原始匯入的 events_* 資料表。常見做法是建立一個「已清洗」的資料表或視圖，透過 SQL 查詢排除或修正已知的問題數據，再於分析時使用這個清洗後的版本。

Q: 「事件重複」是怎麼發生的？該如何用 SQL 偵測？

重複可能因用戶快速多次點擊、網路重傳等造成。偵測方法如 H2-5 所述，可嘗試找出 event_timestamp、event_name、user_pseudo_id 等欄位組合完全相同的記錄，再進行計數分析。