GA4 BigQuery 能做什麼？原始事件資料分析與報表差異

GA4 BigQuery 是什麼？和 GA4 報表差在哪？

GA4 BigQuery 是 GA4 原始事件資料匯出，可用 SQL 查事件層級資料。

GA4 介面看到的是整理後的報表，BigQuery 拿到的是事件層級資料。依照 Google Analytics BigQuery Export 說明，GA4 可把 raw events 匯出到 BigQuery，讓分析師用 SQL 查詢，或和 CRM、訂單、廣告成本資料合併。最常見的誤判，是把「GA4 看得到報表」當成「資料已經能回答所有商業問題」。兩者其實服務不同工作。

比較項目	GA4 標準報表	GA4 BigQuery
資料粒度	整理後的報表資料	事件層級原始資料
主要用途	日常監控流量、來源、轉換	自訂分析、資料合併、指標重建
操作方式	介面、探索報表、內建維度	SQL、資料模型、BI 報表
限制	維度組合、high cardinality、資料保留與介面限制	需要權限、SQL、人力與成本控管

GA4 報表資料是整理後的結果

GA4 標準報表適合快速看趨勢，例如流量來源、熱門頁面、轉換事件與營收概況。它的好處是門檻低，行銷主管或 PM 不需要寫 SQL 就能掌握方向；限制是很多報表已經套用 GA4 的資料模型、歸因邏輯、門檻與維度限制。當你想查「某一批使用者看過三篇內容後，有沒有在七天內提交表單」時，標準報表通常不夠細，這時就需要透過 GA4 BigQuery 自訂受眾做精準分群。

BigQuery 取得的是事件層級原始資料

BigQuery 裡的 GA4 匯出資料會圍繞事件展開，常用欄位包含 event_name、user_pseudo_id、event_timestamp、event_params。這些欄位讓你能把 page_view、scroll、add_to_cart、purchase、generate_lead 等事件重新串成使用者旅程。缺點也很現實：原始資料不會自動變成好報表，事件命名和參數品質不好，SQL 查出來只會更混亂。

為什麼有 GA4 還要串接 BigQuery？

GA4 串接 BigQuery 的價值在保存、查詢、整合與重建指標。

• 保存更完整的事件資料，降低只依賴介面的風險。
• 用 SQL 重建工作階段、轉換、營收、留存等自訂指標。
• 把 GA4 原始資料和 CRM、廣告、訂單、會員資料合併。
• 建立穩定的 Looker Studio 或內部 BI 資料模型。
• 檢查事件、UTM、轉換設定是否真的符合分析需求。

保留比 GA4 介面更完整的歷史資料

GA4 的資料保留設定會影響探索與漏斗等非彙總報表；依 Google 資料保留說明，標準 GA4 資源常見選項是 2 個月或 14 個月，360 才有更長選項。BigQuery 的價值在於從串接後開始保存匯出的事件資料，但它不會自動補回串接前的歷史資料。這一點要先講清楚，否則導入後才發現舊資料不存在，通常已經太晚。

用 SQL 重建自己需要的指標

GA4 BigQuery 可以用 SQL 重新定義 session、conversion、revenue、active user、returning user 等指標。這對分析師很重要，因為同一個「轉換率」在內容站、B2B 表單、電商結帳裡可能代表不同事情。真正有用的指標，常常不是 GA4 預設名稱，而是團隊願意長期採用的計算規則。

把網站行為資料和 CRM、廣告、訂單資料合併

BigQuery 的商業價值通常出現在合併資料後。網站事件可用 user_id、會員 ID、email hash、customer_id 或訂單編號和外部資料串起來，再把 campaign cost、訂單毛利、CRM 階段、客服紀錄放進同一個分析環境。這種分析不適合只靠 GA4 介面完成，但也不該在事件命名還不穩時急著做。

GA4 BigQuery 能做到哪些標準報表做不到的分析？

BigQuery 能做跨事件旅程、長期 cohort、客製漏斗與跨資料源分析。

分析能力	標準報表常見限制	BigQuery 的做法
完整使用者旅程	頁面和事件常被切成不同報表	用 user_pseudo_id、user_id 和 event_timestamp 排序事件
自訂漏斗	探索報表適合互動操作，不一定適合長期自動化	用 SQL 固定每一步定義，接排程表或 BI
高基數維度	報表可能出現 (other) 或維度限制	直接查事件層級資料，保留更多細項
ROAS、LTV、CRM 分眾	GA4 不會自動知道所有成本與客戶狀態	把廣告成本、訂單與 CRM 資料合併

跨頁面、跨事件的完整使用者旅程

GA4 BigQuery 可以把同一位使用者的事件依時間排序，觀察從 landing page、scroll、click、form_start 到 generate_lead 的 sequence。匿名訪客可用 user_pseudo_id，登入後可用 user_id 補強。我的判斷是，這類分析最適合拿來找「哪一段內容真的推進決策」，不適合拿來追每個人的個別行為細節。

不受 GA4 探索報表限制的自訂漏斗

若你已經在做 AARRR 漏斗、GA4 funnel tracking 或 conversion funnel dropoff，BigQuery 可以把漏斗步驟變成固定 SQL。好處是口徑穩定，壞處是每一步都要定義清楚。例如加入購物車後 24 小時內完成 purchase，和同一個 session 內完成 purchase，會是兩種不同數字。

高基數維度與大量自訂維度分析

高基數維度像是 user_id、完整網址、自訂 campaign content、站內搜尋字詞、商品 SKU，容易讓 GA4 報表不好讀。BigQuery 能保留更細的事件列，適合查長尾頁面、細分內容分類或大量自訂維度。限制是查詢會變貴，尤其把完整 events_* 用 SELECT * 掃過一遍，通常不是分析，是在燒成本，建議先了解 GA4 BigQuery 成本與查詢費用的控管方式。

跨資料源的 ROAS、LTV、CRM 分眾

電商可以把 GA4 purchase 事件和訂單毛利合併，重新計算 ROAS 和 LTV；B2B 可以把 generate_lead 後的 CRM 階段接回網站來源，判斷哪些內容帶來有效商機。這比只看 轉換率與 CRO 更接近決策，但前提是廣告成本、訂單和 CRM 欄位要有共同鍵值。

誰真的需要 GA4 BigQuery？誰可以暫時不用？

是否導入 GA4 BigQuery，應看決策需求、人力與資料成熟度。

網站情境	導入優先度	判斷理由
電商網站	高	需要商品、購物車、purchase、營收與廣告成本分析
App 或會員制網站	高	需要 user_id、留存、跨裝置與長期 cohort
大量投放網站	高	需要合併 campaign cost、ROAS、CPA 與 LTV
B2B lead 網站	中高	若 CRM 階段可回接，就能看線索品質
小流量內容站	低到中	若只看流量和熱門頁面，GA4 與 Looker Studio 可能已足夠

高優先導入情境

高優先導入通常有五類：電商、App、廣告投放、會員制網站、B2B lead。這些網站的共同點不是流量一定大，而是每一筆事件背後有商業價值，需要被追蹤到更後面的訂單、續約或名單品質。我會先看分析人力，不先看流量門檻；沒人維護的 BigQuery，只是多一個沒人敢碰的資料倉儲。

可先觀望的情境

小流量、只看基礎流量、沒有 SQL 使用者、事件設定還沒整理、UTM 命名混亂時，可以先觀望。優先把 UTM 追蹤、事件命名、轉換設定和 GA4 報表讀法做好。小站急著上 BigQuery，常見結果不是分析能力升級，而是新增一套沒人負責的帳單與權限問題。

GA4 BigQuery 串接前要知道的限制：為什麼數字會和 GA4 報表不一樣？

GA4 與 BigQuery 數字不同，常來自模型、身分、延遲與同意狀態。

Google Developers 的 UI 與 BigQuery 差異說明指出，GA4 報表會有 Google Signals、建模、歸因、抽樣、高基數與延遲等影響；BigQuery 匯出則偏向收集到的事件資料。不能直接說哪邊一定正確，要先確認比較口徑。

差異來源	可能影響	處理方式
Reporting identity	使用者數可能不同	確認是否用 user_id、device ID 或 Google Signals
Google Signals	跨裝置去重不完整反映在 BigQuery	導入 user_id，並承認匿名流量會有落差
Consent Mode	GA4 報表可能含建模資料，BigQuery 不含建模後資料	看 privacy_info 欄位與同意狀態，不做法律推論
匯出延遲	今天或昨天的資料可能尚未完整	用較舊日期比對，避免拿 intraday 當最終資料
session 定義	工作階段數與 GA4 介面不同	固定 user_pseudo_id 與 ga_session_id 的計算方式

Google Signals 不會完整進 BigQuery

Google Signals 可協助 GA4 在報表中做跨裝置去重，也會影響年齡、性別、興趣等資料呈現；但 BigQuery export 不會取得 Google Signals 的完整明細。結果是 GA4 介面的使用者數可能比 BigQuery 用 user_pseudo_id 算出的數字低。對會員站來說，穩定的 user_id 比期待 Google Signals 解決所有問題更可靠。

Consent Mode 會影響資料完整性

Consent Mode 啟用後，BigQuery 可能看到 cookieless pings 與 privacy_info 相關欄位，但 GA4 介面中的行為建模或轉換建模不會以同樣形式進到 BigQuery。這裡不要把技術差異講成法律建議；實務上要做的是標記同意狀態、記錄實作方式，並在報表上註明資料可比性。

intraday 表與 daily 表會有時間差

串流匯出的 events_intraday_YYYYMMDD 會持續更新，但它是接近即時的暫存資料，不該拿來做最終月報。daily 表 events_YYYYMMDD 通常較穩定，且 GA4 可能在後續數天補上延遲事件。若主管問「昨天營收怎麼跟 GA4 不一樣」，第一步不是改 SQL，而是確認資料表是否已完整。

每日匯出 vs 串流匯出：該選哪一種？

每日匯出適合穩定報表，串流匯出適合接近即時監控。

匯出類型	更新頻率	適合情境	主要風險
每日匯出	每天產生 events_YYYYMMDD	月報、週報、固定 BI、長期分析	今天資料不即時，匯出時間不保證固定
串流匯出	當天持續寫入 events_intraday_YYYYMMDD	活動監控、檔期追蹤、接近即時營收觀察	best effort，不保證完整，也可能增加成本

每日匯出適合穩定報表與成本控管

每日匯出會把前一天事件放進 events_YYYYMMDD，適合固定報表、排程查詢與資料模型。標準 GA4 資源的 daily export 有事件量限制，Google 官方文件列出標準資源每日 BigQuery Export 上限為 100 萬事件，360 上限較高。若網站接近限制，要先篩選不必要事件或評估 360，不要等資料缺口出現才處理。

串流匯出適合活動監控與接近即時分析

串流匯出適合檔期活動、廣告素材、營收監控、App 事件警示。它能讓團隊在當天看到趨勢，但不適合作為最終結算。用在活動期間很合理，用在每張常態報表都強迫即時，就容易把成本和解讀風險一起放大。

GA4 BigQuery schema 入門：event_params、user_properties 和 UNNEST 怎麼理解？

GA4 schema 的核心是 events_*、巢狀欄位與 UNNEST，這正是GA4 BigQuery 資料表結構的重要基礎。

GA4 匯出資料表的基本結構

依 GA4 BigQuery Export schema，每個 GA4 resource 會在 BigQuery 建立類似 analytics_property_id 的資料集；daily export 會產生 events_YYYYMMDD，streaming export 會產生 events_intraday_YYYYMMDD。每一列大多代表一個事件，事件裡再包含使用者、裝置、來源、電商與參數資料。

event_params 為什麼要 UNNEST

event_params 是重複 RECORD，一個事件可能同時帶 page_location、page_title、ga_session_id、source、medium 等 key。SQL 不能把它當成普通欄位直接查，通常要用 UNNEST 把參數攤開，這正是GA4 BigQuery SQL 查詢的入門實戰。白話說，事件是一張收據，event_params 是收據裡多個欄位明細，UNNEST 就是把明細拿出來讀。

SELECT
  event_name,
  (SELECT value.string_value FROM UNNEST(event_params)
   WHERE key = 'page_location') AS page_location
FROM `project.dataset.events_*`
WHERE _TABLE_SUFFIX = '20260101'
LIMIT 10;

常見欄位對照

欄位	用途	提醒
event_name	事件名稱，例如 page_view、purchase	命名不穩會直接影響分析
ga_session_id	工作階段參數	通常從 event_params 取出
traffic_source	使用者初次取得來源	intraday 表可能不完整
collected_traffic_source	事件收集到的來源資訊	適合查 UTM 與廣告參數
items	商品明細	電商分析常要再 UNNEST

5 個可直接套用的 GA4 BigQuery SQL 範例

先用五個短 SQL 查 PV、工作階段、來源、轉換與營收。

查詢頁面瀏覽量

頁面瀏覽量可從 page_view 事件開始，搭配 page_location 取出網址。這適合做內容頁、SEO landing page 或活動頁檢查。

SELECT
  (SELECT value.string_value FROM UNNEST(event_params)
   WHERE key = 'page_location') AS page_url,
  COUNT(*) AS page_views
FROM `project.dataset.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
  AND event_name = 'page_view'
GROUP BY page_url
ORDER BY page_views DESC;

查詢工作階段數

工作階段常用 user_pseudo_id 加上 ga_session_id 去重。這個數字可能和 GA4 介面不同，尤其日期範圍、身分設定與延遲事件不一致時。

SELECT
  COUNT(DISTINCT CONCAT(user_pseudo_id, '-',
    (SELECT value.int_value FROM UNNEST(event_params)
     WHERE key = 'ga_session_id'))) AS sessions
FROM `project.dataset.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131';

查詢 source / medium

行銷來源可以先從收集到的 UTM 來源查起，再視資料日期與 schema 版本評估是否改用 session_traffic_source_last_click。來源欄位版本差異很容易造成新舊 SQL 混用，這裡要保守。

SELECT
  collected_traffic_source.manual_source AS source,
  collected_traffic_source.manual_medium AS medium,
  COUNT(*) AS events
FROM `project.dataset.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
GROUP BY source, medium
ORDER BY events DESC;

查詢 conversion 與 ecommerce revenue

轉換事件可依網站定義調整，例如 generate_lead、sign_up、purchase。若是電商分析，可再連到 GA4 電商追蹤、購物車棄單漏斗 與 conversion rate 相關文章。

SELECT
  event_name,
  COUNT(*) AS conversions
FROM `project.dataset.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
  AND event_name IN ('generate_lead', 'sign_up', 'purchase')
GROUP BY event_name;

SELECT
  SUM(ecommerce.purchase_revenue) AS revenue,
  COUNTIF(event_name = 'purchase') AS purchases
FROM `project.dataset.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131';

BigQuery 成本怎麼估？免費不等於完全零成本

BigQuery 成本主要來自儲存、查詢、串流與報表刷新。

Google 提供 BigQuery sandbox，但超過限制、啟用帳單、使用串流匯出或大量查詢時，仍可能產生成本。價格應以 BigQuery pricing 和 BigQuery cost best practices 為準，不要把「可以免費開始」理解成「永遠零成本」。

成本來源	常見發生情境	控管方式
儲存費	長期保存 events_* 表	設定資料保留、分層保存、刪除不必要資料
查詢費	掃描大量欄位與日期	避免 SELECT *，限制 _TABLE_SUFFIX 與必要欄位
串流費	啟用 streaming export	只在需要接近即時監控時使用
BI 刷新	Looker Studio 多人頻繁開報表	預彙總、快取、排程表、權限控管

成本主要來自儲存與查詢掃描量

BigQuery 查詢常按掃描量計費，所以最危險的習慣是對多月 events_* 直接 SELECT *。即使加 LIMIT，在非叢集表上也不一定能降低掃描成本。真正會花錢的不是 BigQuery 本身，而是沒有人管日期範圍、欄位和報表刷新頻率。

Looker Studio 報表也可能增加查詢成本

Looker Studio 連 BigQuery 很方便，但每次報表載入、篩選、切日期，都可能觸發查詢。若報表面向主管或多部門，建議先用 scheduled query、materialized view 或彙總表整理資料，再讓 Looker Studio 讀較小的模型表。這比讓每張圖直接掃原始 events_* 更穩。

避免成本暴衝的基本做法

• 所有查詢都加日期條件，例如限制 _TABLE_SUFFIX。
• 只選需要欄位，避免 SELECT *。
• 常用指標做成排程彙總表。
• 設定 BigQuery 預算提醒與 maximum bytes billed。
• 報表層使用快取或固定刷新頻率。

為什麼 Looker Studio 報表建議走 BigQuery？

Looker Studio 走 BigQuery，可提升穩定性並先整理資料模型。

降低 GA4 API quota 與報表不穩定問題

直接用 Looker Studio 連 GA4 很適合快速報表，但複雜報表會受 GA4 Data API 配額、維度限制、高基數與資料門檻影響。GA4 Data API quotas會依 property、project、request 類型與複雜度消耗額度。當報表要長期給多個人看，BigQuery 通常是比較可控的中間層。

先整理資料模型再給報表使用

比較穩的做法，是先在 BigQuery 做乾淨的報表表，例如 daily_sessions、daily_conversions、campaign_cost_summary，再交給 Looker Studio。可以用 materialized view 或 scheduled query 固定更新。這樣報表讀的是整理後資料，而不是每次都重新解巢狀欄位、重算漏斗、重掃原始表。

導入後要做的資料治理：不然 BigQuery 只會放大髒資料

GA4 BigQuery 導入後，治理重點是事件、UTM、權限與保留。

事件與參數命名要先穩定

事件命名不穩，BigQuery 只會把混亂保存得更久。purchase、generate_lead、form_submit、sign_up、add_to_cart 這類事件要有清楚定義，參數也要固定型別。若要做 GA4 funnel tracking，漏斗每一步的事件和必要參數要先寫成文件。

UTM 與廣告資料要有一致規則

source、medium、campaign、content 的命名如果沒有規則，後面就很難分析 CTR、CPC、CPA、CPM 和 ROAS。UTM 治理不是小事，它直接決定行銷預算能不能被正確歸因。

權限與資料保留策略要先定義

BigQuery 會保存更細的事件資料，所以權限不該全部開給所有人。至少要區分資料管理者、分析者、報表使用者；也要定義原始表保存多久、彙總表保存多久、誰能匯出資料。治理晚做，BigQuery 只會把小問題放大成跨部門問題。

GA4 BigQuery 新手導入路線圖

新手可依串接、驗證、SQL、指標、BI、成本六步導入。

第 1 步到第 6 步

1. 完成 GA4 串接 BigQuery，確認使用正確 GA4 resource、Google Cloud project、資料集位置與權限。
2. 確認 BigQuery 裡是否出現 events_YYYYMMDD，若有 streaming export，再檢查 events_intraday_YYYYMMDD。
3. 先跑三個基礎 SQL：page_view、sessions、purchase 或 generate_lead，不要一開始就寫複雜歸因模型。
4. 把 SQL 結果和 GA4 報表比較，記錄差異來源，例如 Google Signals、Consent Mode、延遲或 session 計算方式。
5. 建立固定資料模型，再接 Looker Studio 報表 或內部 BI。
6. 設定成本控管、預算提醒、排程查詢與資料治理文件，並定期回頭檢查事件品質。

結論：GA4 BigQuery 的真正價值不是備份，而是讓 GA4 變成可分析的資料資產

GA4 BigQuery 的核心價值，是突破標準報表限制並建立可查詢資料資產。

GA4 標準報表擅長日常監控，BigQuery 擅長回答更細的問題：使用者在轉換前走過哪些頁面、漏斗掉點是否和來源有關、CRM 成交名單來自哪種內容、廣告成本能不能和實際營收合併、high cardinality 維度是否被報表折疊。這些才是 GA4 原始資料分析真正有用的地方。

導入順序可以很務實：先完成串接，確認 events_* 表，跑 page_view、sessions、conversion 三個基礎 SQL，再比較 GA4 報表差異。當差異原因講得清楚，才進一步接 Looker Studio、建立排程表與長期資料模型。BigQuery 很強，但它只適合願意管理資料品質、查詢成本與分析口徑的團隊。

GA4 BigQuery 是免費的嗎？

可以從 BigQuery sandbox 開始，但不代表完全零成本。當資料量、查詢量、串流匯出或報表刷新超過限制時，仍可能產生 BigQuery 費用。正式導入前應查看 Google Cloud 最新價格表，並設定預算提醒。

GA4 串接 BigQuery 後會自動匯入歷史資料嗎？

不會。GA4 BigQuery 匯出通常從串接後開始累積資料，不能期待它自動補回串接前的歷史事件。若需要長期分析，越早完成串接越能保留後續資料。

BigQuery 查出來的使用者數為什麼和 GA4 不一樣？

常見原因包含 reporting identity、Google Signals、user_id 覆蓋率、Consent Mode、active user 定義、HLL++ 近似計算與延遲事件。BigQuery 用 user_pseudo_id 直接去重時，不一定等於 GA4 介面中的使用者數。

我只用 Looker Studio 看報表，也需要 BigQuery 嗎？

如果報表很簡單，直接連 GA4 可能足夠。若報表常遇到配額、速度、維度限制，或需要合併廣告成本、CRM、訂單資料，BigQuery 會是更穩定的資料層。

每日匯出和串流匯出差在哪？

每日匯出產生較穩定的 events_YYYYMMDD，適合週報、月報與長期分析。串流匯出會在當天更新 events_intraday_YYYYMMDD，適合接近即時監控，但不保證完整，也可能增加成本。

不會 SQL 可以用 GA4 BigQuery 嗎？

可以看別人整理好的報表，但很難發揮 BigQuery 的主要價值。至少要有人能讀懂基本 SQL、event_params、UNNEST、日期篩選與查詢成本，否則導入後容易停在「資料有進來，但沒人會用」。

GA4 BigQuery 適合小流量網站嗎？

小流量網站不一定需要馬上導入。若只是看流量、來源和基本轉換，GA4 報表通常足夠；若小流量但每筆 lead 價值很高，且需要接 CRM 判斷名單品質，BigQuery 仍可能值得。

BigQuery 裡的 event_params 是什麼？

event_params 是事件參數集合，用來保存 page_location、ga_session_id、campaign、value 等資料。因為它是重複欄位，查詢時常需要用 UNNEST 把參數攤開。

Google Signals 會出現在 BigQuery 匯出資料裡嗎？

不會以完整明細形式進入 BigQuery。GA4 介面可能利用 Google Signals 做跨裝置去重與報表處理，但 BigQuery 主要保存收集到的事件資料，因此使用者數和受眾資料可能不同。

GA4 BigQuery 可以用來做電商營收分析嗎？

可以，尤其適合分析 purchase、items、商品營收、購物車行為與 LTV。前提是 GA4 電商事件正確實作，transaction_id、items、currency、value 等欄位要穩定。

GA4 BigQuery 成本會不會很高？

不一定。成本高低取決於資料量、查詢寫法、報表刷新頻率與是否使用串流匯出。小量資料且查詢有日期篩選，成本通常可控；大量 SELECT *、多人反覆刷新報表，成本就容易上升。

串接 BigQuery 後還需要 GA4 標準報表嗎？

需要。GA4 標準報表適合日常監控與快速查看趨勢，BigQuery 適合深入分析、資料整合與自訂模型。兩者應該分工使用，而不是互相取代。