Data Collaboration Platform (DCP) - Prepare source data for ingestion

To structure your source data for optimal ingestion and maximum outcomes in DCP:

1. Ensure it meets source data formatting requirements. 
2. For best results, structure identity data as one row per user and include all available identifiers for that user. See Recommended identifier structures.
   • If users have multiple email addresses or phone numbers, use array-based formats (such as Parquet, BigQuery, or Snowflake).
3. Check that hashing guidelines are followed.
4. For transactional datasets (and other data types where applicable), use the DCP Data View tool to create a business-oriented, privacy-safe subset of your data optimized for collaboration, and share it instead of raw tables. Why Data Views are recommended.

While other structures can be used, they may not be ideally suited for getting the most out of DCP. See Data structures that aren't recommended.

Recommended identifier structures

To maximize match rates, it's recommended to send user-level identity data as a single row per user whenever possible and to include all available identifiers in a structure that accurately reflects how users are represented.

Option 1: One row per user, one value per identifier type

Simple and effective.

Use this when each user has at most one hashed email address, one hashed phone number, and so on.

Example

Why this is recommended

• Simplest to prepare and ingest
• Easy to validate and troubleshoot
• Strong matching performance when identifiers are complete and consistent (for matching with collaborator datasets and activation media partner matching) 

Best fit

• Great for CSV-based uploads
• Also works well in Parquet / BigQuery / Snowflake

Option 2: Arrays (lists) of identifiers for multi-value fields

Best for accuracy when users have multiple emails and phones.

Use this when a user can have multiple values of the same identifier type, such as:

• Multiple hashed emails
• Multiple hashed phones

This structure should be represented as native arrays.

Example

Why this is preferred

• Reflects how identity data is often stored internally
• No need to guess how many “email columns” might be needed
• Avoids ongoing schema changes
• Maximizes matching potential (for collaborator datasets and for activation media partner matching) by allowing multiple identifiers per user

Best fit

• Parquet (S3/GCS)
• BigQuery
• Snowflake

Identity (user-level) dataset checklist 

• One row represents one user. 
• Include all available identifiers (hashed email, hashed phone, MAID, and so on). 
• If multiple values exist (for example, multiple emails), use native arrays where possible. 
• Avoid lists in cells, avoid “email_1/email_2/email_3,” and avoid multi-row identity structures. 

Transactional (events) dataset checklist 

• Keep event/transaction rows as-is. See Transactional data examples
• Use Data Views to create collaboration-ready user-level summaries when appropriate. 

Data Views checklist 

• Build business-oriented Data Views (audience-ready, summarized, standardized). 
• Share Data Views instead of raw sensitive tables whenever possible. 
• Minimize shared fields to only what’s needed (for privacy and business protection). 
• Consider aggregations to reduce access to sensitive data and improve efficiency.

The DCP supports ingestion through multiple cloud services, such as:

• AWS S3
• GCS (Google Cloud Storage)
• BigQuery
• Snowflake

Format guidance

• Use CSV (comma-separated) when each user has one value per identifier type (one email, one phone, and so on).
• When users can have multiple values of the same identifier type (for example, multiple hashed emails), prefer array-capable formats:
  • Parquet (common in big data)
  • BigQuery (arrays are built-in)
  • Snowflake (arrays are built-in)

Notes: 

• “Arrays” just means “a list of values.”
• Parquet and arrays in BigQuery/Snowflake are standard, and most data teams can support this naturally.

See Connector-specific example assets (AWS S3, GCS, BigQuery, Snowflake).

Transactional/event data may have multiple rows per user:

Recommended

• Ingest transactional data in its natural structure
• Use the Data View tool to produce a collaboration-ready user-level view (for example, spend in last 30 days, category affinity, recency/frequency summaries)

What does “array/list of identifiers” mean?

Sometimes a single user can have more than one email or phone (for example, a personal and a work email). Instead of forcing these into extra columns or messy text fields, we represent them as a list of values.

1. AWS S3 and GCS connector (Parquet)

What the identity sample should contain (schema)

Parquet supports lists natively, which is why it’s recommended when users have multiple emails/phones.

2. BigQuery connector (table preview and schema screenshot)

Example identity schema (BigQuery)

Arrays are native in BigQuery (REPEATED fields). This is the recommended approach when multiple emails/phones exist.

3. Snowflake connector (table preview and schema screenshot)

Example identity schema (Snowflake)

Snowflake supports list-like fields (arrays). This is preferred over creating email_1/email_2/email_3 columns.

Data views are customized subsets of your existing data sources that you can create without changing the original dataset. They let you perform functions that modify, refine, and summarize the data so you can share only what’s relevant in collaborations, keeping the data you share clear and focused, and all other data private and secure. Use Data Views in collaborations because they:

Are business-oriented and easier to collaborate with

• Data Views let you present the data in a clean, business-friendly structure (for example, “Customer Identity View”, “Eligible Audience View”, “Purchase Summary View”) rather than raw logs or complex transactional schemas.
• They help standardize definitions (for example, “active customer”, “total spend last 30 days”) so both sides are aligned and using the same logic.

Are more privacy-safe by design

• Data Views support data minimization: you can share only the fields and rows needed for the collaboration, instead of exposing full raw datasets.
• They reduce privacy risk by allowing you to:
  • Exclude unnecessary attributes
  • Limit granularity (for example, share aggregated metrics instead of line-level transactions)
  • Share only the identifiers needed for matching (and not additional sensitive columns)

Protect sensitive business data

• Raw transactional tables can contain highly sensitive business signals (for example, detailed purchase behavior, pricing patterns, merchant relationships, internal IDs).
• Data Views let you share only what’s required for the collaboration:
  • Example: share category-level aggregates instead of item-level details
  • Example: share spend buckets or summary metrics instead of exact line items
• This reduces the risk of unintentionally revealing competitive or proprietary information.

Can make your data more cost-effective and performant

Data Views can be structured to be lighter and more efficient, which often reduces:

• Data scanned
• Processing time
• Compute costs

Pre-structuring a collaboration-ready view (especially aggregated views) may make collaboration faster and more operationally predictable.

DCP identifiers upload 

Takeaways for activation planning

• Meta and TikTok
  • Send everything you have
  • True “any-ID” behavior
  • Best platforms for identity-rich clean room activation
• Google
  • Send multiple IDs for coverage
  • Do not expect cross-ID reinforcement
  • Email/phone dominance is real
• TTD and Infillion
  • Matching quality depends more on identity graph participation
  • UID2 / OmniID coverage matters more than raw identifier count
• Pinterest
  • Behaves closer to Google than Meta
  • Limited upside beyond email + MAID

TL;DR

• Only Meta and TikTok do “any-of-them” matching natively
• Google is deterministic but single-ID resolved
• Open web platforms match via identity graphs, not raw IDs

Universal normalization rules:
Before hashing any data, almost all platforms require the following normalization steps to ensure matching accuracy:

• Text: Convert to lowercase and trim all leading/trailing whitespace.
• Phone: Convert to E.164 format (e.g., +15551234567)
• Hashing: SHA-256 is the industry standard, though some platforms accept MD5 or SHA-1.