DCPへ効率的に取り込み、最大限の成果を得られるようソースデータを構成するには：

1. ソースデータの形式要件を満たしていることを確認します。 
2. 最良の結果を得るため、識別子データは1ユーザーにつき1行で構成し、そのユーザーについて利用可能な識別子をすべて含めてください。詳細は、推奨される識別子の構造を参照してください。
   • ユーザーが複数のメールアドレスや電話番号を持つ場合は、配列に対応した形式（Parquet、BigQuery、Snowflakeなど）を使用します。
3. ハッシュ化のガイドラインに従っていることを確認します。
4. トランザクションデータセット（および該当するその他のデータタイプ）では、DCPのData Viewツールを使用して、コラボレーションに適した、ビジネス用途を意識したプライバシー保護済みのデータサブセットを作成し、ローテーブルではなくそのData Viewを共有してください。 Data Viewが推奨される理由

他の構造も使用できますが、DCPを最大限に活用するうえでは最適でない場合があります。推奨されないデータ構造を参照してください。

推奨される識別子の構造

マッチ率を最大化するには、可能な限りユーザーレベルの識別子データを1ユーザーにつき1行で送信し、実際のユーザー情報の持ち方を正確に反映した構造で、利用可能な識別子をすべて含めることを推奨します。

オプション1：1ユーザーにつき1行、識別子タイプごとに1つの値

シンプルで効果的な構造です。

各ユーザーが、ハッシュ化されたメールアドレス、ハッシュ化された電話番号などをそれぞれ最大1つしか持たない場合に使用します。

例

この構造が推奨される理由

• 準備と取り込みが最もシンプル
• 検証やトラブルシューティングが容易
• 識別子が完全かつ一貫している場合、コラボレーターのデータセットとの照合やアクティベーション先のメディアパートナーとの照合で高いマッチ率が期待できる 

適したケース

• CSVベースのアップロードに最適
• Parquet／BigQuery／Snowflakeでも利用可能

オプション2：複数値フィールドで識別子の配列（リスト）を使用

ユーザーが複数のメールアドレスや電話番号を持つ場合に、精度を高めるのに最適な構造です。

1人のユーザーが同じ識別子タイプの値を複数持つ場合に使用します。例：

• 複数のハッシュ化メールアドレス
• 複数のハッシュ化電話番号

この構造はネイティブ配列として表現してください。

例

この構造が推奨される理由

• 識別子データが社内で実際に保存されている構造を反映しやすい
• 必要となる「メールアドレス列」の数を事前に想定する必要がない
• 継続的なスキーマ変更を避けられる
• 1ユーザーにつき複数の識別子を持たせることで、コラボレーターのデータセットやアクティベーション先のメディアパートナーとのマッチ可能性を最大化できる

適したケース

• Parquet（S3／GCS）
• BigQuery
• Snowflake

識別子データ（ユーザーレベルデータ）のチェックリスト 

• 1行が1ユーザーを表していること。 
• 利用可能な識別子（ハッシュ化メールアドレス、ハッシュ化電話番号、MAIDなど）をすべて含めること。 
• 複数の値（複数のメールアドレスなど）がある場合は、可能な限りネイティブ配列を使用すること。 
• セル内のリスト、「email_1/email_2/email_3」のような複数列、複数行にまたがる識別子データの構造は避けること。 

トランザクションデータ（イベントデータ）のチェックリスト 

• イベント／トランザクションの行は、元の構造のまま保持します。トランザクションデータの例を参照してください。
• 必要に応じてData Viewを使用し、コラボレーションに適したユーザーレベルのサマリーを作成します。 

Data Viewのチェックリスト 

• ビジネス用途を意識したData Viewを作成します（オーディエンス作成に適した、集約・標準化済みの構造）。 
• 可能な限り、機密性の高いローデータのテーブルではなくData Viewを共有します。 
• 共有するフィールドは、プライバシー保護とビジネス上の情報保護の観点から、必要なものだけに絞ります。 
• 機密データへのアクセスを減らし、効率を高めるため、集約処理の活用を検討します。

DCPでは、以下を含む複数のクラウドサービスからデータを取り込めます。

• AWS S3
• GCS（Google Cloud Storage）
• BigQuery
• Snowflake

形式に関するガイドライン

• 各ユーザーが識別子タイプごとに1つの値（メールアドレス1つ、電話番号1つなど）を持つ場合は、CSV（カンマ区切り）を使用します。
• ユーザーが同じ識別子タイプの複数の値（複数のハッシュ化メールアドレスなど）を持つ場合は、配列に対応した形式を推奨します。
  • Parquet（ビッグデータで一般的）
  • BigQuery（配列を標準サポート）
  • Snowflake（配列を標準サポート）

注意： 

• 「配列（Array）」とは、複数の値を1つのリストとして持つことを意味します。
• ParquetやBigQuery／Snowflakeの配列は標準的な機能であり、多くのデータチームで無理なく対応できます。

コネクタ別のサンプル（AWS S3、GCS、BigQuery、Snowflake）を参照してください。

トランザクション／イベントデータでは、1ユーザーにつき複数行になる場合があります。

推奨

• トランザクションデータは、元の自然な構造のまま取り込みます。
• Data Viewツールを使用して、コラボレーションに適したユーザーレベルのビューを作成します（例：過去30日間の支出額、カテゴリ嗜好、直近購入日／購入頻度のサマリー）。

「識別子の配列／リスト」とは？

1人のユーザーが複数のメールアドレスや電話番号を持つことがあります（個人用と仕事用のメールアドレスなど）。その場合、列を増やしたり、1つのテキストフィールドに無理に詰め込んだりするのではなく、複数の値をリストとして表現します。

1. AWS S3／GCSコネクタ（Parquet）

識別子データのサンプルに含める内容（スキーマ）

Parquetはリストをネイティブでサポートしているため、ユーザーが複数のメールアドレス／電話番号を持つ場合に推奨されます。

2. BigQueryコネクタ（テーブルプレビューとスキーマのスクリーンショット）

識別子データのスキーマ例（BigQuery）

BigQueryでは、配列はネイティブ機能（REPEATEDフィールド）としてサポートされています。複数のメールアドレス／電話番号がある場合は、この方法を推奨します。

3. Snowflakeコネクタ（テーブルプレビューとスキーマのスクリーンショット）

識別子データのスキーマ例（Snowflake）

Snowflakeは、リスト形式のフィールド（配列）をサポートしています。 email_1/email_2/email_3のように複数の列を作成するよりも、この方法を推奨します。

Data Viewは、元のデータセットを変更することなく、既存のデータソースから作成できるカスタマイズ済みのデータサブセットです。 Data Viewでは、データを加工・精緻化・集約する処理を行い、コラボレーションに必要な情報だけを共有できます。共有データを明確かつ目的に沿った内容に保ちながら、それ以外のデータは非公開かつ安全な状態に維持できます。コラボレーションでData Viewを使用する理由：

ビジネス用途に適しており、コラボレーションしやすい

• Data Viewを使用すると、ローログや複雑なトランザクションスキーマではなく、「Customer Identity View」「Eligible Audience View」「Purchase Summary View」など、整理されたビジネス向けの構造でデータを提示できます。
• また、「アクティブユーザー」「過去30日間の総支出額」などの定義を標準化できるため、双方が同じ定義とロジックに基づいてデータを利用できます。

設計上、よりプライバシーを保護しやすい

• Data Viewはデータ最小化に対応しており、ローデータセット全体を公開するのではなく、コラボレーションに必要なフィールドと行だけを共有できます。
• 以下の方法でプライバシーリスクを抑えられます。
  • 不要な属性を除外
  • 粒度を制限（例：明細レベルのトランザクションではなく、集約済みの指標を共有）
  • 照合に必要な識別子だけを共有し、追加の機密列は共有しない

機密性の高いビジネスデータを保護

• ロートランザクションテーブルには、詳細な購買行動、価格パターン、加盟店との関係、内部IDなど、機密性の高いビジネス情報が含まれる場合があります。
• Data Viewを使用すると、コラボレーションに必要な情報だけを共有できます。
  • 例：商品単位の詳細ではなく、カテゴリ単位の集計値を共有
  • 例：正確な明細ではなく、支出額のレンジやサマリー指標を共有
• これにより、競争上重要な情報や独自情報を意図せず開示してしまうリスクを軽減できます。

コスト効率とパフォーマンスを高められる

Data Viewを軽量で効率的な構造にすることで、以下を削減できる場合があります。

• スキャンするデータ量
• 処理時間
• コンピューティングコスト

コラボレーション向けのビュー（特に集約済みビュー）をあらかじめ構成しておくことで、コラボレーションをより迅速に進め、運用上の予測可能性を高められる場合があります。

DCPの識別子アップロード 

アクティベーション計画のポイント

• MetaとTikTok
  • 利用可能な識別子をすべて送信
  • 複数IDのうち「いずれか」でマッチできる仕組みに対応
  • 識別子が豊富なクリーンルームアクティベーションに最も適したプラットフォーム
• Google
  • カバレッジを広げるために複数のIDを送信
  • 複数IDの組み合わせによる補完効果は期待しない
  • Email／Phoneが中心
• TTDとInfillion
  • マッチング品質は、識別子の数よりIDグラフへの参加状況に左右される
  • 生の識別子数より、UID2／OmniIDのカバレッジが重要
• Pinterest
  • MetaよりGoogleに近い動作
  • Email＋MAID以外のIDを追加しても得られる効果は限定的

要点

• 複数IDのうち「いずれか」でネイティブにマッチできるのはMetaとTikTokのみ
• Googleは決定論的ですが、1つのIDでユーザーを特定します。
• オープンWeb系プラットフォームは、生のIDではなくIDグラフを利用してマッチングします。

共通の正規化ルール：
マッチ精度を確保するため、ほぼすべてのプラットフォームで、データをハッシュ化する前に以下の正規化処理が必要です。

• テキスト：小文字に変換し、先頭と末尾の空白を削除します。
• 電話番号：E.164形式に変換します（例：+15551234567）。
• ハッシュ化：業界標準はSHA-256ですが、一部のプラットフォームではMD5またはSHA-1も利用できます。