GA4 進階實戰：用 BigQuery + Looker Studio 看出流量真相（含完整連線教學）

94%。 這是 GA4 免費版報表所能呈現的數據涵蓋率上限——剩下那 6%，藏著你的高價值用戶、異常流量來源、以及廣告預算正在被浪費的真相。Google 官方早就說清楚了：免費版 GA4 的探索報告預設只取 10 萬列樣本資料，流量一大，數字就開始偏移。你看到的「轉換率 3.2%」，可能在全量數據下只有 2.7%，差那 0.5 個百分點，對月預算百萬的廣告帳戶來說，是幾十萬台幣的決策誤差。

這篇不是 GA4 入門文。如果你還在摸熟基本報表，建議先看看GA4 入門完整指南，打好底再往下走。這篇要談的是：如何把 GA4 的原始資料導進 BigQuery，用 SQL 做自訂分析，再用 Looker Studio 建一個真正有用的儀表板。從連線到落地，完整教學。

為什麼 GA4 免費版報表不夠用：Sample 問題的真正代價

先說一個很多行銷人不知道的事：GA4 的探索（Explore）報表在流量超過門檻後會自動啟用抽樣。這個門檻不是固定的，會隨日期範圍、維度組合、事件量而變動。Google 自己的說明文件寫得很保守，但實務上，月 PV 超過 50 萬的網站，幾乎都會碰到抽樣問題。

有一個數字很值得注意——Measure School 的實測報告顯示，同一個電商網站的「結帳完成」轉換事件，在 GA4 探索報表看到的數字比 BigQuery 全量數據低了 8-12%，換算下來就是幾十筆訂單的差距。更可怕的是，抽樣偏差不是均勻分佈的——它傾向於低估小眾流量來源（例如部分聯盟行銷渠道、品牌字搜尋），而這些渠道通常轉換率最高。

GA4 連結 BigQuery：完整連線教學（含 GCP 設定）

好消息是：GA4 連接 BigQuery 這件事，Google 已經做得相當無縫。只要你有 Google Analytics 的編輯權限 + GCP 帳號，整個連線流程不需要寫一行程式碼。壞消息是：有幾個設定選項如果沒搞清楚，後面的分析會很難做。

步驟一：建立 GCP 專案與啟用 BigQuery API

前往 Google Cloud Console，建立一個新專案（建議命名清楚，例如 `ga4-analytics-prod`）。進入專案後，搜尋「BigQuery API」並啟用。這個步驟完成後，確認計費帳戶已綁定——沒有計費帳戶，BigQuery 的免費額度也無法使用。

步驟二：在 GA4 管理介面啟用 BigQuery 連結

在 GA4 管理介面（Admin）→ 產品連結（Product Links）→ BigQuery 連結，點「連結」開始設定。選擇你剛建立的 GCP 專案，接下來有幾個關鍵選項：

• 資料集位置：選擇離你用戶最近的區域。台灣流量為主建議選 asia-east1（台灣）或 asia-northeast1（日本）。一旦設定，日後無法更改，只能重建。
• 匯出頻率：「每日」或「串流（Streaming）」。串流可即時查看今天的數據，但費用較高（每百萬事件約 $0.05）。大多數場景選每日就夠了。
• 匯出表格類型：選「每日事件資料表」（`events_YYYYMMDD`）。這是最省成本的選項，也是大多數 SQL 分析的基礎。如果你需要即時數據，再另外開啟「事件內嵌」選項。

步驟三：確認資料已開始匯出

連結設定完成後，通常需要 24-48 小時才會看到第一批資料。在 BigQuery 的資料集下，你會看到 `events_YYYYMMDD` 格式的資料表（例如 `events_20260510`）。每個資料表代表當天的所有 GA4 事件。

BigQuery GA4 資料結構解析：events 表你一定要懂這幾個欄位

GA4 的 BigQuery 資料結構和傳統 GA（UA）完全不同。UA 時代是「session-based」，每一行代表一個 session；GA4 是「event-based」，每一行代表一個事件。這個改變讓資料更細緻，但也讓 SQL 查詢複雜了不少——尤其是 `event_params`、`user_properties`、`items` 這幾個欄位都是巢狀的 ARRAY 結構，第一次看到的人通常會愣住。

GA4 SQL 分析實戰：4 個解決真實問題的 BigQuery 查詢範例

光看資料結構沒有感覺，用場景來說。以下 4 個 SQL 查詢，都是在 GA4 標準報表做不到、但在 BigQuery 輕鬆解決的真實分析場景。

查詢一：去重後的真實轉換事件數（解決 GA4 重複計算問題）

GA4 的 purchase 事件有時因為用戶重新整理感謝頁、或網站端 GTM 設定問題，導致同一筆訂單被重複觸發。在 BigQuery，一行 SQL 就能去重：

-- 去重後的真實購買轉換數（按日期）
SELECT
  event_date,
  COUNT(DISTINCT
    (SELECT value.string_value
     FROM UNNEST(event_params)
     WHERE key = 'transaction_id')
  ) AS unique_purchases,
  COUNT(*) AS raw_event_count,
  COUNT(*) - COUNT(DISTINCT
    (SELECT value.string_value
     FROM UNNEST(event_params)
     WHERE key = 'transaction_id')
  ) AS duplicate_events
FROM `your_project.analytics_XXXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260401' AND '20260430'
  AND event_name = 'purchase'
GROUP BY event_date
ORDER BY event_date;

查詢二：Session 層級的渠道歸因（修正 GA4 first-touch 偏差）

GA4 的 `traffic_source` 是用戶層級的首次來源，不是 session 層級。如果你想知道每次 session 的流量來源（更接近廣告歸因的需求），要從 `session_start` 事件的 `event_params` 裡取 `session_source`：

-- Session 層級流量來源與轉換率
WITH sessions AS (
  SELECT
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'source') AS session_source,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'medium') AS session_medium
  FROM `your_project.analytics_XXXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260401' AND '20260430'
    AND event_name = 'session_start'
),
conversions AS (
  SELECT
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id
  FROM `your_project.analytics_XXXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260401' AND '20260430'
    AND event_name = 'purchase'
)
SELECT
  s.session_source,
  s.session_medium,
  COUNT(DISTINCT CONCAT(s.user_pseudo_id, s.session_id)) AS total_sessions,
  COUNT(DISTINCT CONCAT(c.user_pseudo_id, c.session_id)) AS converting_sessions,
  ROUND(
    COUNT(DISTINCT CONCAT(c.user_pseudo_id, c.session_id)) * 100.0 /
    COUNT(DISTINCT CONCAT(s.user_pseudo_id, s.session_id)), 2
  ) AS conversion_rate_pct
FROM sessions s
LEFT JOIN conversions c
  ON s.user_pseudo_id = c.user_pseudo_id
  AND s.session_id = c.session_id
GROUP BY s.session_source, s.session_medium
HAVING total_sessions > 100
ORDER BY converting_sessions DESC;

查詢三：自訂 Funnel 分析（GA4 無法做到的步驟自訂）

GA4 的探索漏斗分析最多只能做到 10 個步驟，且不能跨 session。BigQuery 讓你自由定義任何步驟組合：

-- 電商購買漏斗：瀏覽商品 → 加入購物車 → 結帳 → 購買
WITH funnel_events AS (
  SELECT
    user_pseudo_id,
    event_name,
    event_timestamp
  FROM `your_project.analytics_XXXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260401' AND '20260430'
    AND event_name IN ('view_item', 'add_to_cart', 'begin_checkout', 'purchase')
)
SELECT
  'view_item'      AS funnel_step, COUNT(DISTINCT user_pseudo_id) AS users FROM funnel_events WHERE event_name = 'view_item'
UNION ALL
SELECT 'add_to_cart',   COUNT(DISTINCT user_pseudo_id) FROM funnel_events WHERE event_name = 'add_to_cart'
UNION ALL
SELECT 'begin_checkout',COUNT(DISTINCT user_pseudo_id) FROM funnel_events WHERE event_name = 'begin_checkout'
UNION ALL
SELECT 'purchase',      COUNT(DISTINCT user_pseudo_id) FROM funnel_events WHERE event_name = 'purchase';

查詢四：用戶留存率分析（Cohort Analysis）

GA4 的留存報表只有 2 種預設指標，而且無法自訂「留存事件」的定義。在 BigQuery，你可以定義「在第 N 天有做 X 行為」作為留存標準：

-- 以首次 session 日期為 Cohort，追蹤 Day 7 留存率
WITH first_seen AS (
  SELECT
    user_pseudo_id,
    MIN(PARSE_DATE('%Y%m%d', event_date)) AS cohort_date
  FROM `your_project.analytics_XXXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260301' AND '20260430'
    AND event_name = 'session_start'
  GROUP BY user_pseudo_id
),
returned AS (
  SELECT DISTINCT
    e.user_pseudo_id,
    PARSE_DATE('%Y%m%d', e.event_date) AS return_date
  FROM `your_project.analytics_XXXXXXX.events_*` e
  WHERE _TABLE_SUFFIX BETWEEN '20260301' AND '20260430'
    AND event_name = 'session_start'
)
SELECT
  f.cohort_date,
  COUNT(DISTINCT f.user_pseudo_id) AS cohort_size,
  COUNT(DISTINCT CASE
    WHEN DATE_DIFF(r.return_date, f.cohort_date, DAY) = 7
    THEN r.user_pseudo_id END
  ) AS day7_retained,
  ROUND(
    COUNT(DISTINCT CASE
      WHEN DATE_DIFF(r.return_date, f.cohort_date, DAY) = 7
      THEN r.user_pseudo_id END
    ) * 100.0 / COUNT(DISTINCT f.user_pseudo_id), 1
  ) AS day7_retention_rate
FROM first_seen f
LEFT JOIN returned r ON f.user_pseudo_id = r.user_pseudo_id
GROUP BY f.cohort_date
HAVING cohort_size >= 50
ORDER BY f.cohort_date;

Looker Studio 連接 BigQuery：建一個真正有用的 GA4 儀表板

SQL 查詢出來的數字，放在 Looker Studio 才有辦法讓不懂 SQL 的同事、主管、客戶看懂。Looker Studio 的免費版功能已經相當完整，連接 BigQuery 不需要任何付費。

連接 BigQuery 數據源

在 Looker Studio 新增報表時，選擇「BigQuery」作為數據連接器。授權後選擇你的 GCP 專案 → 資料集（通常是 `analytics_XXXXXXX`）→ 資料表（選擇一個特定日期的表做初始連接）。

Looker Studio 核心元件與 GA4 分析對照

GA4 → BigQuery → Looker Studio 完整資料流程架構

整個數據架構的資料流動如下。從用戶行為觸發事件，一路到你看到報表，每個節點都有對應的延遲時間和可能的掉數點：

注意圖中的虛線：GA4 標準報表和 BigQuery 全量數據是並存的，不是取代關係。實務上建議兩邊都看，用 BigQuery 驗證 GA4 報表的準確性，再用 Looker Studio 呈現。

進階分析使用情境：什麼問題該用 BigQuery 解決

GA4 + BigQuery 不是每個問題的解答。如果你的需求是「查一下本週有幾個轉換」，GA4 標準報表就夠了，不需要 BigQuery。以下整理了哪些情境非用 BigQuery 不可：

GA4 BigQuery 分析最常見的 3 個踩坑點

在幫客戶做 GA4 BigQuery 串接的過程中，我們踩過不少坑。有些問題不查文件根本不知道，這裡整理出最常見的三個：

踩坑一：intraday 表和每日表數字不一致

如果你開啟了串流匯出，BigQuery 會有兩種表：`events_YYYYMMDD`（每日彙整）和 `events_intraday_YYYYMMDD`（當天即時）。問題是，每日表是每天 UTC 08:00 前後重新處理的，可能會和 intraday 表的數字有差異——GA4 在處理延遲事件時會把資料補入每日表，但 intraday 表不會回溯更新。

解決方式：報表分析一律用 `events_YYYYMMDD`（每日表），只有需要看「今天實時數據」時才查 intraday 表，且要標注這個數字是「預估值」。

踩坑二：event_params 取值型別要配對

GA4 的 event_params 每個值都有 4 種型別：string_value、int_value、float_value、double_value。如果你用 `value.string_value` 去取一個本來是 int 的參數（例如 `engagement_time_msec`），會拿到 NULL。記得先用 `SELECT DISTINCT key FROM UNNEST(event_params)` 確認參數名稱，再用 `value.int_value` 取正確型別。

踩坑三：session 定義和 GA4 報表的 session 不一樣

在 BigQuery 裡自己算 session 數時，很多人直接 `COUNT(DISTINCT ga_session_id)` 就以為搞定了。但 `ga_session_id` 是用戶設備層級的計數器，不是全局唯一的——不同用戶可能有相同的 `ga_session_id` 值（例如兩個用戶都在當天產生了 session #1）。正確做法是 `COUNT(DISTINCT CONCAT(user_pseudo_id, CAST(ga_session_id AS STRING)))`，把用戶 ID 和 session ID 組合才是真正的 unique session key。

從 GA4 自訂報表到 BigQuery SQL：進階分析的升級路徑

如果你已經熟悉 GA4 的自訂報表設定，BigQuery 可以看成是把相同分析邏輯「完全自由化」的升級路徑。在GA4 自訂報表設定教學裡你可以設定的維度和指標，在 BigQuery 都能用 SQL 重現——差別是 BigQuery 沒有維度數量限制、沒有抽樣、而且可以加入 GA4 裡沒有的計算欄位。

升級路徑建議：先在 GA4 自訂報表確認分析需求，確認數字方向對了，再移到 BigQuery 做全量版本。這樣可以避免 SQL 寫了一大堆，卻發現一開始分析方向就不對的窘境。

下一步：把數據分析從工具變成決策習慣

GA4 + BigQuery + Looker Studio 這套組合的真正價值，是讓你有辦法回答那些在 GA4 標準報表裡找不到答案的問題——那個你懷疑數字不對的廣告渠道，那個一直掉單的結帳步驟，那批三個月後才回購的高價值用戶；單純看到更多數字反而不是重點。

從這篇文章的連線教學開始，先把 BigQuery export 啟用，讓數據開始累積。你不需要一開始就寫複雜的 SQL，從「去重轉換數」這個最簡單的查詢下手，看看你的 GA4 報表裡有沒有重複計算的問題。找到一個，就值回票價了。

如果你的業務需要更深入的數據整合——把行銷數據、CRM、廣告後台全部打通，建立真正的單一數據來源——這部分涉及資料工程的設計，歡迎透過恆遠 AI 數據諮詢服務了解完整的數據架構規劃，或是探索客製化系統開發方案，讓數據基礎設施支撐你的業務決策。