Skip to main content

Advertiser/Data Provider Integration Guide

This guide covers integration steps for organizations that collect user data and push it to other UID2 participants. Data collectors include advertisers, data on-boarders, measurement providers, identity graph providers, third-party data providers, and any other organizations that send data to other participants.

If you are using a Public Operator service hosted in the Snowflake Data Marketplace, see also Snowflake Integration Guide.

Advertiser/Data Provider Routes to Use UID2​

Within the ad tech industry, advertisers use identity to build audiences, track conversions, and generate their graphs. The following table shows some examples of how you, as an advertiser or as a data provider acting on behalf of an advertiser, can accomplish some of these goals with UID2.

note

There are other ways that you can use UID2, outside these use cases. These are just some examples.

Send/Receive?ActionAdvantage/Result
SendSend UID2s via API or pixelsCreate audiences.
SendSend UID2s as conversion informationUse conversion information for measurement (attribution) or for retargeting via API or pixels.
ReceiveReceive UID2s from graph/data providers via API or pixelsBuild graph data.

High-Level Steps​

At a high level, the steps for advertisers and data providers integrating with UID2 are as follows:

  1. Generate a raw UID2 from directly identifying information (DII), or receive UID2s from another UID2 participant such as a data provider acting on your behalf.

  2. Use the UID2s you received in Step 1. For example, you might do one or more of the following:

    • Do some manipulation: for example, combine UID2s you generated from DII and UID2s received from another participant such as an advertiser or data provider.
    • Add new UID2s into an existing audience.

  3. Use the raw UID2s for some purpose such as measurement.

Integration Diagram​

The following diagram outlines the steps that data collectors must complete to map DII to raw UID2s for audience building and targeting.

DII refers to a user's normalized email address or phone number, or the normalized and SHA-256-hashed email address or phone number.

Advertiser Flow

Refer to the following sections for details about the different parts of the diagram:

  1. Retrieve a raw UID2 for DII using the identity map endpoint
  2. Send stored raw UID2s to DSPs to create audiences or conversions
  3. Monitor for salt bucket rotations related to your stored raw UID2s

1: Retrieve a raw UID2 for DII using the identity map endpoint​

StepEndpointDescription
1-aPOST /identity/map requestSend a request containing DII to the identity mapping endpoint.
1-bPOST /identity/map responseThe advertising_id (raw UID2) returned in the response can be used to target audiences on relevant DSPs.
The response returns a user's raw UID2 and the corresponding bucket_id for the salt bucket. The salt assigned to the bucket rotates annually, which impacts the generated raw UID2. For details on how to check for salt bucket rotation, see 3: Monitor for salt bucket rotations.
For ease of maintenance, a recommended approach is to store a user's raw UID2 and bucket_id in a mapping table. For guidance on incremental updates, see Use an incremental process to continuously update raw UID2s.

2: Send stored raw UID2s to DSPs to create audiences or conversions​

Send the advertising_id (raw UID2) returned in Step 1-b to a DSP while building your audiences. Each DSP has a unique integration process for building audiences; follow the integration guidance provided by the DSP for sending raw UID2s to build an audience.

A raw UID2 is an identifier for a user at a specific moment in time. The raw UID2 for a specific user changes at least once per year, as a result of the salt rotation.

Even though each salt bucket is updated approximately once per year, individual bucket updates are spread over the year. Approximately 1/365th of all salt buckets are rotated daily.

important

To ensure that your integration has the current raw UID2s, check salt bucket rotation for active users every day.

StepEndpointDescription
3-aPOST /identity/bucketsSend a request to the bucket status endpoint for all salt buckets that have changed since a specific timestamp.
3-bPOST /identity/bucketsUID2 service: The bucket status endpoint returns a list of bucket_id and last_updated timestamps.
3-cPOST /identity/mapCompare the returned bucket_id to the salt buckets of raw UID2s that you've cached.
If you find that the salt bucket was updated for one or more raw UID2s, re-send the DII to the identity mapping service for a new raw UID2.
3-dPOST /identity/mapStore the new values returned for advertising_id and bucket_id.

Use an Incremental Process to Continuously Update Raw UID2s​

To keep your UID2-based audience information accurate and up to date, follow these integration steps every day:

  1. The response from the UID2 retrieval step contains mapping information. Cache the following:

    • The mapping between DII (identifier), raw UID2 (advertising_id), and salt bucket (bucket_id).
    • The most recent last_updated timestamp.

  2. Using the results from Step 3, Monitor for salt bucket rotations related to your stored raw UID2s, remap any raw UID2 for which the salt buckets have been rotated by retrieving new raw UID2 for those IDs, following Step 1, Retrieve a raw UID2 for DII using the identity map endpoint.

    Then, use the refreshed UID2s to update audiences or conversions, following Step 2, send raw UID2 to a DSP.

Check Opt-Out Status​

It's important to honor user opt-out status. Here are two ways you can check that you have the latest opt-out information:

For details about the UID2 opt-out workflow and how users can opt out, see User Opt-Out.

FAQs​

For a list of frequently asked questions for advertisers and data providers using the UID2 framework, see FAQs for Advertisers and Data Providers.