DCPでの取り込みを最適化し、成果を最大化するためにソースデータを構造化するには：

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

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

推奨される識別子構造

マッチ率を最大化するために、可能な限りユーザーレベルの識別データをユーザーごとに1行で送信し、ユーザーがどのように表現されているかを正確に反映する構造ですべての利用可能な識別子を含めることをお勧めします。

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

シンプルかつ効果的。

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

例

これが推奨される理由

• 準備と取り込みが最も簡単
• 検証とトラブルシューティングが容易
• 識別子が完全かつ一貫している場合に強力なマッチングパフォーマンスを発揮する（コラボレーターのデータセットおよびアクティベーションメディアパートナーとのマッチング用） 

最適

• CSVベースのアップロードに最適
• Parquet / BigQuery / Snowflakeでもうまく機能する

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

ユーザーが複数のメールアドレスや電話番号を持っている場合の精度に最適。

ユーザーが同じ識別子タイプで複数の値を持つ可能性がある場合、以下のように使用します。

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

この構造はネイティブ配列として表現する必要があります。

例

これが推奨される理由

• IDデータが内部でどのように保存されているかを反映しているため
• 「メール列」がいくつ必要かを推測する必要がないため
• 継続的なスキーマ変更を回避できるため
• ユーザーごとに複数の識別子を許可することで、マッチングの可能性を最大化する（コラボレーターのデータセットおよびアクティベーションメディアパートナーとのマッチング用）

最適

• Parquet (S3/GCS)
• BigQuery
• Snowflake

ID（ユーザーレベル）データセットチェックリスト 

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

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

• イベント/トランザクション行はそのまま維持してください。トランザクションデータの例を参照してください。
• 必要に応じてデータビューを使用し、コラボレーション可能なユーザーレベルのサマリーを作成してください。 

データビューのチェックリスト 

• ビジネス指向のデータビュー（オーディエンス対応、要約済み、標準化済み）を構築してください。 
• 可能な限り、機密性の高い生のテーブルではなく、データビューを共有してください。 
• 共有するフィールドは、必要なものだけに最小限に抑えてください（プライバシー保護およびビジネス保護のため）。 
• 機密データへのアクセスを減らし、効率を向上させるために、集計を検討してください。

DCPは、以下のような複数のクラウドサービスを通じた取り込みをサポートしています。

• AWS S3
• Google Cloud Storage
• BigQuery
• Snowflake

フォーマットに関するガイダンス

• 各ユーザーが識別子タイプごとに1つの値（1つのメールアドレス、1つの電話番号など）を持つ場合は、CSV（カンマ区切り）を使用してください。
• ユーザーが同じ識別子タイプの複数の値を持つ可能性がある場合（例：複数のハッシュ化されたメールアドレス）、配列対応フォーマットを優先してください。
  • Parquet（ビッグデータで一般的）
  • BigQuery（配列が組み込み）
  • Snowflake（配列が組み込み）

注意： 

• 「配列」とは単に「値のリスト」を意味します。
• ParquetおよびBigQuery/Snowflakeの配列は標準的であり、ほとんどのデータチームがこれを自然にサポートできます。

コネクタ固有のサンプルアセット（AWS S3、GCS、BigQuery、Snowflake）を参照してください。

トランザクションデータやイベントデータは、ユーザーごとに複数行になる場合があります：

推奨

• トランザクションデータは自然な構造のまま取り込んでください
• Data Viewツールを使用して、コラボレーション可能なユーザーレベルのビューを作成します（例：過去30日間の支出、カテゴリの親和性、直近性/頻度の要約など）

「識別子の配列/リスト」とはどういう意味ですか？

1人のユーザーが複数のメールアドレスや電話番号を持つ場合があります（例：個人用と仕事用のメールアドレス）。これらを余分な列や煩雑なテキストフィールドに押し込むのではなく、値のリストとして表現します。

1.AWS S3およびGCSコネクタ（Parquet）

IDサンプルに含めるべき内容（スキーマ）

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

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

IDスキーマの例（BigQuery）

BigQueryでは配列がネイティブでサポートされています（REPEATEDフィールド）。複数のメールアドレスや電話番号が存在する場合、これが推奨されるアプローチです。

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

IDスキーマの例（Snowflake）

Snowflakeはリストのようなフィールド（配列）をサポートしています。これは、email_1/email_2/email_3といった列を作成するよりも推奨されます。

データビューは、元のデータセットを変更することなく作成できる、既存のデータソースのカスタマイズされたサブセットです。データビューを使用すると、データを変更、絞り込み、要約する機能を実行できるため、コラボレーションにおいて関連性の高いデータのみを共有でき、共有するデータを明確かつ的を絞ったものに保ちつつ、その他のすべてのデータを非公開かつ安全に保つことができます。コラボレーションでデータビューを使用する理由：

ビジネス指向であり、コラボレーションが容易であるため

• データビューを使用すると、生のログや複雑なトランザクションスキーマではなく、クリーンでビジネスに適した構造（例：「顧客IDビュー」、「対象オーディエンスビュー」、「購入概要ビュー」など）でデータを提示できます。
• 定義（例：「アクティブな顧客」、「過去30日間の総支出」など）を標準化するのに役立つため、双方が足並みを揃え、同じロジックを使用できます。

設計上、よりプライバシーが保護されているため

• データビューはデータ最小化をサポートしています。完全な生のデータセットを公開するのではなく、コラボレーションに必要なフィールドと行のみを共有できます。
• データビューを使用すると、以下のことが可能になり、プライバシーリスクを軽減できます。
  • 不要な属性を除外する
  • 粒度を制限する（例：トランザクション単位ではなく集計された指標を共有する）
  • マッチングに必要な識別子のみを共有する（機密性の高い追加列は共有しない）

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

• 生のトランザクションテーブルには、非常に機密性の高いビジネスシグナル（例：詳細な購買行動、価格設定パターン、加盟店との関係、内部IDなど）が含まれている可能性があります。
• データビューを使用すると、コラボレーションに必要なデータのみを共有できます。
  • 例：アイテムレベルの詳細ではなく、カテゴリレベルの集計を共有する
  • 例：正確な明細項目ではなく、支出のバケットや要約指標を共有する
• これにより、競合情報や独自の情報を意図せず開示してしまうリスクが軽減されます。

データの費用対効果とパフォーマンスを向上させることができる

データビューは、より軽量で効率的になるように構成でき、多くの場合、以下を削減できます。

• スキャンされたデータ
• 処理時間
• コンピューティングコスト

コラボレーション対応のビュー（特に集計ビュー）を事前に構成しておくと、コラボレーションが迅速化し、運用上の予測可能性が高まる可能性があります。

DCP識別子のアップロード

アクティベーション計画のための要点

• MetaおよびTikTok
  • 持っているすべてのデータを送信する
  • 真の「any-ID」動作
  • IDリッチなクリーンルームアクティベーションに最適なプラットフォーム
• Google
  • カバレッジのために複数のIDを送信する
  • ID間での補強は期待しないこと
  • メール/電話番号の優位性は本物である
• TTDおよびInfillion
  • マッチング品質はIDグラフへの参加状況に大きく依存する
  • 生の識別子数よりもUID2 / OmniIDのカバレッジが重要である
• Pinterest
  • MetaよりもGoogleに近い動作をする
  • メール + MAID以外でのメリットは限定的である

要点

• MetaとTikTokのみが「いずれか」のマッチングをネイティブに行う
• Googleは決定論的ですが、単一IDで解決されます
• オープンウェブプラットフォームは、生のIDではなく、アイデンティティグラフを介して照合します

ユニバーサル正規化ルール：
データをハッシュ化する前に、マッチングの精度を確保するため、ほとんどのプラットフォームで以下の正規化ステップが求められます：

• Text:小文字に変換し、先頭/末尾のすべての空白を削除します。
• PhoneE.164形式に変換します（例：+15551234567）
• ハッシュ化SHA-256が業界標準ですが、MD5やSHA-1を受け入れるプラットフォームもあります。