ID5 OpenRTB ID Provenance Support and Best Practices

Overview

Publishers and ad tech partners can choose to use the ID5 Graph to enrich their programmatic transactions with additional data. The Graph enables both probabilistic and deterministic connections between ID5 IDs and Platform Cookie IDs, which can be inserted into bid requests in real time to boost addressability. When using the ID5 Graph for bid enrichment, ID5 strongly recommends full compliance with the IAB Tech Lab’s ID provenance fields and best practices. To support this use case, ID5 provides a dedicated version of the Graph for this use case that includes the matchmethod field, indicating how each ID5–to–Platform Cookie ID connection was established.

This page provides practical guidance for publishers enriching bid requests with the ID5 Graph either directly or through a partner such as Optable, as well as for ad tech partners receiving enriched requests where ID5 (id5-sync.com) is declared as the matcher.

Publisher Guidance

Publishers collaborating with ID5 or with technology providers that use ID5's Graph to facilitate bid enrichment should follow the OpenRTB ID provenance guidance to ensure compliance and transparency. Following these steps ensures that your bid enrichment setup is recognized, compliant, and properly processed by your SSP and DSP partners.

Recommended Steps

1. Set Inserter and Matcher Values

a. Inserter: Declare your own domain as the inserter. We recommend using the same domain as the ownerdomain in your ads.txt file. 

b. Matcher: Declare id5-sync.com as the matcher.

2. Notify Your SSPs

Inform your supply-side platforms (SSPs) that you are enriching bid requests in this way. Some SSPs require whitelisting for both the inserter and matcher values before accepting or using the data.

EID Array Example of Publisher Bid Enrichment with ID5 ID and Platform Cookie IDs

{
  "eids": [
    { 
      "source": "id5-sync.com",
      "uids": [
        {
          "id": "some-random-id-value",
          "atype": 1,
          "ext": {
            "linkType": 2,
            "abTestingControlGroup": false
          }
        }
      ]
    },
    {
      "source": "ssp-domain.com",
      "matcher": "id5-sync.com",
      "mm": 5,
      "inserter": "publisher-domain.com",
      "uids": [
        {
          "id": "some-random-id-value",
          "atype": 1
        }
      ]
    }
  ]
}

SSP Guidance and Expected Behaviour

Build Support for the ID provenance fields. In practise this means:

1.When you receive a Cookie ID with provenance in the EID array, use your match tables to look up the corresponding DSP cookie IDs and include them downstream in the user.ext.eids field, following the format shown below. We recommend passing only the DSP cookie IDs for vendors to whom the user has given consent, in accordance with the user’s jurisdiction and applicable privacy regulations.

{
    "source": "<dsp-cookie-domain>",
    "id": "<dsp-cookie-id>",
    "ext":
    {
        "inserter": "ssp-domain.com",
        "matcher": "id5-sync.com",
        "mm": 5
    }
}

2. When no corresponding DSP cookie ID is found in your match tables, forward any DSP cookie IDs received along with their provenance in the user.ext.eids field.

3. Only include enriched cookie IDs in the buyeruid field if explicitly instructed by your DSP and if permitted under your contract.

4. Instruct publishers, or the partners enriching bids on their behalf, to provide the expected source value—for example, ssp-domain.com.

5. If you enforce allow-listing for bid enrichment at either the matcher or inserter level, add id5-sync.com to your matcher allow-list and request the latest list of inserter values from your ID5 representative for allow-listing.

DSP Guidance and Expected Behaviour

DSP Guidance for Handling Bid Requests with ID5 Connections

When processing bid requests that may not contain your DSP cookie ID in the buyeruid field, we recommend the following approach:

• Primary identifier (ID5 ID):

  • If present, decrypt and use the ID5 ID as the user identifier.

  • This ensures you can transact even when your DSP cookie ID is not included directly.

• Fallback identifier (cookie ID with provenance):

  • If using the ID5 ID is not supported, rely on your DSP cookie ID provided with provenance in the user.ext.eids field.

  • Use this cookie ID as the user identifier for campaign targeting.

• Bidding decision logic:

  • Once the identifier is established, evaluate eligible advertiser campaigns and decide on bid values accordingly.

  • You may also incorporate the matcher and matchmethod values into your bidding algorithms to optimise decision-making.

• Request you SSPs to conduct buyeruid Substitution

  • If you do not support the ID5 ID or ID provenance fields, instruct your SSPs to pass you bridged cookie IDs in the buyeruid field where 'id5-sync.com' is the source. 

By following this sequence, DSPs can ensure accurate user recognition, support transactions in both cookieless and cookie-supported environments, and take full advantage of the high-quality connections enabled by the ID5 graph.