Skip to main content

Frequently Asked Questions

Frequently asked questions for EUID are grouped into general categories by audience.

FAQs—General​

Here are some frequently asked questions regarding the EUID framework.

Will all integration partners in the UID2 infrastructure (SSPs, third-party data providers, measurement providers) be automatically integrated with EUID?​

No. EUID has its own framework, which is separate from UID2. As such, paperwork relating to the usage and access to the UID2 framework does not automatically grant usage and access to the EUID framework. New contracts are required to be signed for EUID.

Can users opt out of targeted advertising tied to their EUID?​

Yes. Through the Transparency and Control Portal, users can opt out from being served targeted ads tied to their EUID identity. Each request is distributed through the EUID Opt-Out Service, and EUID Operators make the opt-out information available to all relevant participants.

When I send personal data to EUID, does EUID store the information?​

No. None of the components of the EUID service store any personal information.

In addition, in almost all cases, EUID doesn't store any values at all once the POST /token/generate, POST /token/refresh, or POST /identity/map call is complete. A necessary exception is the case where a user has opted out. In this scenario, EUID stores a hashed, opaque value to indicate the opted-out user. The stored value cannot be reverse engineered back to the original value of the personal data, but can be used to identify future requests for an EUID generated from the same personal data, which are therefore denied.

FAQs for Publishers​

Here are some frequently asked questions for publishers using the EUID framework.

How can I test that the personal data sent and the returned token match up?​

You can use the POST /token/validate endpoint to check whether the personal data you are sending through POST /token/generate is valid. POST /token/validate is used primarily for testing purposes.

For details, see Using POST /token/validate to Test.

Do I need to decrypt tokens?​

No, publishers do not need to decrypt EUID tokens.

How will I be notified of user opt-out?​

If the user has opted out, the API response notifies you in either of these cases:

  • When you generate the EUID token by a call to the POST /token/generate endpoint, either directly or via one of the EUID SDKs, using the required optout_check parameter with a value of 1.
  • When you refresh the EUID token by a call to the POST /token/refresh endpoint, either directly or via one of the EUID SDKs.

Where should I make token generation calls—from the server side or the client side?​

You can generate EUID tokens from either the client side or the server side. For more information, see:

Can I make token refresh calls from the client side?​

Yes. The POST /token/refresh can be called from the client side (for example, a browser or a mobile app) because it does not require using an API key.

How can I test the refresh token workflow?​

You can use the refresh-optout@example.com email address to test your token refresh workflow. Using this email address in a request always generates an identity response with a refresh_token that results in a logout response.

The procedure is a little different depending on whether or not you are using an SDK.

With SDK:​
  1. Send a POST /token/generate request using one of the following values:
    • The refresh-optout@example.com as the email value.
    • The hash of refresh-optout@example.com as the email_hash value.
  2. Wait until the SDK's background auto-refresh attempts to refresh the advertising token (this can take several hours) and observe the refresh attempt fail with the OPTOUT status. At this point the SDK also clears the first-party cookie.
Without SDK:​

  1. Send a POST /token/generate request using one of the following values:

    • The refresh-optout@example.com as the email value.
    • The hash of refresh-optout@example.com as the email_hash value.

  2. Store the returned refresh_token for use in the following step.

  3. Send a POST /token/refresh request with the refresh_token (saved in step 2) as the token value.

    The body response should be empty, and the status value should be set to optout because the refresh-optout@example.com email always results in a logged out user.

What is the uniqueness and rotation policy for EUID tokens?​

The EUID service encrypts tokens using random initialization vectors. The encrypted EUID is unique for a given user as they browse the internet. At every refresh, the token re-encrypts. This mechanism ensures that untrusted parties cannot track a user's identity.

What does an EUID token look like in the bidstream?​

There are many ways to approach EUID implementation. Here is one example of a code snippet showing how an EUID token is passed in the bidstream:

{
  "user":{
    "ext":{
      "eids":[
        {
          "source":"euid.eu",
          "uids":[
            {
              "id":"E3AAAAGnjHikWAL4FRzBh6p+4iKvCFFi3RieJhBg2kCXNT1AjMKev/jreXLPVb2u2IRT7AtZRqpwjFlibf4xaAmJCsdOed9S15igcJiHZ3PR1gOjCmL2HRvN5wMvnvE4CVYCwbLSXjzb6nCqSWL2xPkwMMjZGE7U4S4Xt+jMzQ2uu0vxqfIp5rzAboap5XLrCPHyq6hOQ5dnWZyaEi5TcvBzNIQ="
            }
          ]
        }
      ]
    }
  }
}

FAQs for Advertisers and Data Providers​

Here are some frequently asked questions for advertisers and data providers using the EUID framework.

How do I know when to refresh the EUID due to salt bucket rotation?​

Metadata supplied with the EUID generation request indicates the salt bucket used for generating the EUID. Salt buckets persist and correspond to the underlying personal data used to generate an EUID. Use the POST /identity/buckets endpoint to return which salt buckets rotated since a given timestamp. The returned rotated salt buckets inform you which EUIDs to refresh.

note

We do not make any promises about when the rotation takes place. To stay as up-to-date as possible, we recommend doing the checks once per hour.

Do refreshed emails get assigned to the same bucket with which they were previously associated?​

Not necessarily. After you remap emails associated with a particular bucket ID, the emails might be assigned to a different bucket ID. To check the bucket ID, call the mapping function and save the returned EUID and bucket ID again.

info

When mapping and remapping emails, do not make any assumptions about the number of buckets, their rotation dates, or the specific bucket that an email gets assigned to.

How often should EUIDs be refreshed for incremental updates?​

The recommended cadence for updating audiences is daily.

Even though each salt bucket is updated roughly once a year, individual bucket updates are spread over the year. This means that about 1/365th of all buckets are rotated daily. If fidelity is critical, consider calling the POST /identity/buckets endpoint more frequently—for example, hourly.

How should I generate the SHA-256 of personal data for mapping?​

The system should follow the email normalization rules and hash without salting.

Should I store large volumes of email addresses or their hash mappings?​

Yes. Not storing email address or hash mappings may increase processing time drastically when you have to map millions of addresses. Recalculating only those mappings that actually need to be updated, however, reduces the total processing time because only about 1/365th of EUIDs need to be updated daily.

important

Unless you are using a private operator, you must map email addresses or hashes consecutively, using a single HTTP connection, in batches of 5,000 emails at a time. In other words, do your mapping without creating multiple parallel connections.

How should I handle user opt-outs?​

When a user opts out of EUID-based targeted advertising through the Transparency and Control Portal, the opt-out signal is sent to DSPs and publishers, who handle opt-outs at bid time. We recommend that advertisers and data providers regularly check whether a user has opted out, via the POST /identity/map endpoint.

Advertisers and data providers can also check the opt-out status of raw EUIDs using the POST /optout/status endpoint.

If a user opts out through your website, you should follow your internal procedures for handling the opt-out. For example, you might choose not to generate an EUID for that user.

Does the same personal data always result in the same raw EUID?​

In general yes, the process of generating a raw EUID from personal data is the same, and results in the same value, no matter who sent the request. If two EUID participants were to send the same email address to the POST /identity/map endpoint at the same time, they would both get the same raw EUID in response.

However, there is a variable factor, which is the salt value that's used in generating the raw EUID. The salt values are rotated roughly once per year (for details, see How often should EUIDs be refreshed for incremental updates?). If the salt value changes between one request and another, those two requests result in two different raw EUIDs, even when the personal data is the same.

For more information, see Monitor for salt bucket rotations related to your stored raw EUIDs in the Advertiser/Data Provider Integration Guide.

FAQs for DSPs​

Here are some frequently asked questions for DSPs.

How do I know which decryption key to apply to an EUID?​

Each of the server-side SDKs (see SDKs: Summary) updates decryption keys automatically. Metadata supplied with the EUID token discloses the IDs of the decryption keys to use.

Where do I get the decryption keys?​

You can use one of the server-side SDKs (see SDKs: Summary) to communicate with the EUID service and fetch the latest keys. To make sure that the keys remain up-to-date, it is recommended to fetch them periodically; for example, once every hour.

How many decryption keys may be present in memory at any point?​

There may be thousands of decryption keys present in the system at any given point.

How do I know if/when the salt bucket has rotated?​

The DSP is not privy to when the EUID salt bucket rotates. This is similar to a DSP being unaware if users cleared their cookies. Salt bucket rotation has no significant impact on the DSP.

Should the DSP be concerned with latency?​

The EUID service does not introduce latency into the bidding process. Any latency experienced can be attributed to the network, not the EUID service.

How should the DSP maintain proper frequency capping with EUID?​

The EUID has the same chance as a cookie of becoming stale. Hence, the DSP can adapt the same infrastructure currently used for cookie or deviceID-based frequency capping for EUID. For details, see How do I know when to refresh the EUID due to salt bucket rotation?

Will all user opt-out traffic be sent to the DSP?​

Yes, all opt-outs from the EUID Transparency and Control Portal hit the opt-out endpoint, which the DSP must configure to honor user opt-outs.

Is the DSP expected to handle opt-out signals only for the EUID that they already store?​

In some cases a DSP may receive an EUID token for a newly-stored EUID where the token is generated before the opt-out timestamp. The DSP is not allowed to bid on such tokens. It is therefore recommended to store all opt-out signals regardless of whether the corresponding EUID is currently stored by the DSP or not. For details, see the diagram in Bidding Opt-Out Logic.

How long should the DSP keep the opt-out list?​

We recommend that you keep the opt-out information indefinitely.

Is the EUID of an opted-out user sent to the opt-out endpoint in an encrypted form?​

No. It is sent as an unencrypted (raw) EUID.

In what format is the EUID of an opted-out user sent to the webhook?​

If a user has opted out, the EUID Operator returns the raw EUIDs as URL-encoded query parameters.

For details about the opt-out process for DSPs, see Honor User Opt-Outs.

What request type do opt-outs use?​

Typically GET requests, but different DSPs may use different types.

How strict are the requirements for honoring opt-outs?​

Opt-outs must always be respected. It may take some time for an opt-out request to propagate through the system during which time it is expected that some bids may not honor the opt-out.

How can I check if a user has opted out?​

DSPs can check the opt-out status of raw EUIDs using the POST /optout/status endpoint.

How do SDK errors impact the DSP's ability to respond to a bid?​

If there is an error, the SDK will not decrypt the EUID token into a raw EUID.