GA4 BigQuery 資料表結構解析：欄位命名與三層架構

例如，執行以下 SQL 可以檢視特定資料表的欄位結構：

SELECT column_name, data_type
FROM `your-project-id.analytics_123456789.INFORMATION_SCHEMA.COLUMNS`
WHERE table_name = 'events_20260601'
ORDER BY ordinal_position;

這份查詢結果將完整列出所有欄位名稱與其對應的 BigQuery 資料型別（如 STRING、INTEGER、RECORD 等），是進行任何複雜查詢前不可或缺的參考步驟。

event_params、user_properties 與 items 巢狀結構解剖

GA4 資料表中最獨特也最具挑戰性的部分，是 event_params、user_properties 與 items 這些以 RECORD（結構體）型態存在的巢狀重複（REPEATED）欄位。它們不像 flat 欄位那樣直接可讀，而是包含了多層嵌套的 key-value 對，需要特定的 SQL 語法展開才能提取有用的資訊。掌握這些欄位的解讀方式，是發揮 GA4 原始資料價值的關鍵。

event_params 的 key-value 結構說明

以 event_params 為例，它是一個陣列（ARRAY）型態的欄位，裡面每一個元素都是一個包含 key（參數名稱）和 value（參數值，本身也是一個結構體，包含 string_value、int_value、double_value 等不同型別的欄位）的結構體。例如，一個頁面瀏覽事件的 event_params 中可能同時包含 page_title、page_location、ga_session_id 等多個參數。

user_properties 的結構類似，但它記錄的是使用者層級的屬性（例如，使用者的會員等級、偏好的語言），這些屬性會附加在該使用者觸發的每個事件上。items 欄位則主要用於電商相關事件（如 add_to_cart、purchase），它是一個巢狀陣列，用來儲存交易中涉及的每一個商品（item）的詳細資訊，包括商品 ID、名稱、價格、數量等，結構更為複雜。

UNNEST 展開巢狀欄位的語法範例

要查詢巢狀欄位中的內容，必須使用 UNNEST() 函數將其「展開」為虛擬的資料列，使其能與主事件資料進行關聯查詢。以下是一個簡單的範例，用於提取事件中的 page_title 參數：

SELECT
  event_name,
  event_timestamp,
  params.key AS param_key,
  params.value.string_value AS page_title
FROM
  `your-project-id.analytics_123456789.events_20260601`,
  UNNEST(event_params) AS params
WHERE
  params.key = 'page_title';

在這個查詢中，UNNEST(event_params) AS params 將每一筆事件的 event_params 陣列展開，並為陣列中的每個參數創建一行暫時的記錄，命名爲 params。隨後，你就可以像查詢普通欄位一樣，指定要取 params.key 和 params.value.string_value。這種展開操作是分析 GA4 原始資料時最頻繁使用的技巧。

用標準 SQL 查詢 GA4 資料表的基本語法模式

BigQuery 預設使用標準 SQL 查詢 GA4 匯出的資料表。一個典型的查詢會從指定資料表路徑開始，透過 UNNEST 處理巢狀欄位，並使用 WHERE 子句過濾。理解這個基本模式，能讓你快速將分析需求轉化為實際可執行的查詢。

使用 INFORMATION_SCHEMA 檢視資料表欄位

在撰寫查詢前，先透過 INFORMATION_SCHEMA 確認欄位是良好習慣。除了前文提到的查詢欄位清單與型別，你也可以用它來檢查特定資料表是否存在、或比較不同日期的資料表結構是否一致。

一個結合了 flat 欄位與巢狀欄位展開的完整查詢骨架如下：

SELECT
  event_name,
  TIMESTAMP_MICROS(event_timestamp) AS event_time, -- 將微秒轉換為可讀時間
  user_pseudo_id,
  device.category AS device_category,
  params.value.string_value AS page_title
FROM
  `your-project-id.analytics_123456789.events_20260601`
CROSS JOIN
  UNNEST(event_params) AS params
WHERE
  event_name = 'page_view'
  AND params.key = 'page_title';

這個範例首先從指定的日表中選取事件名稱、轉換後的時間戳記、使用者 ID 與裝置類別。接著，透過 CROSS JOIN UNNEST(event_params) 展開巢狀參數，並在 WHERE 條件中過濾出特定事件名稱和特定的參數鍵值，最終提取出頁面標題。這個模式是構建更複雜分析的基礎。

GA4 資料匯出的延遲與資料可用性

GA4 的每日匯出並非即時資料流。設定匯出後，當天的資料通常需要等待 24 到 48 小時才會完整地出現在對應日期的 BigQuery 資料表中。這意味著，如果你在當天或隔天早上查詢最新的資料表，很可能會發現資料不完整或尚未可用。規劃分析報表或資料管線時，必須將這個延遲因素納入考量。

延遲對查詢結果的實際影響

資料延遲的具體影響在於：假設現在是 2026 年 6 月 3 日，要查詢 6 月 2 日全天的完整資料，最好等到 6 月 3 日的下午或晚上再執行查詢。若在 6 月 3 日一早就查 events_20260602，很可能只會拿到部分事件，導致分析結果產生偏差。此外，這種延遲機制也意味著 BigQuery 中的 GA4 資料不適合用於需要即時或近即時監控的場景。若需要更即時的資料，可以考慮啟用 GA4 的「串流匯出至 BigQuery」功能，但其資料結構與欄位可能與每日匯出有所不同，且通常用於補充而非取代每日匯出。

GA4 資料表的常見限制與注意事項

儘管 BigQuery 中的 GA4 原始資料非常強大，但使用時必須瞭解其固有限制。並非你在 GA4 介面報表中看到的所有維度和指標都會原封不動地出現在匯出資料表中。有些欄位可能因設定或政策原因而缺漏，有些則可能需要額外的處理才能使用。

• 欄位完整性差異：部分在 GA4 介面中可用的維度（如細分、某些使用者屬性）可能不會匯出至 BigQuery，或匯出的格式不同。
• 政策限制資料：受 Google 廣告隱私權政策影響的資料，例如基於興趣的廣告相關欄位（年齡、性別、興趣愛好），在匯出資料中可能顯示為空值或受限。
• 結構變動：GA4 產品本身會持續更新，其匯出至 BigQuery 的資料表欄位結構也可能隨版本演進而新增、修改或移除。長期維護的查詢腳本需要定期檢查相容性。
• 資料保留期：BigQuery 中的 GA4 匯出資料遵循你在 GCP 專案設定的資料保留政策，與 GA4 介面中的資料保留設定是分開管理的。

這些限制提醒我們，BigQuery 原始資料是 GA4 介面報表的補充而非完全替代。若需要比較兩者差異以決定使用場景，可以參考下表。

總結：讀懂 GA4 BigQuery 資料表結構後，下一步怎麼走

掌握了從專案架構、資料表命名、flat 欄位、巢狀結構到查詢模式的完整知識後，你已經具備了直接與 GA4 原始事件資料對話的基礎能力。這不僅是查看資料的第一步，更是進行深度自訂分析、建構精準報告或整合其他資料源的必要前提。你可以從撰寫簡單的查詢開始，逐步探索不同事件類型、使用者行為路徑或轉換歸因等更複雜的分析主題。

當你熟悉了資料表結構與基本查詢後，便能更自信地回答諸如「特定事件在不同裝置上的觸發頻率」、「使用者從進入到轉換的完整歷程」等進階問題。若想進一步瞭解這些原始資料能如何轉化為具體的商業洞察或優化建議，可以延伸閱讀 GA4 BigQuery 能做什麼？原始事件資料分析與報表差異。