ノイズ インジェクション

ノイズ インジェクションは、データベースにクエリを実行する際にユーザーのプライバシーを保護するために使用される技術です。これは、クエリの集計 SELECT 句にランダムノイズを追加することで機能します。このノイズによりユーザーのプライバシーが保護される一方で、ある程度の正確な結果が得られ、差分チェックの必要性がなくなり、出力に必要な集計しきい値が削減されます。いくつかの制限があるものの、既存のクエリのほとんどはノイズモードで実行できます。

重要: Ads Data Hub の MRC 認定は、ノイズモードで実行されるクエリには適用されません。

ノイズ インジェクションを使用する利点を学ぶ

差分チェックが適用されない: ノイズ インジェクションを使用してクエリを実行すると、前の結果セットとの類似性による行のフィルタリングが行われません。この特長により、ユーザーのプライバシーを保護しながら、包括的なデータを取得できます。

トラブルシューティングが簡素化される: 行は集計要件によってのみ省略されるため、クエリのトラブルシューティングと調整が簡単になります。

新しい構文を学習する必要がない: 差分チェックの代わりにノイズを使用するために、新しいクエリ構文を学習したり、プライバシー概念に精通したりする必要はありません。

結果の精度が報告される: ジョブが成功すると、ノイズの影響を受けた可能性のあるデータの合計パーセンテージが表示されます。

ノイズがプライバシー要件に与える影響を学ぶ

差分チェック: ノイズ インジェクションは、Ads Data Hub の既存の差分チェックに依存しません。ノイズ インジェクションを使用する場合、差分チェックは無効になります。

集計要件: ノイズ インジェクションでは、インプレッション データを出力するには約 20 人以上のユニーク ユーザー、クリックデータまたはコンバージョン データを出力するには約 10 人以上のユニーク ユーザーが必要です。

静的チェック: 影響はありません。

予算とクエリ制限: ノイズを使用して実行されたクエリは、差分チェックで使用されるデータアクセス予算を共有します。差分チェックと同様に、同じデータセットに対して同じクエリを何度も実行すると、データセット内の頻繁にクエリされる日付にアクセスできなくなる可能性があります。これは、スライディング ウィンドウ クエリを実行する場合、または同じリクエストを複数回実行する場合に発生する可能性があります。

ノイズモードでは、クエリ内またはクエリ間で同じ集計結果を再計算する場合に、さらに厳しい制限が課されます。データアクセス予算と同様に、データセット内の頻繁にクエリされる日付にアクセスできなくなる可能性があります。ただし、同じ集計結果を再計算することによる制限は、ノイズモードのクエリのみに適用され、差分チェックモードのクエリには適用されません。詳しくは、繰り返し結果をご覧ください。

プライバシー チェックについて詳しくは、こちらをご覧ください。

ノイズ インジェクションが結果に与える影響を理解する

Ads Data Hub では、開示リスク（個人ユーザーに関する情報が第三者に知られるリスク）を軽減するために、プライバシーと実用性のバランスをとりながらノイズが注入されます。

Ads Data Hub のノイズ インジェクションにより、クエリ結果が次のように変換されます。

• 集計結果における「外れ値」ユーザーの貢献度を境界内に収めます。各集計における各ユーザーの貢献度を合計し、最小および最大のクランプ境界に各貢献度が収まるようにします。
• 範囲内にあるユーザーごとの貢献度を集計します。
• 各集計結果（各行の各集計関数呼び出しの結果）にノイズが追加されます。このランダムノイズのスケールは、クランプ境界に比例します。
• ノイズが加えられた各行のユーザー数が集計され、ユーザー数が少なすぎる行が削除されます。これは差分チェックモードの k-匿名性と似ていますが、ノイズを使用しているため、同じデータセット上で実行されているジョブにより異なる行が削除される可能性があります。 また、ノイズモードでは、集計要件が低い（正確に 50 行ではなく約 20 行）ため、削除される行が少なくなります。

最終結果となるデータセットでは、ノイズが加えられた各行が集計され、小さなグループが除外されています。これにより、返された結果で個々のユーザーの影響がマスクされます。

集計クランプについて

Ads Data Hub のノイズ インジェクションでは、暗黙的または明示的な集計クランプを使用して、外れ値の貢献度を制限します。ユースケースに応じて、使用するクランプのタイプを選択できます。

暗黙的なクランプ

暗黙的なクランプを使用するために特別な SQL 構文は必要ありません。デフォルトで適用されます。暗黙的な境界はデータ自体から導出され、集計ごとに決定されます。一部の集計値の範囲が他の集計値の範囲よりも広い場合、暗黙的な境界では必要に応じて集約ごとに異なる境界を推測できます。これにより、通常、エラーが少なくなります。1 の上限を持つ明示的なクランプが COUNT(DISTINCT user_id) で自動的に使用されることに注意してください。

明示的なクランプ

明示的なクランプでは、指定された範囲内に各ユーザーからの合計貢献度が収められます。明示的な境界（リテラル値で設定）は、すべての集計に均一に適用されます。境界が一般的にわかっている場合は、明示的なクランプの方が良い結果が得られることがあります。たとえば、0〜100 の境界の年齢は、ほとんどの人の年齢がこの範囲内にあるため、公開情報が反映されます。

Ads Data Hub には、明示的なクランプ用の追加のADH.ANON集計関数が用意されています。明示的なクランプを使用するには、下限と上限を表す整数を追加して、サポート対象の各集計関数の境界を設定します。次に例を示します。

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. 省略可: クエリを調整して、ノイズの影響を軽減します。

ノイズの影響を確認する

ジョブが正常に完了すると、プライバシーの概要に結果の信頼性が表示されます。信頼性は、ノイズの影響を大きく受ける可能性のある出力内のセルの割合に基づきます。結果テーブルの値に追加されたノイズのスケールがセル内の結果の 5% を超える場合、その値は影響を受けていると見なされます。

影響を受けている出力データセットのプライバシーの概要には、影響が最も大きい列から順番にノイズが最も多い 10 列が、それに対応するノイズへの貢献度とともにリストされます。以下の表は、ノイズの影響ラベルの内訳です。

影響を受けた結果の割合（%）	インジケーターの色	効果
5% 未満	緑	影響が小さい
5%～ 15%	黄	影響が中程度
15%～ 25%	Orange	大規模な影響
25% 以上	赤	影響が非常に大きい

[ホーム] ページで、最近のレポート ジョブのプライバシーの概要をプレビューすることもできます。特定のジョブのプライバシーをプレビューするには、[最近のアクティビティ] のジョブカードにあるプライバシーのヒント アイコン privacy_tip にカーソルを合わせます。

クエリを調整する

集計結果に貢献するユーザーがほとんどいない場合、集計はノイズの影響を受けやすくなります。これは、小規模なユーザーセットから集計が計算される場合や、一部のユーザーが結果に影響を与えない場合（COUNTIF 関数を使用する場合など）に発生する可能性があります。ノイズレポートに基づいてクエリを調整することで、影響を受ける結果の割合を減らすことができます。

一般的なガイドラインは次のとおりです。

• 期間を延長します。
• グループ化の基となるパラメータの数を減らしたり COUNTIF を COUNT で置き換えたりすなど、クエリを書き直してデータの粒度を下げます。
• ノイズの多い列を削除します。
• 妥当な境界を選択できる場合は、明示的なクランプを試してください。

---

サポート対象の集計関数

次の集計関数ではノイズの使用がサポートされています。

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

DISTINCT キーワードは、COUNT 関数でのみサポートされています。また、Ads Data Hub テーブルの user_id 列への直接参照、または user_id か NULL を返す式（COUNT(DISTINCT IF(..., user_id, NULL)) など）でのみ使用する必要があります。

これらの制限は、ノイズを含む集計（クロスユーザー集計の第 1 レベル）にのみ適用されます。ユーザーレベルの集計とノイズ注入後の集計には制限がありません。

補足的な集計関数

Ads Data Hub では、通常の集計関数に加えて、明示的なクランプをサポートする補足的な ADH.ANON 集計関数が導入されています。これらのアグリゲータは、BigQuery の差分プライベート集計関数と同じ構文を使用しますが、WITH DIFFERENTIAL_PRIVACY 句は必要ありません。

• ADH.ANON_SUM( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_COUNT( *, [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_COUNT( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_AVG( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

• ADH.ANON_PERCENTILE_CONT( ..., percentile, contribution_bounds_per_row => (lower_bound, upper_bound) )

ADH.ANON_SUM、ADH.ANON_COUNT、ADH.ANON_AVG パラメータ:

• contribution_bounds_per_group: ユーザーあたりの貢献度は、GROUP BY キーで定義された各パーティションに対してクランプされます。上限と下限は、ユーザーごとに値が集計された後、グループごとに値に適用されます。
• lower_bound: 集計に含める最小値を表す数値リテラル。
• upper_bound: 集計に含める最大値を表す数値リテラル。

ADH.ANON_PERCENTILE_CONT パラメータ:

• percentile: 計算するパーセンタイル。[0, 1] の範囲内のリテラル。
• contribution_bounds_per_row: ユーザーあたりの貢献度は、行ごと（レコードごと）にクランプされます。パーセンタイルには明示的なクランプ境界が必要であるため、補助関数としてのみサポートされます。
• lower_bound: 集計に含める最小値を表す数値リテラル。
• upper_bound: 集計に含める最大値を表す数値リテラル。

最小値と最大値を計算する

MIN 関数と MAX 関数はノイズ集計で直接サポートされていませんが、これらの結果を計算する代替方法が用意されていることがよくあります。

イベント日などのグループ化キーとして使用できる値の MIN または MAX がある場合は、まずその値で GROUP BY を実行してから、MIN/MAX を計算できます。これにより、集計のしきい値を超える最小値または最大値が返されます。

例:

WITH campaign_date_ranges AS (
  SELECT campaign_id, MIN(event_date) AS min_date, MAX(event_date) AS max_date
  FROM (
    # Aggregation thresholding will be applied here
    SELECT DISTINCT
      campaign_id,
      DATE(query_id.time_usec, @time_zone) AS event_date
    FROM adh.google_ads_impressions
  )
)
SELECT campaign_id, num_impressions, min_date, max_date
FROM (
  # Noise and aggregation thresholding will be applied here
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
)
JOIN campaign_date_ranges USING(campaign_id)

また、境界がわかっている粒度の値の MIN または MAX がある場合は、PERCENTILE_CONT と明示的な境界を使用して、近似結果を取得できます。

例:

SELECT
  campaign_id,
  COUNT(*) AS num_impressions,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 0,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS min_timestamp,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 1,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS max_timestamp
FROM adh.google_ads_impressions

整数の結果について

Ads Data Hub は上記の集計関数に自動的にノイズを挿入しますが、関数の署名は変更されません。INT64 の COUNT や SUM などの関数は INT64 を返すため、ノイズが含まれた結果の小数部分は四捨五入されます。丸められた数値は通常、結果とノイズのサイズに比べると無視できる程度のものです。

結果に小数点の粒度が必要な場合は、INT64 を返す関数を作成せずに、たとえば、入力を FLOAT64 にキャストする SUM を使用します。

負の結果について

原則として、値が非常に小さいノイズは、クエリで意味的に不可能である場合でも、負の数になる可能性があります。期待される動作を維持するため、COUNT と COUNTIF のすべての形式は自動的にゼロにクランプされるため、負の結果が返されることはありません。SUM などの別の関数で同じ動作が必要な場合は、GREATEST(0, SUM(...)) を使用して結果を手動でクランプできます。

通常、この変更は無視できる程度ですが、全体的な結果にわずかな正のバイアスが生じます。

---

サポートされているクエリパターン

重要: Ads Data Hub のほとんどの標準的なベスト プラクティスは、ノイズ インジェクションを使用するクエリにも適用されます。特に、同じデータの繰り返しクエリに関するガイダンスをご確認ください。

このセクションでは、ノイズ インジェクションを使用してクエリを実行するときにサポートされるクエリパターンについて説明します。

ユーザーレベルの集計

ユーザーレベルでの無制限の集計は、差分チェックモードの場合と同じ方法でサポートされます。ノイズは、複数のユーザーにわたるデータを結合する集計にのみ注入されます。user_id で明示的にグループ化する集計、または user_id でパーティショニングする分析関数はノイズを受け取らず、どの関数も許可されます。user_id ごとに明示的にグループ化されていないユーザーレベルの集計（例: GROUP BY impression_id）は、ユーザー間の集計として扱われるため、ノイズが追加されます。

external_cookie ごとにグループ化するだけでは十分ではありません。external_cookie を使用して *_match テーブルと顧客所有のテーブルを結合することはできますが、単一ユーザーの集計は、external_cookie 列だけでなく user_id 列で明示的にグループ化する必要があります。

集計関数の例:

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;

並行集計

クロスユーザーの各集計は、独立してノイズを受け取ります。このような複数の集計は、1 つのステートメントで実行し、JOIN または UNION を使用して結果を 1 つのテーブルに結合できます。

例:

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_creative_conversions
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

この集計は、差分チェックモードでは回避する必要がありますが、ノイズモードでは各並行集計は個別にノイズ処理とフィルタ処理が行われるため、問題となりません。

未集計データと結合された集計データ

注: 各集計は個別にノイズを受け取るため、合計値が一致しない可能性があります。この場合、特定の campaign_id の imps 合計値が、対応する campaign_imps の値と一致しない場合があります。

Ads Data Hub では 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) などの集計結果の再集計が推奨されていません。

---

サポートされていないクエリパターン

このセクションでは、ノイズ インジェクションを使用するクエリ実行でサポートされていないクエリパターンについて説明します。

当日のデータのクエリ

ノイズモード クエリでは、当日のデータのクエリはサポートされていません。（差分チェックモードでは推奨されていません）。現在の日付は、ノイズ インジェクションを使用するクエリでは選択できません。

繰り返し結果

Ads Data Hub のノイズモードでは、同じ集計を繰り返す頻度が制限されています。この制限に達すると、データセット内の頻繁にクエリされる日付にノイズモード クエリを実行できなくなる可能性があります。以下は、この問題がどのように発生するかを示す例です。

クエリの繰り返しは、期間の重複など、同じパラメータまたは非常に類似したパラメータを使用して同じクエリが複数回実行される場合に発生します。これは、すでに BigQuery プロジェクトにエクスポートされているデータを使用することで回避できます。

2 つのジョブが重複する期間をクエリしている場合、同じユーザーに対して同じ計算を実行すると、繰り返しが発生する可能性があります。たとえば、重複する期間に対して実行される次のクエリは、日付でパーティショニングされているため、繰り返しが発生します。

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

この場合、重複していない日付セグメントに対してクエリを実行する必要があります。

繰り返しが発生する別の例は、データが日付にあまり依存していない場合です。 次のクエリは、キャンペーンの全期間をカバーしている 2 つのジョブを重複する日付に実行すると、繰り返しが生成されます。

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

この場合、結果は変わらないため、このクエリは 1 回だけ実行する必要があります。

集計の繰り返しは、クエリ内で同じ集計が複数回繰り返される場合に発生します。

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

この場合、いずれかの繰り返しを削除する必要があります。

なお、集計が構文的に異なっていても同じ値を計算するなら、繰り返しとしてカウントされます。つまり、condition1 と condition2 の値が key の値を持つすべてのユーザーで同じである場合、次のクエリは繰り返しになります。

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

ユーザー グループで非常によく似た条件がある場合は、COUNT を 1 つだけ持つようにクエリを書き直してください。

行の重複は、Ads Data Hub テーブルの各行が BigQuery テーブル内の複数の行と一致するような方法で、Ads Data Hub テーブルが BigQuery テーブルと結合されるときに発生します。たとえば、次のクエリでは、同じキャンペーン ID を持つ行が bq_table に複数ある場合に繰り返しが生成されます。

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

この場合、結合キー値（この場合は campaign_id）ごとに 1 行だけ bq_table に含まれるようにクエリを再構築する必要があります。

ほとんどのユーザーが同じ値の配列を持っている場合に、Ads Data Hub テーブルから配列のネストを解除すると同じ結果が生じる可能性があります。

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

クエリの他のベスト プラクティスについては、こちらをご覧ください。

ルックバック ウィンドウについて

クエリ パターンによっては、長期間にわたるレポートが生成され、新しい結果を含めるために定期的に再生成されます。これらのクエリは、ノイズモードで動作するように調整する必要がある場合があります。これは、以前の結果を再計算するとブロックされるためです。代わりに、各ジョブで新しい結果のみを生成し、新しい結果を前のジョブの結果と組み合わせて完全なレポートを作成する必要があります。

たとえば、日付別に指標のレポートを作成し、毎日更新する場合:

SELECT
  campaign_id,
  DATE(TIMESTAMP_MICROS(query_id.time_usec), @time_zone) AS event_date,
  COUNT(*) AS impressions
FROM adh.google_ads_impressions
GROUP BY 1,2

過去の結果が再計算されるため、このコマンドを大きな日付範囲で実行しないでください。代わりに、新しいデータを含む最新の日にのみ各ジョブを実行し、前のジョブの結果と組み合わせる必要があります。

以前の結果を更新する必要がある場合（遅れて到着したデータを考慮する場合など）は、1 つの結果を 2 回以上再計算しないようにする必要があります。そうしないと、クエリの試行が繰り返されるため、エラーが発生する可能性があります。

直接再集計

ノイズは、クエリ内のクロスユーザー集計の最初のレイヤに適用されます。 複数の集計レイヤを含むクエリでは、ノイズのある結果が結合されるため、最終的な集計にはノイズがかなり多くなる可能性があります。これらのクエリでは、検証時に警告が表示されます。

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 を取得します。

多層集計が避けられない場合は、代わりに最初のレイヤから結果を直接エクスポートすることで、警告を解決できます。スクリプトの結果を変更せずにこれを 1 つのジョブ内で行うには、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

ノイズモードのクエリでは、ノイズを使用して集計を実行する場合を除き、別々のユーザーからのデータは 1 つの行に結合されません。そのため、未集計の Ads Data Hub データを結合する場合は、user_id 列で明示的に結合する必要があります。

以下のクエリは user_id 列に対して明示的に結合していないため、検証警告が発生します。

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

このような結合は、同じ user_id 値を持つ行のみが一致するため、期待どおりに動作しない可能性があります。このエラーは、USING 句を調整して user_id を明示的に含めること（例: USING(impression_id, user_id)）で修正できます。

なお、この制限は Ads Data Hub テーブル間の結合にのみ適用されます（ディメンション テーブルを除く）。顧客所有のテーブルには適用されません。たとえば、次は許可されています。

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

Ads Data Hub と BigQuery の右結合

顧客所有データとの外部結合では、ユーザー識別子が欠落している行が発生する可能性があり、そうなるとノイズが適切に機能しなくなります。

以下のクエリでは、Ads Data Hub 側でユーザー識別子が欠落している不一致の行が許可されるため、どちらのクエリでも検証警告が発生します。

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)

なお、テーブルの順序が逆であったとしたら、どちらの結合も機能します。device_id_md5 で直接結合する RDID テーブルにも例外があります。たとえば、次のクエリは警告なしで動作します。

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)

フィルタされた行の概要

フィルタされた行の概要仕様は、ノイズモードではサポートされていません。ノイズモードではフィルタリング レートが低く、差分チェックによるフィルタリングが発生しないため、ほとんどの場合この機能は不要です。

ノイズ結果で重要なデータ フィルタリングが観察された場合は、集計データを増やします。データセット全体に対して並行集計を実行して、合計の推定値を比較できます。次に例を示します。

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

合計数には独立してノイズが含まれており、合計値が加算されない場合がありますが、多くの場合、ノイズが含まれた行の合計を取得するよりも合計数の方が正確になります。

クロスモードで作成されたテーブル

エクスポートされていない Ads Data Hub テーブルは、テーブルが作成されたときと同じプライバシー モードでのみ使用できます。最初に BigQuery にエクスポートされていない限り、通常の集計モードで作成したテーブルをノイズモードで使用することはできません。その逆も同様です。