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 に直接保存されません。代わりに、Ads Data Hub はサービス アカウントと OAuth を使用して、プラットフォーム間でデータを安全にアクセス、転送します。このアプローチでは、機密情報の保存を回避し、承認されたアクションに一時的なアクセス トークンを使用することによって、セキュリティを強化します。
セットアップに失敗した理由
セットアップが失敗する理由はさまざまです。このエラーが発生する理由の 1 つは、Google Cloud プロジェクトでドメインで制限された共有（DRS）が有効になっている場合です。この問題を解決するには、Google Cloud プロジェクトで DRS を一時的に無効にして、UPDM の設定を完了します。設定が完了したら、DRS を再度有効にできます。組織のポリシーにより DRS を無効にできない場合は、サポートチームにお問い合わせください。