瞭解如何將網站體驗指標資料傳送至 Google Analytics (分析) 4 資源，以及匯出資料以便在 BigQuery 和 Looker Studio 中進行分析。
Google 提供 Searchsole、PageSpeed Insights (PSI) 和 Chrome 使用者體驗報告 (CrUX) 等工具，可讓開發人員查看自己網站針對實際使用者的Core Web Vitals 指標，瞭解網站效能表現。
這些工具非常實用，在於能讓您全面掌握網站的實際效能，而且幾乎不需要進行任何設定，即可開始使用。
不過，基於下列幾項重要原因，您不想單靠這些工具評估網站效能：
- 以 CrUX 為基礎的工具，可以按月或過去 28 天來報告資料。也就是說，進行任何變更之後，您必須等待很長的時間才能看到結果。
- 以 CrUX 為基礎的工具只能按特定數量的維度劃分資料，例如國家/地區、連線類型和裝置類別 (電腦或行動裝置)。您無法按照自家業務專屬的維度 (例如：參與度高的使用者、特定實驗群組的使用者等) 劃分資料。
- 以 CrUX 為基礎的工具會顯示效能「什麼」，但無法說明「原因」。有了分析工具，您可以傳送額外資料，協助追蹤問題並進行偵錯。
基於上述原因，我們建議所有網站擁有者使用現有的分析工具監控網站體驗核心指標指標。這篇文章將說明如何使用 Google 提供的免費工具來完成這項工作。
完成所有設定後，您就能建立下列資訊主頁：
如要查看此處所列所有步驟的簡要總覽，請參閱 2021 年 Google I/O 大會講座影片：
測量
您一直以來可透過 Google Analytics (分析) 使用自訂指標評估成效，但 Google Analytics (分析) 4 (GA4) 中有些新功能可讓開發人員特別期待。
- 無須設定的自訂事件參數
- 可免費使用 BigQuery 匯出功能，讓您使用 SQL 查詢資料
雖然 Google Analytics (分析) 網頁介面有強大的分析工具，但使用您可能熟悉的查詢語言，無法超越原始事件資料存取的強大功能和靈活性。
如要開始使用 Google Analytics (分析) 4 和 BigQuery 評估網站體驗核心指標，您必須完成以下三個步驟：
- 建立 Google Analytics (分析) 4 資源和 BigQuery 專案。
- 只要在 Google Analytics (分析) 資源設定中啟用 BigQuery Export，系統就會將您收到的所有資料自動填入 BigQuery 專案資料表中。
- 將 Web-vitals JavaScript 程式庫新增至網站，以便評估 Core Web Vitals 指標並將資料傳送至 Google Analytics (分析) 4。
分析
完成所有設定後，事件資料應會填入 BigQuery 介面，您應該能夠按照下列方式查詢資料：
SELECT * FROM `my_project_id.analytics_XXXXX.events_*`
WHERE event_name IN ('LCP', 'FID', 'CLS')
以下是這項查詢的結果預覽：
查詢網站體驗指標資料
開始查詢網站體驗指標事件資料前，請務必先瞭解資料的匯總方式。
最重要的是，在某些情況下，同一個指標的可能會接收多個事件。如果指標值發生變更並回報更新值 (CLS 的常見情況)，就可能發生這種情況。
如果是網站體驗指標事件，最後傳送的值一律是最準確的值，因此在執行任何分析前，請務必只篩選出這些值。網站 Vitals JavaScript 程式庫提供的程式碼片段可用來將資料傳送至 Google Analytics (分析) 4，包括傳送每項指標的不重複 ID，因此您可以利用下列查詢，將結果限制為只顯示每個指標 ID 的最後接收值：
# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
SELECT *, IF (ROW_NUMBER() OVER (
PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
) = 1, true, false) AS is_last_received_value
FROM `bigquery_project_id.analytics_XXXXX.events_*`
WHERE event_name in ('CLS', 'FID', 'LCP') AND
_TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
) WHERE is_last_received_value
)
請注意，此文章中參照的所有其他查詢都會以這個子查詢開頭。
以下幾節將列舉幾個建議執行的網站體驗指標常見查詢。
查詢範例
在整個網站均採用 75% 百分位數 (第 75 個百分位數) 的 LCP、FID 和 CLS
# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
SELECT *, IF (ROW_NUMBER() OVER (
PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
) = 1, true, false) AS is_last_received_value
FROM `bigquery_project_id.analytics_XXXXX.events_*`
WHERE event_name in ('CLS', 'FID', 'LCP') AND
_TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
) WHERE is_last_received_value
)
# Main query logic
SELECT
metric_name,
APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS p75,
COUNT(1) as count
FROM (
SELECT
metric_name,
ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
FROM web_vitals_events
)
GROUP BY 1
所有個別 LCP 值 (從最高到最低)
# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
SELECT *, IF (ROW_NUMBER() OVER (
PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
) = 1, true, false) AS is_last_received_value
FROM `bigquery_project_id.analytics_XXXXX.events_*`
WHERE event_name in ('CLS', 'FID', 'LCP') AND
_TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
) WHERE is_last_received_value
)
# Main query logic
SELECT
ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
FROM web_vitals_events
WHERE metric_name = 'LCP'
ORDER BY metric_value DESC
10 個最熱門網頁的 LCP 分數 (第 75 頁)
# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
SELECT *, IF (ROW_NUMBER() OVER (
PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
) = 1, true, false) AS is_last_received_value
FROM `bigquery_project_id.analytics_XXXXX.events_*`
WHERE event_name in ('CLS', 'FID', 'LCP') AND
_TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
) WHERE is_last_received_value
)
# Main query logic
SELECT
page_path,
APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS LCP,
COUNT(1) as count
FROM (
SELECT
REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
FROM web_vitals_events
WHERE metric_name = 'LCP'
)
GROUP BY 1
ORDER BY count DESC
LIMIT 10
CLS 最差的前 10 大網頁 (第 75 頁)
# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
SELECT *, IF (ROW_NUMBER() OVER (
PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
) = 1, true, false) AS is_last_received_value
FROM `bigquery_project_id.analytics_XXXXX.events_*`
WHERE event_name in ('CLS', 'FID', 'LCP') AND
_TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
) WHERE is_last_received_value
)
# Main query logic
SELECT
page_path,
APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS CLS,
COUNT(1) as count
FROM (
SELECT
REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
FROM web_vitals_events
WHERE metric_name = 'CLS'
)
GROUP BY 1
HAVING count > 50 # Limit to relatively popular pages
ORDER BY CLS DESC
LIMIT 10
偵錯
上述查詢會說明如何查詢網站體驗指標指標資料，這有助於瞭解目前效能和一段時間內的趨勢。但是，如果成效低於預期，但您不確定原因為何，該怎麼辦？
如果您無法採取行動並修正問題，瞭解「分數」就沒有幫助。
「在欄位中進行偵錯」一文說明瞭如何將其他偵錯資訊與數據分析資料一起傳送。如果您按照該文章中詳述的操作說明執行，應該就會在 BigQuery 中看到偵錯資訊。
下列查詢說明如何使用 debug_target 事件參數，找出效能問題的根本原因。
查詢範例
影響 CLS 的主要元素
debug_target 是 CSS 選取器字串，對應網頁上與指標值最相關的元素。
使用 CLS 時，debug_target 代表最大的版面配置位移中，造成 CLS 值的最大元素。如果沒有移動任何元素，debug_target 值將會是 null。
下列查詢會根據 CLS，列出第 75 個百分位數由低至最佳的網頁列出，並以 debug_target 分組：
# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
SELECT *, IF (ROW_NUMBER() OVER (
PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
) = 1, true, false) AS is_last_received_value
FROM `bigquery_project_id.analytics_XXXXX.events_*`
WHERE event_name in ('CLS', 'FID', 'LCP') AND
_TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
) WHERE is_last_received_value
)
# Main query logic
SELECT
page_path,
debug_target,
APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS CLS,
COUNT(1) as count
FROM (
SELECT
REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = "debug_target") as debug_target,
ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
*
FROM web_vitals_events
WHERE metric_name = 'CLS'
)
GROUP BY 1, 2
HAVING count > 50 # Limit to relatively popular pages
ORDER BY CLS DESC
知道網頁上的哪些元素正在移動，如此應該就能更容易找出問題的根本原因並加以修正。
請注意，這裡回報的元素可能與您在本機偵錯網頁時看到的元素不同，因此一開始就擷取這些資料非常重要。我們很難修正自己沒有察覺的問題！
對其他指標進行偵錯
上述查詢顯示了 CLS 指標的結果，但相同的技術可用來回報 LCP 和 FID 的偵錯目標。只需將 location 子句替換為相關指標即可進行偵錯：
WHERE metric_name = 'CLS'
WHERE metric_name = 'LCP'
同樣地，您可以參閱在欄位中進行偵錯的效能，瞭解如何收集及傳送各個 Core Web Vitals 指標的偵錯資訊。
以圖表呈現
單單查看查詢結果可能很難取得深入分析結果。舉例來說，以下查詢會列出資料集中 LCP 的每日第 75 個百分位數值。
# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
SELECT *, IF (ROW_NUMBER() OVER (
PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
) = 1, true, false) AS is_last_received_value
FROM `bigquery_project_id.analytics_XXXXX.events_*`
WHERE event_name in ('CLS', 'FID', 'LCP') AND
_TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
) WHERE is_last_received_value
)
# Main query logic
SELECT
event_date,
metric_name,
APPROX_QUANTILES(ROUND(metric_value, 2), 100)[OFFSET(75)] AS p75
FROM
(
SELECT
event_date,
metric_name,
ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value'), 3) AS metric_value
FROM web_vitals_events
WHERE
metric_name = 'LCP'
)
GROUP BY
1, 2
ORDER BY event_date
從這些查詢結果中，要藉由查看資料就很難找出趨勢或離群值。
在這種情況下，以視覺化方式呈現資料可協助您更快取得深入分析結果。
在 Looker Studio 中以圖表呈現查詢結果
BigQuery 可讓您透過數據分析，以視覺化方式呈現任何查詢結果。Looker Studio 是可供免費使用的資料視覺化和資訊主頁工具。為了將查詢結果視覺化，請在 BigQuery UI 中執行查詢後，按一下「Explore Data」按鈕，然後選取「Explore with Looker Studio」。
即可在探索檢視畫面中，建立從 BigQuery 直接連至 Looker Studio 的連結。在這個檢視畫面中，您可以選取要視覺化的欄位、選擇圖表類型、設定篩選器，以及建立臨時圖表以快速進行視覺化分析。根據上述查詢結果，您可以建立以下折線圖，查看 LCP 值的趨勢變化：
在 BigQuery 和 Looker Studio 之間直接連結後，您就能從任何查詢建立快速圖表，並進行視覺化分析。不過，如果您想執行其他分析，可能需要在互動式資訊主頁中查看數個圖表，以便更全面地檢視畫面或下鑽細查資料。有了方便的資訊主頁，就不必在每次分析指標時編寫查詢並產生圖表。
您可以使用原生 BigQuery 連接器，在 Looker Studio 中建立資訊主頁。方法是前往 datastudio.google.com 建立新資料來源，選取 BigQuery 連接器，然後選擇要使用的資料集：
具體呈現網站體驗指標資料
按照上述方式建立網站體驗指標事件資料的資訊主頁時，直接使用 Google Analytics (分析) 4 匯出資料集並沒有效率。基於 GA4 資料的結構，以及網站體驗指標指標所需的預先處理作業，查詢的部分最終會執行多次。這會產生兩個問題：資訊主頁效能和 BigQuery 費用。
您可以免費使用 BigQuery 沙箱模式。如果是 BigQuery 的免費用量層級，每個月處理的前 1 TB 查詢資料免費。對於本文中討論的分析方法，除非您使用非常大型的資料集，或定期大量查詢資料集，否則每個月應可維持在這個免費上限內。不過，如果您有高流量網站，並希望使用快速的互動式資訊主頁定期監控不同的指標，建議您預先處理並將網站 Vitals 資料具體化，同時利用分區、分群和快取等 BigQuery 效率功能。
下列指令碼會預先處理您的 BigQuery 資料 (來源資料表)，並建立具體化資料表 (目標資料表)。對自己的資料集使用這項查詢時，建議您一併定義來源資料表的日期範圍，以降低處理的資料量。
# Materialize Web Vitals metrics from GA4 event export data
# Replace target table name
CREATE OR REPLACE TABLE bigquery_project_id.ga4_demo_dev.web_vitals_summary
PARTITION BY DATE(event_timestamp)
CLUSTER BY metric_name
AS
SELECT
ga_session_id,
IF(
EXISTS(SELECT 1 FROM UNNEST(events) AS e WHERE e.event_name = 'first_visit'),
'New user',
'Returning user') AS user_type,
IF(
(SELECT MAX(session_engaged) FROM UNNEST(events)) > 0, 'Engaged', 'Not engaged')
AS session_engagement,
evt.* EXCEPT (session_engaged, event_name),
event_name AS metric_name,
FORMAT_TIMESTAMP('%Y%m%d', event_timestamp) AS event_date
FROM
(
SELECT
ga_session_id,
ARRAY_AGG(custom_event) AS events
FROM
(
SELECT
ga_session_id,
STRUCT(
country,
device_category,
device_os,
traffic_medium,
traffic_name,
traffic_source,
page_path,
debug_target,
event_timestamp,
event_name,
metric_id,
IF(event_name = 'LCP', metric_value / 1000, metric_value) AS metric_value,
user_pseudo_id,
session_engaged,
session_revenue) AS custom_event
FROM
(
SELECT
(SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
AS ga_session_id,
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
AS metric_id,
ANY_VALUE(device.category) AS device_category,
ANY_VALUE(device.operating_system) AS device_os,
ANY_VALUE(traffic_source.medium) AS traffic_medium,
ANY_VALUE(traffic_source.name) AS traffic_name,
ANY_VALUE(traffic_source.source) AS traffic_source,
ANY_VALUE(
REGEXP_SUBSTR(
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location'),
r'^[^?]+')) AS page_path,
ANY_VALUE(
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'debug_target'))
AS debug_target,
ANY_VALUE(user_pseudo_id) AS user_pseudo_id,
ANY_VALUE(geo.country) AS country,
ANY_VALUE(event_name) AS event_name,
SUM(ecommerce.purchase_revenue) AS session_revenue,
MAX(
(
SELECT
COALESCE(
value.double_value, value.int_value, CAST(value.string_value AS NUMERIC))
FROM UNNEST(event_params)
WHERE key = 'session_engaged'
)) AS session_engaged,
TIMESTAMP_MICROS(MAX(event_timestamp)) AS event_timestamp,
MAX(
(
SELECT COALESCE(value.double_value, value.int_value)
FROM UNNEST(event_params)
WHERE key = 'metric_value'
)) AS metric_value,
FROM
# Replace source table name
`bigquery_project_id.analytics_XXXXX.events_*`
WHERE
event_name IN ('LCP', 'FID', 'CLS', 'first_visit', 'purchase')
GROUP BY
1, 2
)
)
WHERE
ga_session_id IS NOT NULL
GROUP BY ga_session_id
)
CROSS JOIN UNNEST(events) AS evt
WHERE evt.event_name NOT IN ('first_visit', 'purchase');
這種具體化資料集有幾個優點：
- 資料結構會經過簡化，且更容易查詢。
- 只會保留原始 GA4 資料集的網站體驗指標事件。
- 欄會直接顯示工作階段 ID、使用者類型 (新與回訪者) 和工作階段參與度資訊。
- 資料表會依日期partitioned，並依據指標名稱分群。這樣通常可以減少每項查詢處理的資料量。
- 由於您不需要使用萬用字元來查詢這個資料表，因此查詢結果在快取中最長可達 24 小時。這樣可以降低重複執行相同查詢的費用。
- 如果您使用 BigQuery BI 引擎，可以針對這個資料表執行最佳化 SQL 函式和運算子。
您可以直接在 BigQuery UI 中查詢這個具體化資料表，或是在 Looker Studio 中，透過 BigQuery 連接器使用該資料表。
使用 Web Vitals 連接器
由於從頭開始建立資訊主頁相當耗時，因此我們開發一套封裝解決方案，可為您建立範本資訊主頁。首先，請確認您已使用上述查詢具體化網站體驗指標表格。然後使用以下連結存取 Looker Studio 的 Web Vitals 連接器：goo.gle/web-vitals-connector
提供一次性授權後，您應該會看到下列設定畫面：
請提供具體化 BigQuery 資料表 ID (即目標資料表) 和 BigQuery 帳單專案 ID。按一下「連結」後，Looker Studio 就會建立新的範本資訊主頁，並將資料與資料建立關聯。您可以視需要編輯、修改及共用資訊主頁建立資訊主頁一次後，除非您想從不同的資料集建立多個資訊主頁，否則不需要再次造訪連接器連結。
瀏覽資訊主頁
瀏覽資訊主頁時，您可以在「Summary」分頁中查看 Web Vitals 指標的每日趨勢，以及網站使用資訊 (例如使用者和工作階段) 的部分使用資訊。
在「User Analysis」(使用者分析) 分頁中，您可以選取指標，然後取得指標百分位數的詳細資料，以及按照不同使用情形和業務指標區分的使用者人數。
「網頁路徑分析」分頁可協助您找出網站上的問題區域。您可以在此挑選指標來查看總覽。不過，您也可以看到所有網頁路徑的散佈圖，在 y 軸上有百分位數值，X 軸記錄次數。散佈圖有助您找出指標值低於預期的網頁。使用「Page path」(網頁路徑) 表格的散佈圖選取網頁後，請查看「Debug Target」(偵錯目標) 表格，進一步細查問題區域。
「收益分析」分頁範例說明如何在同一處監控業務和成效指標。這個部分顯示使用者完成購買的所有工作階段。您可以比較特定工作階段期間的收益與使用者體驗。
進階用法
熟悉資料集之後，您就可以編輯資訊主頁並新增自己的圖表，以更豐富而針對性分析。如要讓資訊主頁更加實用，您可以採取下列步驟：
- 在 BigQuery 中設定排程查詢以取得更新後的資料。我們執行上述的具體化查詢僅會拍攝當下的資料快照。如果您希望資訊主頁與新資料保持最新狀態，您可以執行每天執行的排程查詢，並使用新資料附加具體化資料表。
- 彙整第一方資料 (例如客戶關係管理系統)，取得業務洞察。在具體化資料表中，您可以將
user_id新增為獨立資料欄。這樣就能彙整第一方資料。如果 BigQuery 中還沒有第一方資料，您可以載入資料或使用聯合資料來源。 - 將網站或應用程式版本回報為傳送給 Google Analytics (分析) 的資料中的參數，並在具體化資料表中將其新增為資料欄。然後將該版本資料新增為圖表中的維度，更輕鬆地查看版本變更對效能的影響。
- 如果您預期透過直接查詢或資訊主頁來大量使用資料集，則可嘗試使用 BigQuery BI Engine 的付費版本。
摘要
本文涵蓋了使用 Google Analytics (分析) 4 和 BigQuery 的基本概念，說明如何使用 Google Analytics (分析) 4 和 BigQuery，根據透過該欄位收集到的實際使用者資料來評估效能並進行偵錯。以及如何使用 Looker Studio 和 Web Vitals Connector 建構自動化報表和資訊主頁，盡可能簡化資料視覺化作業。
本文重點如下：
- 想要瞭解、偵錯及最佳化網站，就必須利用實際使用者資料來評估成效。
- 當您的成效指標和業務指標位於同一個系統中時，您將可取得更深入的分析資訊。Google Analytics (分析) 和 BigQuery 就是做到這點
- BigQuery 原始 Google Analytics (分析) 資料匯出功能可讓您使用自己熟悉的查詢語言，進行深入的自訂分析。
- Google 提供多種 API 和視覺化工具 (例如 Looker Studio)，讓您按照自己偏好的方式建構報表。