雜訊插入

查詢資料庫時，雜訊插入技術可保護使用者隱私，運作方式是在查詢的 SELECT 匯總子句中加入隨機雜訊。在保護使用者隱私之餘，這個雜訊能還能提供合理準確的結果，為您省去進行差異檢查的麻煩，並降低取得結果所需達到的匯總門檻。目前大多數的查詢都能在雜訊模式下執行，但有一些限制。

瞭解使用雜訊插入功能的優點

無須進行差異檢查：如果在執行查詢時使用雜訊插入功能，廣告資料中心就不會因為與先前的結果集類似，而篩除資料列。換句話說，在保護使用者隱私的同時，資料仍能一覽無遺。

簡化疑難排解：系統只會基於匯總要求而略過資料列，疑難排解和調整查詢也將更輕鬆。

無須學習新的語法：您不必學習任何新的查詢語法，也不必精通隱私權概念，就能使用雜訊來取代差異檢查。

容易判斷結果是否準確：成功執行工作後，您會看到含有預期雜訊量的資料所占的總百分比。

瞭解雜訊對隱私權規定的影響

差異檢查：插入雜訊時，不必進行廣告資料中心現有的差異檢查，這類檢查會停用。

匯總要求：雜訊插入功能會輸出曝光資料 (以大約至少 20 位不重複使用者做為代表)，以及點擊或轉換資料 (以大約至少 10 位不重複使用者做為代表)。

靜態檢查：沒有任何影響。

預算和查詢限制：使用雜訊功能執行的查詢，會與差異檢查共用資料存取預算。與差異檢查一樣，如果對同一個資料集執行多次相同查詢，可能會失去查詢資料集中常用日期的權限。執行滑動區間查詢，或是多次發出同一項要求時，可能就會發生上述情況。

在查詢中或跨查詢重新計算相同的匯總結果時，雜訊模式會施加更嚴格的額外限制。與資料存取預算一樣，您可能會失去查詢資料集中常用日期的權限；但是重新計算相同的匯總結果而產生的限制，只會限制雜訊模式中的查詢，不會限制差異檢查模式中的查詢。詳情請參閱「重複結果」一節。

如要進一步瞭解隱私權檢查，請參閱本文。

瞭解雜訊插入功能對結果的影響

廣告資料中心會插入雜訊來降低資料外洩的風險，防止他人取得個別使用者的相關資訊，在保護隱私和實用之間取得平衡。

廣告資料中心的雜訊插入功能會轉換查詢結果，方法如下：

• 對離群使用者在匯總結果中所占的資料量限制取值範圍，亦即加總每位使用者在每項匯總作業中所占的資料量，然後為每位使用者所占的資料量設定取值範圍的上下限。
• 匯總已限制取值範圍的每位使用者所占資料量。
• 在每筆匯總結果 (每個資料列中每次匯總函式呼叫的結果) 中加入雜訊。這個隨機雜訊的規模，與限制取值範圍的上下限成比例。
• 計算每個資料列套用雜訊的使用者人數，刪除使用者過少的資料列。這類似於差異檢查模式中的 k-anonymity，但在相同資料集中執行的作業，可能會因為雜訊而刪除不同的資料列。此外，雜訊模式的匯總要求較低 (大約 20 列，而不是整整 50 列)，因此刪除的資料列較少。

最終結果是一個資料集，其中每個資料列的匯總結果都套用雜訊，且刪除人數較少的群體，個別使用者對傳回結果的影響就不會顯現出來。

關於匯總取值範圍限制

廣告資料中心的雜訊插入功能，會採用隱性或顯性匯總取值範圍限制，藉此限制離群使用者所占的資料量。您可以根據自身的使用情況，選擇要採用哪一種取值範圍限制。

隱性取值範圍限制

如果是隱性取值範圍限制，系統會自動決定上下限。您不必使用任何特別的 SQL 語法，就能套用隱性取值範圍限制。如果某個資料列的值範圍大於另一個資料列，隱性取值範圍限制會為這兩列指定不同的上下限，這樣通常可以縮小每筆結果的誤差範圍。另一方面，每項匯總作業都有不同的取值範圍上下限和雜訊等級，可能導致難以進行比較。

要是匯總時擷取資料的來源使用者人數過少 (例如在罕見條件下呼叫 COUNTIF())，隱性取值範圍限制可能會無法發揮作用，此時系統會傳回 NULL 結果。另請注意，COUNT(DISTINCT user_id) 會自動使用顯性取值範圍限制，上下限介於 0 和 1 之間。

顯性取值範圍限制

顯性取值範圍限制會將每位使用者所占的總資料量限制在指定範圍內。顯性上下限會一致套用到所有資料列，而且必須為常值。即使某些資料列每位使用者所占資料量的範圍較大，也會一致套用相同的上下限。因此，便可更容易地比較不同資料列，但某些資料列的雜訊可能會比採用隱性取值範圍限制時更多。

以任何一組取值範圍上下限而言，顯性取值範圍限制使用的雜訊量，都只有隱性取值範圍限制的一半。因此，如果您可以估算出合理的上下限，則將取值範圍限制設為顯性會獲得更好的結果。

如要使用顯性取值範圍限制，請為每個支援的匯總函式設定上下限，並分別加入整數來代表下限和上限。例如：

SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1

使用雜訊插入功能執行查詢

1. 撰寫查詢或開啟現有查詢。如要瞭解有哪些匯總函式可用，請參閱「支援的函式」一節。
2. 在查詢編輯器中按一下「執行」，為新工作輸入詳情。
3. 按一下「隱私權設定」切換鈕，撥到「使用雜訊」的位置。
4. 執行查詢。
5. 查看加入的雜訊。
6. 選用步驟：調整查詢，減少雜訊造成的影響。

查看雜訊造成的影響

成功完成查詢後，廣告資料中心會根據輸出結果有多少儲存格含有預期雜訊量，來顯示結果的可靠性。如果加入的雜訊量超過儲存格內所顯示結果的 5%，就表示結果資料表中的值受到大幅影響。請參閱下表中的影響範圍。

對於受影響的輸出資料集，「詳情」分頁會按照影響程度由高到低的順序，列出雜訊最多的前 10 個資料欄，以及這些資料欄相對於雜訊的影響。以下詳細列出雜訊量符合預期的情況。

雜訊量符合預期的資料	代表色	影響
>95%	綠色	影響程度低
85%-95%	黃色	影響程度普通
75%-85%	橘色	影響程度高
<75%	紅色	影響程度非常高

如要進一步瞭解雜訊所造成的影響，請按照下列步驟操作：

1. 按一下「報表」。
2. 從清單中選取報表。隱私摘要工具提示會指出雜訊量符合預期的結果所占的百分比 (指出加入的雜訊量是否超出結果的 5%)。
3. 如要查看更多資訊，請按一下「工作」>「詳情」
4. 在工作詳情中查看「隱私權訊息」，其中會列出結果所屬的類別。
5. 視需要調整查詢來提高結果的準確度。

調整查詢

如果對匯總結果產生影響的使用者人數不多，結果會更有可能含有不符預期的雜訊量。倘若資料列納入計算的使用者人數不多，或是部分使用者不會影響結果 (例如使用 COUNTIF 函式時)，可能就會發生上述情況。建議您根據雜訊詳情調整查詢，提高雜訊量符合預期的資料所占的百分比。

一般準則如下：

• 擴大日期範圍。
• 改寫查詢來降低資料精細程度，例如減少做為分組依據的參數，或是使用 COUNT 取代 COUNTIF。
• 移除套用雜訊的資料欄。
• 使用顯性取值範圍限制。

---

支援的匯總函式

系統支援搭配雜訊使用下列匯總函式：

• SUM(...)
• COUNT(*)
• COUNT(...)
• COUNTIF(...)
• COUNT(DISTINCT user_id)
• APPROX_COUNT_DISTINCT(user_id)
• AVG(...)

DISTINCT 關鍵字的使用條件有兩個，一是必須搭配 COUNT 函式，二是直接參照廣告資料中心資料表的 user_id 資料欄，或是會傳回 user_id 或 NULL 的運算式，例如 COUNT(DISTINCT IF(..., user_id, NULL))。

系統不直接支援下列函式，但可換成套用雜訊的其他匯總函式，以算出統計結果。請注意，這裡的數值僅供參考：

• LOGICAL_OR(...)。建議的替換函式：COUNT(DISTINCT IF(..., user_id, NULL)) > 0
• LOGICAL_AND(...)。建議的替換函式：COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

關於整數結果

雖然廣告資料中心會自動為這些匯總函式插入雜訊，但函式簽章不會改變。INT64 的 COUNT 或 SUM 等函式會傳回 INT64，因此結果插入雜訊後，所有小數部分都會四捨五入。相對於結果和雜訊的規模，這種捨去通常可以忽略不計。

如要查看結果中精細的小數部分，請避免撰寫會傳回 INT64 的函式，例如使用 SUM 並將輸出結果轉換為 FLOAT64。

---

支援的查詢模式

重要事項：廣告資料中心提供的大部分標準最佳做法，仍適用於插入雜訊的查詢。我們尤其建議您查看有關重複查詢相同資料的指南。

本節說明使用雜訊插入功能執行查詢時支援的查詢模式。

使用者層級匯總

不受限使用者層級匯總受到的支援，與差異檢查模式下受到的支援相同。匯總在合併多位使用者的資料時，才會插入雜訊。明確按 user_id 分組的匯總作業 (亦即按 user_id 區分的分析函式) 不會收到任何雜訊，且可以使用任何函式。未明確按 user_id 分組的使用者層級匯總作業 (例如 GROUP BY impression_id)，則會視為跨使用者進行匯總，因此會加入雜訊。

按 external_cookie 分組還不夠。雖然 external_cookie 可用於彙整 *_match 資料表和客戶擁有的資料表，但任何單一使用者匯總作業都應明確按 user_id 欄分組，而不僅僅是按 external_cookie 欄分組。

匯總函式範例：

WITH user_paths AS (
  # Grouping by user_id, no noise needed, all functions allowed
  SELECT user_id, STRING_AGG(campaign_id, ">" ORDER BY query_id.time_usec) AS path
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to num_users
SELECT path, COUNT(*) AS num_users
FROM user_paths
GROUP BY 1;

分析函式範例：

WITH events AS (
  # Partitioning by user_id, no noise needed, all functions allowed
  SELECT
    campaign_id,
    ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY query_id.time_usec) AS index
  FROM adh.google_ads_impressions
)
# Noise applied here to first_impressions
SELECT campaign_id, COUNT(*) AS first_impressions
FROM events
WHERE index = 1
GROUP BY 1;

平行匯總

每項跨使用者匯總作業各自會套用雜訊。一個陳述式可以進行多項此類匯總，並使用 JOIN 或 UNION 將結果併入一份資料表。

範例：

WITH result_1 AS (
  # Noise applied here to num_impressions
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
  GROUP BY 1
), result_2 AS (
  # Noise applied here to num_clicks
  SELECT campaign_id, COUNT(*) AS num_clicks
  FROM adh.google_ads_clicks
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

請注意，雖然可以這樣做，但在差異檢查模式下建議避免。這種做法在雜訊方面不構成問題，因為每項平行匯總作業會各自套用雜訊並進行篩選。

經過匯總的資料與未經匯總的資料彙整

注意：每項匯總作業會各自插入雜訊，因此總值可能不會一致。在這種情況下，特定 campaign_id 的 imps 總和值，可能與 campaign_imps 的相應值不一致。

廣告資料中心僅支援按 user_id 劃分的分析區間，因此常見的處理方法是先個別匯總這些結果並自行進行彙整，然後再匯總一次。這類查詢可在雜訊模式下進行，且隱私權規定的問題已先解決，因此成效通常也會比在差異檢查模式下進行時更好。

例子：

WITH campaign_totals AS (
  # Noise applied here to campaign_imps
  SELECT campaign_id, COUNT(*) AS campaign_imps
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3

雜訊模式禁止對匯總結果進行重新匯總，例如 AVG(campaign_imps)。

---

不支援的查詢模式

本節說明使用雜訊插入功能執行查詢時不支援的查詢模式。

包含今日在內的查詢

雜訊模式查詢不支援查詢當日資料 (不建議在差異檢查模式中採取這種做法)。如果查詢時使用雜訊插入功能，就無法選取當日。

重複結果

在雜訊模式下，廣告資料中心會限制可重複進行同一項匯總的頻率。如果達到這些限制，雜訊模式查詢會失去查詢資料集中常用日期的權限。以下是發生這種情形的其中幾個原因。

查詢重複是指以相同或類似參數多次執行相同查詢，例如日期範圍重疊。如要避免這個問題發生，您可以使用已匯出至 BigQuery 專案的資料。

請注意，如果兩項工作查詢的日期範圍重疊，那麼在對相同使用者進行相同的運算時，可能就會造成重複。舉例來說，如果對重疊的日期範圍執行下列查詢，由於是以日期做為劃分依據，因此會造成重複：

SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1

在這種情況下，建議您對沒有交集的日期範圍執行查詢。

在另一種造成重複的情況中，資料不受日期的影響。對重疊的日期執行下列查詢時，會造成重複，因為兩項工作都涵蓋廣告活動的整個生命週期：

SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1

在這種情況下，建議您只執行一次這項查詢，因為結果不變。

匯總重複是指一項查詢多次進行相同的匯總：

SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table

在這種情況下，建議您移除其中一項重複的匯總作業。

請注意，即使匯總作業在語法上不同，但只要計算的是同一個值，同樣也可能會視為重複。換句話說，如果值為 key 的所有使用者的 condition1 和 condition2 值都相同，下列查詢可能會造成重複：

SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key

如果您為某幾組使用者設定的條件非常類似，不妨將查詢改寫為只有一個 COUNT。

資料列重複是指廣告資料中心資料表與 BigQuery 資料表彙整，使得前者的每個資料列都與後者的多個資料列一致。舉例來說，如果 bq_table 中有多個資料列的廣告活動 ID 都相同，下列查詢就會造成重複：

SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id

在這種情況下，建議您調整查詢的結構，讓 bq_table 的每個彙整鍵值 (這裡是指 campaign_id) 只有一列。

請注意，如果解除廣告資料中心資料表中陣列的巢狀結構，而大多數使用者具有相同的值陣列，可能也會產生相同的影響。

SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1

如要進一步瞭解其他查詢最佳做法，請參閱本文。

直接重新匯總

查詢中的第一層跨使用者匯總作業會套用雜訊。系統會封鎖有多層匯總作業的查詢：

WITH layer_1 AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

如果希望雜訊帶來最準確的結果，請計算單次匯總中的所有跨使用者作業。舉例來說，請對事件進行 SUM，而不要對中繼計數進行 SUM。您可以改寫查詢來重新匯總套用雜訊的匯總作業，但最終的匯總作業可能包含更多雜訊。

如果無法避免，您可以改寫查詢，直接從第一層匯出結果。如果只想在一項工作內執行上述操作，但希望指令碼結果維持不變，請以 OPTIONS(privacy_checked_export=true) 語法建立臨時資料表 (或匯出至 BigQuery 專案的資料表)：例如：

CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

如要進一步瞭解臨時資料表，請參閱本文。

如果第一層匯總作業太過精細，而無法執行隱私權檢查，不妨運用使用者層級匯總改寫查詢：如果不可行，就表示雜訊模式不支援這項查詢。

未經彙整的使用者 ID

在雜訊模式下執行查詢時，不得將個別使用者的資料併入一個資料列，除非是執行套用雜訊的匯總。因此，如要明確對 user_id 資料欄進行彙整，就必須先彙整未經匯總的廣告資料中心資料。

這項查詢並未明確對 user_id 資料欄進行彙整，造成驗證錯誤：

SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_id)

如要修正這項錯誤，您可以調整 USING 子句來明確包含 user_id，例如 USING(impression_id, user_id)。

請注意，這項限制僅適用於彙整廣告資料中心資料表 (維度資料表除外)，不適用於客戶擁有的資料表。舉例來說，我們允許：

SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)

廣告資料中心與 BigQuery 聯集

套用雜訊的匯總作業要有效執行，就不能缺少使用者 ID。在 BigQuery 中，客戶擁有的資料沒有使用者 ID，因此必須先與廣告資料中心資料表彙整，才能與套用雜訊的匯總作業建立聯集。

這項查詢會產生驗證錯誤：

SELECT COUNT(*) FROM (
  SELECT 1 FROM adh.google_ads_impressions
  UNION ALL
  SELECT 1 FROM bigquery_project.dataset.table
)

如要修正這項錯誤，請彙整 BigQuery 資料表來擴增廣告資料中心資料，不要建立聯集；或者，您也可以拆分資料，分別匯總每個來源。

請注意，您可以針對包含使用者資料的多個廣告資料中心資料表，或是客戶擁有的多個 BigQuery 資料表建立聯集，但無法將兩者混合。

正確彙整廣告資料中心與 BigQuery

如果與客戶擁有的資料進行外部彙整，可能會導致資料列缺少使用者 ID，使得雜訊無法正常運作。

這兩項查詢都允許廣告資料中心端有缺少使用者 ID 的不一致資料列，因此會產生驗證錯誤：

SELECT …
FROM adh.google_ads_impressions
RIGHT JOIN bigquery_project.dataset.table USING(column)

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions USING(column)

請注意，如果將資料表的順序反轉過來，就能進行任一彙整。

篩除資料列摘要

雜訊模式不支援篩除資料列摘要規格。如果已經套用雜訊，這項功能通常最沒有使用的必要，因為篩選率較低，而且差異檢查不會進行篩選。

如果您在套用雜訊的結果中發現大量資料經過篩選，請增加匯總資料。您可以對整個資料集進行平行匯總，來比較總計的預估值，例如：

SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1

請注意，總數會獨立套用雜訊，而總值可能不會累加，但總數通常比套用雜訊的資料列總和更準確。

跨模式建立的資料表

廣告資料中心內未匯出的資料表，只能搭配建立時採用的隱私權模式使用。您無法在一般的匯總模式下，建立資料表並用於雜訊模式，反之亦然 (除非先將該資料表匯出至 BigQuery)。