GA4 BigQuery 自訂受眾建立教學：突破介面限制的精準分群方法

為什麼要結合 GA4 與 BigQuery 建立自訂受眾？

GA4 介面內建的目標對象功能，其建立邏輯主要依賴預設的維度、指標與事件條件進行組合。當行銷人員需要定義更複雜的受眾，例如基於跨裝置行為、精密的時間序列，或是結合多個非線性事件路徑時，介面工具會顯得力有未逮。BigQuery 提供了 GA4 原始事件資料的直接存取權限，讓我們能透過 SQL 查詢語言，從最底層的資料結構中提取符合任何業務邏輯的使用者清單。兩者結合的價值，在於將 GA4 的易用性與 BigQuery 的無限彈性結合，創造出介面無法直接實現的精準受眾。

BigQuery 中的資料表，如 events_*，儲存了每次互動的原始紀錄，其欄位結構遠比 GA4 介面提供的篩選器更為豐富且具體。這使得我們能定義例如「在特定時間窗口內，依序瀏覽 A 與 B 頁面，但從未觸發 C 事件，且來自特定 UTM 設定」的使用者羣組。這種定義方式完全以原始資料為基礎，避免了介面層可能的資料轉譯限制或聚合誤差。簡言之，BigQuery 是手術刀，GA4 介面是標準工具箱，後者處理常規任務快速方便，前者則解決高度客製化的分析需求。

為什麼我不能直接在 BigQuery 中建立與 GA4 介面功能完全相同的「目標對象」？

這涉及兩個平臺的角色與資料處理方式的根本差異。GA4 介面的「目標對象」是一個與 Google Analytics 評估引擎深度整合的產品功能，它允許即時在報表與 Google Ads 中套用，並由 Google 的基礎設施自動處理更新與計算。BigQuery 是一個通用的雲端資料倉儲，儲存的是原始事件資料流。您可以在 BigQuery 中用 SQL 模擬出與 GA4 介面條件完全相同的使用者名單，但這個名單本身並非 GA4 內建的「目標對象」物件。它無法自動出現在 GA4 的受眾清單中，也無法直接用於 GA4 的即時評估。它的價值在於，您可以將這個名單匯出至其他平臺（如 Google Ads）作為再行銷清單，或用於更深度的離線分析。因此，BigQuery 提供的是建立受眾名單的原料與工具，而 GA4 介面則是將名單轉化為可用的產品功能。

前置作業：確保 GA4 數據成功匯出至 BigQuery

在著手建立任何自訂受眾名單之前，必須先確認 GA4 的事件資料能正確、穩定地匯出至 BigQuery。這項設定是後續所有操作的基礎。主要確認事項包括：您是否已在 GA4 管理介面中啟用 BigQuery 連結、選擇的匯出模式（批次或串流）是否符合分析時效需求，以及資料是否已開始流入 BigQuery 專案中的指定資料集。此步驟通常是一次性設定，但匯出模式會影響資料的新鮮度與查詢成本。

GA4 匯出至 BigQuery 的資料，其核心結構圍繞著 events_* 這系列資料表。每一天的事件資料會儲存在對應日期的資料表中（例如 events_20231027）。表內每個欄位都承載著特定意義，例如 event_name 標示事件類型，event_timestamp 記錄精確時間，而 event_params 則是一個結構化的欄位，儲存瞭如頁面標題、商品 ID 等事件參數。理解這些欄位是撰寫有效查詢語句的前提。

什麼是 `events_*` 資料表中的 `user_pseudo_id`？

user_pseudo_id 是 GA4 用來在沒有確定性使用者登入資訊（如已驗證的使用者 ID）時，匿名識別使用者的欄位。它通常由裝置瀏覽器的 Cookie 或裝置 ID 派生而來，格式類似「一串數字.一個識別碼」。在 BigQuery 分析中，它是連結同一匿名使用者不同事件的關鍵欄位。例如，要追蹤「使用者 X 在今天加了購物車，昨天瀏覽了商品頁」，您的 SQL 查詢就會透過 user_pseudo_id 來關聯 events_* 資料表中屬於同一 user_pseudo_id 的不同事件紀錄。需要注意的是，若使用者跨裝置或清除 Cookie，其 user_pseudo_id 會改變，這可能導致跨裝置分析的挑戰。

方法一：在 GA4 介面中建立自訂目標對象

對於多數標準行銷場景，直接使用 GA4 介面建立目標對象仍是最快捷的選擇。此方法無需編寫程式碼，透過圖形化介面即可完成設定，且建立的受眾能立即用於 GA4 報表區隔與匯出至 Google Ads。適用於條件邏輯相對直接，且不需要結合外部資料源的受眾定義。操作路徑為：進入 GA4 管理介面，於「資源」欄位下找到「目標對象」，點擊「新增目標對象」即可開始。

建立受眾的核心在於設定「包含條件」。您可以從「事件」（例如：發生了 purchase 事件）、「維度」（例如：國家 = 臺灣）、「指標」（例如：過去 30 天工作階段數 > 5）等預設類別中選擇。GA4 也允許透過「集合」功能將多個條件羣組，進行更靈活的 AND/OR 邏輯組合。進階功能「序列」允許您定義有時間順序的事件流，是追蹤使用者轉換路徑的強大工具。

在 GA4 介面設定「序列」條件的完整步驟

1. 在新增目標對象頁面，點擊「新增條件」，然後選擇「序列」。
2. 在「序列類型」中選擇「使用者」或「事件」。選擇「使用者」意味著序列必須由同一個使用者按順序完成；選擇「事件」則允許序列由不同事件組成，不要求同一使用者（較少用）。
3. 步驟 1：設定序列的第一步條件。例如，選擇「事件」，然後選擇事件名稱為 view_item。您可以進一步限定此事件的參數，如商品類別。
4. 點擊「新增步驟」來加入序列的後續步驟。例如，步驟 2 設定事件名稱為 add_to_cart。
5. 您可以繼續加入更多步驟。同時，可以設定步驟之間的時間限制，例如「步驟 1 發生後 7 天內」，用來定義時間窗口。
6. 最後，在「序列結尾」部分，您可以選擇「在任何步驟之後結束」或「在特定步驟之後結束」，這會影響受眾的最終包含範圍。
7. 完成序列設定後，與其他任何條件一樣，為目標對象設定名稱和描述，然後儲存。此受眾會開始累積符合條件的使用者（通常需 24-48 小時）。

方法二：利用 BigQuery SQL 查詢建立精準受眾名單

當 GA4 介面的序列條件或維度/指標組合無法滿足需求時，BigQuery SQL 查詢提供了終極的解決方案。您可以直接編寫語句，從原始事件資料中篩選、轉換、並聚合出任何可以想像到的使用者羣體。這個方法的核心是將業務問題轉化為 SQL 查詢邏輯，從 events_* 資料表中撈取出符合條件的 user_pseudo_id 列表。此列表隨後可被匯出並用於其他系統。

一個常見的應用場景是找出「過去 30 天內，加入購物車但從未完成購買」的使用者。這需要查詢 events_* 表，先找出所有有 add_to_cart 事件的使用者，再排除掉那些同時也有 purchase 事件的使用者。SQL 的強大之處在於，您可以輕鬆加入更複雜的條件，例如限定加購的商品類別、購買事件的價值門檻等。

BigQuery SQL 範例：篩選符合特定事件參數的使用者

以下是一個簡化的 SQL 結構範例，用於說明如何篩選曾在事件參數中指定特定內容的使用者。假設您想找出所有曾瀏覽「產品類別」為「高階筆記型電腦」的商品頁的使用者。

SELECT DISTINCT
  user_pseudo_id
FROM
  `your-project.analytics_XXXXXXXX.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
  AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
  AND event_name = 'view_item'
  AND (
    SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'item_category'
  ) = '高階筆記型電腦'

這段查詢的關鍵在於利用 UNNEST 函數展開巢狀的 event_params 陣列，以便存取內部的 key 與 value 欄位。這是在 BigQuery 中處理 GA4 事件參數的標準做法。要更深入瞭解這類查詢的基礎，建議參閱 GA4 BigQuery SQL 查詢：基礎語法與巢狀欄位處理實戰。

將 BigQuery 受眾清單匯入 Google Ads

從 BigQuery 查詢獲得受眾清單（例如一組 user_pseudo_id 或加密的電子郵件地址）後，下一步是將其匯入 Google Ads 以進行再行銷活動。最直接且廣泛使用的方法是透過 Google Ads 的「客戶管理員」功能上傳使用者清單。此流程需要您先將 BigQuery 查詢結果匯出為 CSV 檔案，並確保檔案格式符合 Google Ads 的要求。上傳後，Google Ads 會將此清單作為自訂受眾，可用於廣告活動的目標設定。

除了手動上傳，技術團隊也可能考慮使用 Google Ads API 來建立自動化的資料管道。這允許您排程執行 BigQuery 查詢，並自動將結果同步至 Google Ads 受眾清單，實現半自動化的更新。然而，必須明確指出，這是一個自建流程，並非 Google 提供的官方一鍵同步功能。您需要自行維護腳本、處理授權、監控執行狀態，並確保資料更新頻率符合業務需求。

上傳受眾至 Google Ads 時，資料檔案的格式要求是什麼？

Google Ads 對於上傳的使用者清單檔案有嚴格的格式規範，這主要關係到資料匹配率與隱私合規。如果您使用的是使用者 ID 或客戶 ID，檔案通常需要包含兩欄：一欄是您自己的識別碼，另一欄是 Google 可識別的標記（如 hashed email）。如果上傳的是純電子郵件或電話號碼名單，這些資訊必須在上傳前經過 SHA256 雜湊加密處理，以保護用戶隱私。具體的欄位順序、雜湊格式、檔案編碼（UTF-8）以及逗點分隔符等細節，都需要參照 Google Ads 最新的官方技術規範文件。格式不符會導致上傳失敗或匹配率極低。

實戰案例：用序列條件追蹤高價值使用者路徑

讓我們透過一個具體案例，比較兩種方法在解決同一問題時的差異。假設行銷團隊希望追蹤「瀏覽產品頁後未加入購物車，但 7 天後再次回訪」的使用者。這類使用者展現了初期興趣，但可能在首次訪問時猶豫不決，屬於值得再次接觸的潛在客戶羣。

在 GA4 介面中，您可以使用「序列」功能，設定步驟 1 為 view_item 事件，步驟 2 為 session_start 事件（代表新的工作階段，即回訪），並設定步驟 1 與步驟 2 之間的時間間隔為 7 天。同時，在序列條件中，您可以加入排除條件，確保步驟 1 與步驟 2 之間沒有發生 add_to_cart 事件。這個設定在介面中是可行的，但邏輯相對固定。

若使用 BigQuery SQL，您可以更靈活地定義此行為。您可以編寫查詢，先找出每個使用者第一次 view_item 的時間，然後尋找該時間點之後 7 天內是否存在另一個來自相同 user_pseudo_id 的 session_start 事件。同時，您可以輕鬆加入更複雜的篩選，例如第二次回訪時瀏覽了不同的產品頁，或兩次訪問的時段都在晚上等。SQL 提供了時間序列分析上近乎無限的自由度。

比較 GA4 介面序列條件 vs. BigQuery SQL 時間序列查詢的優劣

比較維度	GA4 介面建立	BigQuery SQL 建立
操作門檻	低，透過下拉選單與條件設定，無需編程。	高，需要具備 SQL 編寫能力與資料庫結構知識。
邏輯複雜度	支援基礎的 AND/OR 與線性序列邏輯。複雜的非線性路徑或跨事件參數的交叉分析較難實現。	可實現任意複雜的邏輯，包括多重序列、子查詢、視窗函數等，能精準刻畫任意使用者路徑。
資料更新頻率	通常近即時（取決於 GA4 處理延遲），受眾會自動累積新使用者。	依賴手動或排程執行的查詢，資料新鮮度取決於您設定的執行頻率。非自動更新。
維護成本	低，設定後在 GA4 介面中管理。	較高，需維護 SQL 查詢語句、匯出腳本、上傳流程，並監控執行狀態。

GA4 目標對象 vs. Meta 自訂受眾：機制與應用比較

在數位廣告領域，GA4 與 Meta（Facebook）是兩大主要的受眾定義與投放平臺。理解它們建立自訂受眾的底層機制差異，有助於制定更有效的跨平臺行銷策略。雖然兩者都能用於再行銷，但其數據來源、處理方式與整合管道有著本質上的不同。

GA4 的目標對象主要基於網站或應用程式上的事件（Events）與維度（Dimensions）來定義，資料來源相對單一且直接。其優勢在於與 Google 生態系（尤其是 Google Ads）的緊密整合，受眾可即時用於 Google Ads 廣告活動。BigQuery 進一步擴展了 GA4 的能力，允許在事件資料基礎上進行自訂分析。

Meta 的自訂受眾則有多種數據來源，包括 Meta 像素捕捉的網站事件、應用程式事件、客戶名單（來自 CRM 的電子郵件或電話號碼）以及與 Meta 帳戶的互動。它的建立更偏向於「匹配」邏輯，即將您提供的名單與 Meta 用戶進行匹配。受眾更新通常需要重新上傳名單或等待像素數據回傳。兩者在可用條件、數據深度和廣告投放平臺上各有所長，實務上常需要結合使用，以覆蓋不同的使用者觸及點。

注意事項與常見問題

在實作過程中，會遇到一些共通的技術與流程問題。以下整理了幾個最常見的疑問，涵蓋了從設定、查詢到匯出的關鍵環節。

使用 BigQuery 建立自訂受眾，與直接在 GA4 介面建立有什麼根本不同？

主要不同在於資料處理與邏輯複雜度。GA4 介面建立受眾是透過預設的維度、指標與事件進行條件組合，操作較直覺但功能有限。BigQuery 方式則是直接查詢原始事件資料，可用 SQL 實現任何複雜的交叉分析與時間序列邏輯，定義更精準的受眾，但需要 SQL 技能且匯出流程較手動。

我一定要使用 BigQuery 來建立 GA4 受眾嗎？

不一定。如果您的受眾定義簡單（如「所有使用者」、「過去 30 天的活躍使用者」），直接在 GA4 介面建立即可。只有當您需要進行跨事件、跨裝置、或基於複雜業務邏輯（例如「看了 A 頁面且花了超過 5 分鐘，但沒完成 B 動作」）的深度篩選時，才需要藉助 BigQuery 的 SQL 查詢能力。

從 BigQuery 查詢出的受眾名單，如何同步到 Google Ads 進行再行銷？

最直接的方式是將查詢結果（如使用者 ID 或加密的電子郵件）匯出為 CSV 檔案，然後透過 Google Ads 的「客戶管理員」功能上傳為自訂受眾清單。此過程非即時同步，需手動或透過腳本定期更新資料。請注意 Google Ads 對上傳名單的格式與隱私政策有嚴格要求。

在 BigQuery SQL 查詢中，如何找出「符合特定事件序列」的使用者？

這需要使用 SQL 的視窗函數（如 FIRST_VALUE、LEAD）或 JOIN 來關聯同一使用者的不同事件，並比較它們的時間戳。例如，要找「加入購物車後 7 天內未完成結帳」的使用者，需先找出每個使用者的「加入購物車」事件時間，再檢查其後 7 天內是否存在「購買」事件。這比在 GA4 介面設定序列條件更靈活，但 SQL 寫法也更複雜。

這種方法建立的受眾，數據更新是即時的嗎？

不是即時的。取決於兩個環節：(1) GA4 事件資料匯出至 BigQuery 的頻率（可能是批次更新，延遲數小時至一天）。(2) 您執行 SQL 查詢並上傳至 Google Ads 的時間。因此，這更適合用於建立基於歷史行為的長期再行銷受眾，而非捕捉即時活動的熱受眾。

我沒有程式背景，也能完成 BigQuery 查詢建立受眾嗎？

這具有挑戰性。基本的概念和流程可以理解，但撰寫正確的 SQL 查詢需要具備資料庫語言的基礎知識。建議初學者可以從理解查詢邏輯開始，並嘗試修改現成的範例來匹配自己的需求，或藉助資料分析師、工程師的協助來編寫與驗證查詢。

將 GA4 數據匯入 BigQuery 是否需要付費？

這取決於您的 GA4 版本和使用量。一般來說，將 GA4 資料串流至 BigQuery 本身在標準版 GA4 中是免費功能，但儲存於 BigQuery 中的資料以及執行的查詢會產生費用，具體取決於資料量與查詢複雜度。要更全面地瞭解 GA4 與 BigQuery 整合後能進行哪些分析，可參考 GA4 BigQuery 能做什麼？原始事件資料分析與報表差異。