GA4 BigQuery 漏斗分析：自訂 SQL 查詢步驟與序列深度解析

爲何需要 BigQuery？GA4 漏斗探索報告的 3 個關鍵限制

GA4 的漏斗探索報告爲快速檢視使用者流程提供了便利，但其設計邏輯與功能範疇存在幾個關鍵限制，使得深度的漏斗與序列分析變得困難。當你需要解答關於使用者「如何」與「爲何」流失的複雜問題時，僅依賴 GA4 介面可能會遇到瓶頸。

爲什麼 GA4 漏斗報告有時「不準」？

GA4 漏斗探索報告的運作機制，導致它在某些情境下無法提供完全符合預期的分析結果。理解這些限制，是判斷是否需要轉向 BigQuery 的第一步：

• 序列計數邏輯限制： GA4 漏斗報告通常以「包含」邏輯計算完成每個步驟的使用者。這意味着，如果一名使用者在報告期間內完成了序列 A，後來又完成了序列 B，他可能會被重複計入。報告難以靈活定義「一次完成」的條件，也無法輕鬆剔除重複計數。
• 步驟定義與時間窗口的剛性： 你無法在介面上自由定義「跳過某些步驟」或「必須按嚴格順序」的漏斗規則。同時，步驟之間允許的時間間隔通常是固定的（例如，全部步驟必須在 30 分鐘內完成），難以根據不同商業流程（如長週期的購買決策）進行調整。
• 分析維度的深度不足： GA4 漏斗探索主要提供使用者層級的聚合視圖。要同時分析「漏斗步驟」與「商品屬性」（如商品類別、價格區間）或「使用者屬性」（如地區、新舊訪客）的交叉流失情況，介面提供的選項非常有限，無法滿足細粒度的診斷需求。

這些限制的根本原因在於，GA4 報表呈現的是經過預計算和聚合的「結果」。當你需要追溯原始事件、自訂序列定義或進行多維度交叉分析時，就需要能直接處理原始事件資料的工具。

核心概念：BigQuery 如何補足 GA4 的漏斗分析缺口？

BigQuery 的核心價值在於提供「未取樣的原始事件資料」與「高度靈活的自訂查詢能力」。它讓你能繞過 GA4 報表的聚合邏輯，直接從基礎的事件流中，用 SQL 語言重新定義你想要分析的任何漏斗與路徑。

匯出至 BigQuery 的資料，與我在 GA4 後臺看到的有何不同？

理解兩者資料性質的差異，是掌握 BigQuery 分析能力的關鍵。GA4 後臺報表看到的是處理後的聚合資料，而 BigQuery 匯出的是原始事件流。關於 GA4 原始事件資料的基礎分析概念，可參考 GA4 BigQuery 能做什麼？原始事件資料分析與報差異。

• 原始事件 vs. 報表聚合： GA4 介面爲了報錶速度與易讀性，會對資料進行取樣、彙總與預計算。而匯出至 BigQuery 的資料，是每日或串流匯入的原始事件記錄，每一條記錄代表一個特定時間點發生的特定事件（如 page_view、purchase）。
• 查詢靈活性： 在 BigQuery 中，你可以使用完整的 SQL 語法。這意味著你能自訂漏斗步驟的順序、爲每個步驟設定獨立的時間窗口、加入複雜的條件（例如，使用者必須來自特定廣告活動），甚至將漏斗分析與來自其他系統的資料（如 CRM、廣告平臺）進行結合。
• 教學範圍定位： 本文將聚焦於如何將 GA4 介面中常見的漏斗概念，轉換爲可在 BigQuery 中執行的 SQL 查詢。我們將從基礎的漏斗步驟定義開始，逐步進入更復雜的分析場景。

前置步驟：確保你的 GA4 資料已匯出至 BigQuery

在開始任何 SQL 分析前，必須先完成 GA4 到 BigQuery 的資料匯出設定。這是所有後續操作的基礎，確保你能取得分析所需的原始事件資料。

如何在 BigQuery 中找到你的事件資料？

設定匯出後，你的 GA4 資料會以特定格式儲存在 BigQuery 資料集中。熟悉這個結構是編寫有效查詢的前提。詳細的資料表結構說明，請參閱 GA4 BigQuery 資料表結構解析：欄位命名與三層架構。

1. 啓用 BigQuery Export： 在 GA4 管理介面中，前往「資料串流」，選擇你的資料串流，然後點選「BigQuery 連結」進行設定。你需要有 Google Cloud Platform 的專案，並擁有對 BigQuery 的寫入權限。
2. 識別資料表結構： 匯出後，你會在 BigQuery 中找到一個以 analytics_ 開頭、後跟數字的資料集。核心事件資料儲存在每日分割的資料表中，命名爲 events_YYYYMMDD。每張資料表的 schema 是固定的，包含 event_name、event_timestamp、user_pseudo_id 等關鍵欄位。
3. 理解匯出延遲： GA4 提供兩種匯出模式：「每日批次匯出」通常會在隔天完成前一天的資料匯出；「串流匯出」則近乎即時地將事件送入 BigQuery，但可能有幾分鐘的延遲。匯出模式的選擇，會影響你分析的資料時效性，但無論哪種模式，都不影響 GA4 後臺本身的報表運作。

實戰：用 SQL 建立你的第一個 BigQuery 漏斗分析

有了原始事件資料，我們就可以用 SQL 來定義漏斗。核心邏輯是：爲每個漏斗步驟標記事件，並確保這些事件由同一使用者在指定時間窗口內按序發生。

漏斗 SQL 的核心邏輯：如何用 WITH 語句定義每個步驟？

使用 SQL 的 Common Table Expression (CTE) 或子查詢，可以清晰地將每個漏斗步驟定義爲獨立的臨時資料集，最後再進行關聯計算。關於基礎的 SQL 語法與巢狀欄位處理，建議先閱讀 GA4 BigQuery SQL 查詢：基礎語法與巢狀欄位處理實戰。

一個基礎漏斗的 SQL 架構通常包含以下步驟：

1. 定義步驟： 爲每個漏斗步驟創建 CTE，使用 event_name 進行篩選，並記錄事件發生的 user_pseudo_id 和時間戳。
2. 序列關聯： 將各個步驟的 CTE 通過使用者 ID 進行關聯，並檢查事件發生的時間順序與間隔是否符合你定義的漏斗規則（例如，步驟二必須在步驟一之後發生）。
3. 聚合計算： 計算通過每個步驟的獨立使用者數量，並以此爲基礎計算轉換率。

以下爲一個概念性的 SQL 範例片段，展示如何定義並計算一個簡單的三步驟漏斗：

-- 僞代碼：定義漏斗步驟
WITH step1 AS (
  SELECT user_pseudo_id, MIN(event_timestamp) AS step1_time
  FROM `your-project.analytics_XXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20231001' AND '20231031'
    AND event_name = 'page_view' AND (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_title') = '產品首頁'
  GROUP BY user_pseudo_id
),
step2 AS (
  SELECT user_pseudo_id, MIN(event_timestamp) AS step2_time
  FROM `your-project.analytics_XXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20231001' AND '20231031'
    AND event_name = 'add_to_cart'
  GROUP BY user_pseudo_id
),
step3 AS (
  SELECT user_pseudo_id, MIN(event_timestamp) AS step3_time
  FROM `your-project.analytics_XXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20231001' AND '20231031'
    AND event_name = 'purchase'
  GROUP BY user_pseudo_id
)
-- 關聯步驟並計算
SELECT
  COUNT(DISTINCT s1.user_pseudo_id) AS step1_users,
  COUNT(DISTINCT s2.user_pseudo_id) AS step2_users,
  COUNT(DISTINCT s3.user_pseudo_id) AS step3_users
FROM step1 AS s1
LEFT JOIN step2 AS s2 ON s1.user_pseudo_id = s2.user_pseudo_id AND s2.step2_time > s1.step1_time
LEFT JOIN step3 AS s3 ON s2.user_pseudo_id = s3.user_pseudo_id AND s3.step3_time > s2.step2_time;

這段查詢篩選了特定日期範圍內的事件，定義了三個步驟，並計算了完成每一步的獨立使用者數。在實際應用中，你需要根據自身的事件名稱、頁面標題和業務邏輯調整 WHERE 條件。

進階應用：深入商品層級的漏斗流失分析

超越基礎的人數統計，BigQuery 的真正威力在於能深入分析「使用者在哪個商品上流失」。這需要處理 GA4 中常見的巢狀欄位結構。

GA4 介面很難同時呈現「使用者的漏斗路徑」與「他們所瀏覽的具體商品屬性」。而在 BigQuery 中，你可以透過展開 event_params 欄位來取得這些巢狀資料。

以下是一個概念性的 SQL 概念範例，說明如何將漏斗步驟與商品 ID 結合：

-- 概念範例：結合商品資訊的漏斗
WITH product_view AS (
  SELECT
    user_pseudo_id,
    event_timestamp,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'item_id') AS product_id
  FROM `your-project.analytics_XXXXX.events_*`
  WHERE event_name = 'view_item'
),
add_to_cart AS (
  SELECT
    user_pseudo_id,
    event_timestamp,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'item_id') AS product_id
  FROM `your-project.analytics_XXXXX.events_*`
  WHERE event_name = 'add_to_cart'
)
SELECT
  pv.product_id,
  COUNT(DISTINCT pv.user_pseudo_id) AS viewed_users,
  COUNT(DISTINCT atc.user_pseudo_id) AS added_users
FROM product_view AS pv
LEFT JOIN add_to_cart AS atc
  ON pv.user_pseudo_id = atc.user_pseudo_id
  AND pv.product_id = atc.product_id  -- 確保是同一個商品
  AND atc.event_timestamp > pv.event_timestamp
GROUP BY pv.product_id
ORDER BY added_users DESC;

這個查詢可以識別出哪些商品的瀏覽量高但加入購物車的比例低，從而揭示商品詳情頁可能存在的問題。你可以進一步擴展，加入購買步驟，或根據商品類別進行聚合分析。

結果驗證：如何比對 GA4 報表與 BigQuery 查詢結果？

使用兩種工具分析同一段資料時，結果可能會出現差異。理解差異來源並進行驗證，是確保分析可信度的重要環節。

爲什麼我的 GA4 報表人數與 BigQuery 查詢結果不同？

數字不一致通常不是錯誤，而是由工具的設計原理與資料處理方式不同所導致。以下是常見的差異來源：

• 取樣： 當 GA4 報表需要處理大量資料時，爲了提升響應速度，可能會使用部分樣本資料進行估算。而 BigQuery 查詢的是全量原始資料，結果是精確的。
• 身分識別模式： GA4 在報表中可能會混合使用 User-ID、Google Signals 與設備 ID 來識別使用者，並嘗試進行跨設備整合。你在 BigQuery 中查詢時，可以明確選擇使用 user_pseudo_id（設備層級 ID）或 user_id（如果已設定），這兩種方式的統計口徑可能不同。
• 資料匯出延遲： 特別是使用每日批次匯出時，BigQuery 中的資料可能比 GA4 介面中顯示的資料晚一天。進行比對時，需確保兩者查詢的時間範圍完全一致。
• 事件處理邏輯： 某些 GA4 功能（如自動增強型衡量、電子商務事件）的資料在進入報表前，可能經過額外的處理或校驗，這與直接匯出至 BigQuery 的原始事件可能略有不同。

一個簡單的驗證思路是：從 BigQuery 查詢結果中隨機抽樣幾個 user_pseudo_id，然後在 GA4 的「使用者探索」或「Raw Data」報表中，查看這些特定使用者的原始事件序列，手動覈對關鍵事件是否與查詢中的篩選條件一致。

我該用 GA4 介面還是 BigQuery？分析場景決策指南

GA4 漏斗探索與 BigQuery SQL 分析並非取代關係，而是互補工具。選擇哪一個，取決於你的分析目標、技術資源與對資料精確度的要求。

哪些分析需求，讓 BigQuery 成爲更優選擇？

根據分析需求的複雜性、定製化程度與資料量，你可以做出更合適的工具選擇。下表總結了關鍵差異：

簡單來說，當你需要快速獲得標準漏斗概覽、進行非技術性的團隊溝通，或資料量較小且分析需求常規時，GA4 介面是更高效的選擇。

反之，當你面臨需要高度客製化的序列分析（如複雜的電商購物流程）、必須處理海量原始資料而避免取樣誤差、需要結合其他資料源（如廣告花費、CRM 資料）進行歸因分析，或需要導出精細分析結果用於內部系統時，BigQuery SQL 就是更強大且必要的工具。

將兩者結合使用是常見且高效的實踐：用 GA4 漏斗探索進行日常監控與快速假設，當發現需要深入探究時，再用 BigQuery 進行嚴謹的驗證與診斷。