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.

note

For FAQs relating to mobile publisher integrations, see FAQs for Mobile Integrations.

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 accessing and using 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. 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.

Should I use a Public Operator or a Private Operator?​

For most participants, Public Operator is the simplest solution. A Public Operator integration is a much easier option than hosting your own Private Operator. Having a Private Operator instance has some advantages, but adds extra complexities and costs.

The best choice depends on your unique scenario and needs. For more information to help you arrive at a decision, refer to the following:

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 that 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.

If I choose to manually refresh the token, how will I know when to refresh the token?​

The recommended refresh interval is hourly.

To determine when to refresh, you can use the timestamp of the refresh_from field in the response to the POST /token/generate endpoint (see Successful Response) or POST /token/refresh endpoint (see Successful Response With Tokens).

You could also use one of the SDKs that has a function to check if token refresh is needed.

For details, see Recommended Token Refresh Frequency and Managing Token Refresh with an SDK.

How can I test the refresh token workflow?​

You can use the refresh-optout@example.com email address or the +00000000002 phone number to test your token refresh workflow. Using either parameter value in a request always generates an identity response with a refresh_token that results in a logout response.

tip

To get the normalized, hashed, and Base64-encoded hashed values for any email address, or the hashed and Base64-encoded hashed values for a phone number, you can use the hashing tool: see EUID Hashing Tool.

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

With SDK:​

  1. Depending on whether the personal data is an email address or a phone number, send a POST /token/generate request using one of the following values:

    • email value: refresh-optout@example.com.
    • email_hash value: The hashed and Base64-encoded value for refresh-optout@example.com, which is NaNI8RU0bL1Jpp1jJLC5aJO/lchc6gGhgXQIAwJ7cV4=.
    • phone value: +00000000002.
    • phone_hash value: The hashed and Base64-encoded value for +00000000002, which is 0VoxsIuk88qt7TnZaTC//C9Vur3pR1zBMIr1cJe7xjE=.

  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. Depending on whether the personal data is an email address or a phone number, send a POST /token/generate request using one of the following values:

    • email value: refresh-optout@example.com.
    • email_hash value: The hashed and Base64-encoded value for refresh-optout@example.com, which is NaNI8RU0bL1Jpp1jJLC5aJO/lchc6gGhgXQIAwJ7cV4=.
    • phone value: +00000000002.
    • phone_hash value: The hashed and Base64-encoded value for +00000000002, which is 0VoxsIuk88qt7TnZaTC//C9Vur3pR1zBMIr1cJe7xjE=.

  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 and the +00000000002 phone number always result in a logged-out user.

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

The EUID service encrypts EUID tokens using random initialization vectors. The EUID token is unique for a given user as the user browses the internet. This means that every time an EUID token is generated, the token is always different, even for the same underlying raw EUID. Every time the token is refreshed, a new token is generated and encrypted.

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":"E4AAAAW2T2Fj-aRzN_G_t-1UP9Ndl-e1kJLCL0b9wTq0UORlRIFjIS4Mz7I3TYy6YrYyIGDwjHWZOifsnYTZawQcCwAkfyp0RbkLhB4Hznodt3ZLHrOYqFmvSrsbEuMrowfoGSJyFz3hj-Q4CArezZzamp1-aoOjJz3s-ydQADH7OapPv5iQBYBiWza3r3tBVY7drUMV8_08aBMqHuLyKzNUvws"
            }
          ]
        }
      ]
    }
  }
}

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 mapping of email addresses, phone numbers, or corresponding hashes to raw EUIDs in my own datasets?​

Yes. Not storing mappings may increase processing time drastically when you have to map millions of email addresses or phone numbers. 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, phone numbers, or hashes consecutively, using a single HTTP connection, with a maximum batch size of 5,000 items per batch. 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.

If two operators process the same personal data, are the results the same?​

Yes, if the request is for a raw EUID. As covered in the previous FAQ, Does the same personal data always result in the same raw EUID?, if an advertiser or data provider sends the same personal data to the EUID Operator, by using an SDK or the POST /identity/map endpoint, at the same time, the same raw EUID is created.

The result is the same, regardless of the Operator and whether it's a Private Operator or a Public Operator.

The timing is important only because of salt bucket rotation. If the salt value changes between one request and another, the result is a different raw EUID.

However, if a publisher sends personal data in a request for an EUID token, via the POST /token/generate or POST /token/refresh endpoint or via an SDK, the resulting EUID token contains the same encrypted raw EUID, but the token itself is always unique.

FAQs for DSPs​

Here are some frequently asked questions for demand-side platforms (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.