Ads Data Hub が行うあらゆる処理はエンドユーザーのプライバシー保護を念頭に置いたものとなっており、プラットフォームそのものがプライバシー保護を基礎として構築されています。Google ではプライバシーを保護し、お客様の規制遵守をサポートするために、お客様がプラットフォームから取得するデータの中に個々のユーザーに関するデータ1が含まれないよう、一定のチェック機能と制限を設けています。チェック機能の概要は以下のとおりです。一部詳細については後述します。
- 静的チェック。クエリ内のステートメントを調べ、プライバシーに関する明らかで直接的な懸念がないか確認します。以下はその例です。
- ユーザー識別子のエクスポート、またはユーザー識別子のなんらかの使用。
- ユーザー単位のデータを含むフィールドにおけるブロックリストの関数の使用。
- データアクセス予算。データアクセス予算とは、同じデータにアクセスできる回数の上限を定めたものです。予算の終了が近づくと、
DATA_ACCESS_BUDGET_IS_NEARLY_EXHAUSTEDタイプのプライバシー メッセージで通知されます。 予算は、データアクセス予算のエントリ ポイントを使用するか、管理画面で予算通知を確認することでモニタリングできます。 - 集計の要件。各行に含まれるユーザー数をしきい値以上にすることで、エンドユーザーのプライバシーを保護します。
差分チェック。実行中のジョブの結果を以前の結果と比較します。また、同じ結果セット内の行同士も比較します。これは、集計要件を満たした複数のユーザーセットのデータを比較することで、個々のユーザーに関する情報が収集されないようにするためです。2 つのジョブの間で基になるデータに差異があると、差分チェック違反になります。
ヒント: 差分チェックとノイズ インジェクションのどちらを使用してクエリを実行するかを選択できます。ノイズ インジェクションを使用すると、ユーザーのプライバシーが保護される一方で、ある程度の正確な結果が得られ、差分チェックを行う必要はなくなります。Ads Data Hub におけるノイズ インジェクションの使用に関する詳細をご覧ください。
プライバシー チェックの結果が不合格だった場合、行がフィルタされたことを示すプライバシー メッセージが表示されます。フィルタによる除外の規模はさまざまで、1 行の場合もあれば結果セット全体の場合もあります。フィルタされた行の概要を使用して2、除外された行のデータをカウントすることで、レポートの合計の精度を保つことができます。
集計の要件
Ads Data Hub のプライバシー チェックでは、ユーザー集計のしきい値が基準となります。ほとんどのクエリでは、含まれるユーザーが 50 人未満の場合、レポートデータは取得できません。ただし、クリック数とコンバージョン数のみを参照するクエリの場合は、10 人以上であれば取得可能です（ID が null のユーザーは、この集計のしきい値にカウントされません）。
下の例では、キャンペーン 125 を含む行は最終結果からフィルタされます。48 人のユーザーからの結果を集計しており、ユーザー数 50 人の集計要件を下回っているためです。なお、フィルタされた行とは、プライバシーに関する制限により結果から除外された行のことです。
| キャンペーン | ユーザー数 | 表示回数 |
|---|---|---|
| 123 | 314 | 928 |
| 124 | 2,718 | 5,772 |
| 125 | 48 | 353 |
差分チェック
差分チェックは、集計要件を満たした複数のユーザーセットのデータを比較することで、個々のユーザーに関する情報が収集されるのを防ぐのに役立ちます。ジョブの結果を過去の結果と比較する際、Ads Data Hub は個々のユーザーのレベルで脆弱性がないか確認します。このため、過去のジョブと重複しているユーザーが多ければ、異なるキャンペーンについてのジョブや、含まれるユーザー数が同一のジョブであっても、結果がフィルタされる可能性があります。
一方、2 つの集計結果セットのユーザー数は同一に見えても、個々のユーザーが重複していない場合は、プライバシーが保護されるためフィルタされません。
新しい結果の脆弱性を確認する際は、過去の結果のデータが使用されるため、同じクエリを繰り返し実行すると、新しい結果の脆弱性を確認する際に差分チェックで使用されるデータが増えます。さらに、基になるデータが変化する可能性があるため、安定していると考えられるクエリでもプライバシー チェック違反が発生する場合があります。
ジョブレベルでは結果が十分に異なっていても、個々の行が前のジョブの行と類似している場合、その類似した行はフィルタされます。以下の例では、2 番目の結果のキャンペーン 123 を含む行は、前の結果とユーザー数が 1 人しか変わらないためフィルタされます。
| ジョブ 1 | ジョブ 2 | |||
|---|---|---|---|---|
| キャンペーン ID | ユーザー数 | キャンペーン ID | ユーザー数 | |
| 123 | 400 | 123 | 401 | |
| 124 | 569 | 224 | 1,325 |
結果セットのすべての行のユーザー数の合計が前のジョブのユーザー数の合計と類似している場合、結果セット全体がフィルタされます。以下の例では、2 番目のジョブからすべての結果がフィルタされます。
| ジョブ 1 | ジョブ 2 | |||
|---|---|---|---|---|
| キャンペーン ID | ユーザー数 | キャンペーン ID | ユーザー数 | |
| 123 | 400 | 123 | 402 | |
| 124 | 1,367 | 124 | 1,367 |
フィルタされた行の概要
フィルタされた行の概要では、プライバシー チェックによって除外されたデータが集計されます。フィルタされた行のデータが合計され、キャッチオール行に追加されます。フィルタされたデータはこれ以上分析できませんが、結果から除外されたデータの量の概要を把握することができます。
クエリ アドバイザー
有効な SQL であっても、過度のフィルタ処理を引き起こす可能性がある場合は、クエリ作成中にクエリ アドバイザーによる具体的なアドバイスが提供され、望ましくない結果を避けられるようになっています。
次のような場合に、アドバイスが提供されます。
- 集計されたサブクエリの結合
- 異なっている可能性のあるユーザーとの未集計のデータの結合
- 再帰的に定義された一時テーブル
クエリ アドバイザーを使用するには:
- 管理画面。アドバイスは、クエリエディタ内のクエリテキストの上に表示されます。
- API。
customers.analysisQueries.validateメソッドを使用します。
-
ユーザーが共有に同意したデータ（パネルメンバーの場合など）以外を指します。 ↩
-
プライバシー上の制限によってできない場合（フィルタされた行の概要のユーザー数が集計要件を満たしていない場合など）を除きます。 ↩