Google の UPDM（ユーザー提供データ マッチング）機能を使えば、ファーストパーティ データをもとに必要なアクションを割り出し、顧客との有意義な関係構築に役立てることができます。このページでは、UPDM のマッチ率についてのよくある質問にお答えします。
リストのサイズとリーチを最大化するにはどうすればいいですか？
リストのサイズとは、リーチできるユーザーの実数を指します。リストのサイズとリーチを最大化したい場合は以下が効果的です。
- 利用可能な情報（メールアドレス、モバイル デバイス、電話番号、住所）はすべてアップロードします。追加するシグナル識別子が多いほど、マッチが発生しやすくなります。各シグナルは OR ロジックで個別に処理されるため、シグナルの種類を増やすことでマッチ範囲が絞られてしまう心配はありません。
- 接続で UPDM 用にハッシュ処理済みのカスタマー マッチ テーブルを再利用します。
- データのフォーマットに関する問題がある場合、マッチ率がベンチマークとして役立ちます。
- データファイルの同一行に顧客のシグナル識別子を複数入れます。
顧客のシグナル識別子を複数追加するにはどうすればいいですか？
データファイルの同一行に顧客のシグナル識別子を複数入れることで、Ads Data Hub でのマッチ率向上が期待できます。たとえば、同じ顧客の電話番号とメールアドレスがわかっている場合は、同一行のデータとして入力します（行 2 と行 5 を参照）。
リストはどれくらいの頻度で更新するべきですか？
最大限の成果とパフォーマンスを得るには、リストは毎日更新することをおすすめします。接続の設定時にインポート スケジュールを組んでおけばスムーズです。
マッチ率はどこで確認できますか？
最近実行したばかりのジョブに限り、管理画面の [最近の実行] 欄にデータのマッチ率が表示されます。プライバシー上の制約により厳密な値はご提供できないため、ここで表示されるのは概算値です。
データマッチ率（Google ユーザー識別スペース全体とマッチしたユーザー）は、必ず Ads Data Hub のマッチテーブルの行数（Google に開示したファーストパーティ データに含まれており、かつ利用者様のキャンペーンでリーチできたユーザー）と同数またはそれ以上になります。この数値は、次のクエリを顧客のファーストパーティ データの一意のエントリ数で割った結果として得られます。
SELECT COUNT(*)
FROM *_updm
GROUP BY 1
マッチ率が低いのですが、なぜですか？
マッチ率とは、アップロードしたデータのうち Google ユーザーと結び付けることができたものの割合で、リストのうちどの程度が使用可能かを表します。マッチ率が 100% でなくても問題ありません。マッチしない顧客情報が存在することもよくあります。
マッチ率には次のような利用方法があります。
- データのフォーマットに関する問題がある場合に、ベンチマークとして診断に利用する。
- ファーストパーティ データと Google の間のマッチの割合を確認する。
UPDM のマッチ率がカスタマー マッチの場合よりも高いのですが、なぜですか？
UPDM では任意のシグナル識別子によってユーザーのマッチングを行いますが、カスタマー マッチではマッチングのためのフィルタ処理時に広告インプレッション データも考慮されます。
エラーと ID の競合を防ぐにはどうすればよいですか？
エラーや ID の競合の可能性を減らすには:
- アカウントごとに一度に 1 つの一致する接続のみを実行する
- Ads Data Hub アカウントと同じリージョンにあるデータソースを使用してください。
データの TTL はどれくらいですか？
有効期間（TTL）が 60 日の場合、お客様が一致レコードをアップロードすると、そのレコードがマッチテーブルに 60 日間保存されます。60 日が経過すると、エントリは再アップロードされるまでマッチテーブルから削除されます。Cookie マッチのアップロード データにプライバシーと法令遵守のため有効期限が設けられているのと同様です。
地域によってデータの処理方法に違いはありますか？
UPDM は、カスタマー マッチのデータを 4 つの地域（EU、米国、アジア、オーストラリア）にエクスポートします。4 つの地域のそれぞれに完全なデータセット（地域を問わず、すべての Google GAIA ID のデータ）がエクスポートされます。このため、利用者様の所在地域を問わず、全地域のデータとマッチングが行われます。
データがフィルタ処理されるのは、Ads Data Hub 側で地域によるフィルタリングを行っている場合のみです（UPDM 自体はそういったフィルタ処理を行いません）。
クエリを実行してみるとマッチテーブルが空なのですが、なぜですか？
UPDM 使用時は、分析対象が Google が所有・運営するデータであること、検索を使用するキャンペーンを結合していないことを確認しましょう。UPDM で使用する広告イベントは、Google の広告データ上でログイン済みのユーザーと関連付けられている必要があります。詳細: Ads Data Hub の結合可能なフィールド
google_ads_impressions、dv360_youtube_impressions、yt_reserve_impressions テーブルには、ログイン中のデータとログアウト中のデータが含まれます。UPDM 向け Ads Data Hub の「一致したユーザー」には、過去 180 日間にアクティブで、キャンペーンによってリーチされ、ファーストパーティ データセットにアップロードされた、Google が認識しているユーザーが含まれます。
アカウントはどのような構造にすべきですか？
UPDM とファーストパーティ データを使用するには、代理店は広告主ごとに一意の子アカウントを Ads Data Hub アカウントに追加する必要があります。これにより、各広告主は、メインの代理店アカウントの下にある一意の子アカウントにデータを保存することができます。広告主データを固有の子アカウントに分けていない従来のアカウントでは、広告主ごとに子アカウントを新たに作成し、データがバックフィルされるまで待つ必要があります。
API はサポートされていますか？
公開の UPDM API はなく、接続の設定は UI から行います。 ただし、UPDM マッチテーブルを使用するクエリの実行は、他のクエリと同様に Ads Data Hub API でサポートされます。また、マッチ率は機密情報です。ユーザー インターフェースでお客様に表示されるレートには、プライバシー要件によりノイズが適用されています。
UPDM サービス アカウントを見つけて管理するにはどうすればよいですか？
UPDM の設定時に、Data Fusion、Data Proc、Matching サービス アカウントが自動生成され、アクセス権が自動的に付与されます。設定が完了したら、Google Cloud プロジェクトの IAM 設定でサービス アカウントを見つけて管理できます。
データソースの認証情報を UI で送信する場合、その認証情報はどのように処理されますか？
Snowflake や MySQL などのデータソースに接続するための認証情報は、Ads Data Hub に直接保存されません。代わりに、サービス アカウントと OAuth を使用して、プラットフォーム間で安全にデータにアクセスし、データを転送します。このアプローチでは、機密情報の保存を回避し、承認されたアクションに一時的なアクセス トークンを使用することで、セキュリティを強化します。
セットアップに失敗した理由
セットアップが失敗する原因はさまざまです。このエラーが表示される理由の 1 つは、Google Cloud プロジェクトでドメインで制限された共有（DRS）が有効になっていることです。この問題を解決するには、Google Cloud プロジェクトで DRS を一時的に無効にして UPDM の設定を完了します。設定が完了したら、DRS を再度有効にできます。組織のポリシーが原因で DRS を無効にできない場合は、Google のサポートチームにお問い合わせください。