According to the UID2 DSP guide, a DSP receives UID2 tokens in bid requests and decrypts them with a server-side SDK to get raw UID2 values it can use for bidding. The guide also requires the DSP to honor opt-outs: an opted-out UID2 must not be used for real-time bidding. This article covers only that DSP-side flow.

What is UID2, and where does it sit next to OpenRTB?

The UID2 overview describes UID2 as a framework for deterministic identity on the open internet. The term can mean the framework or an identifier. UID2 is a named third-party service with its own documentation, so a DSP follows that guide the way it would follow a vendor integration guide, not an OpenRTB specification.

The overview says the source code for its component services is public and that all work and artifacts are licensed under the Apache License, Version 2.0. It also says consumers can opt out at any time through the Transparency and Control Portal.

How does the token flow work?

In the DSP guide, the token is what travels in the bid request and the raw UID2 is what the DSP uses to bid. A bid is handled in this order:

  1. A bid request arrives carrying a UID2 token.
  2. The DSP decrypts the token with a server-side SDK. The response contains the raw UID2 and the UID2 creation time.
  3. The DSP checks that raw UID2 against the opt-outs it has recorded, because the guide says DSPs are required to honor the opt-out protocol.
  4. If the user has opted out, the UID2 must not be used for RTB. The DSP can bid with an alternate ID or choose not to bid. Which of the two it does is the DSP’s decision, not the guide’s.

A DSP can only decrypt a token that actually arrives in the bid request. Coverage therefore depends on what each placement sends, and this article gives no reach figure because the guide gives none.

What are the opt-out duties?

Opt-outs reach a DSP in two ways, according to the guide:

  • Webhook. The DSP sets up an endpoint and gives its address to the UID2 service. When a user opts out, the service sends the raw UID2 and the opt-out time within seconds, as two parameters named identity and timestamp. The guide marks the timestamp as informational. The DSP must answer with a 200 response code.
  • Status endpoint. The DSP can check the opt-out status of raw UID2s by calling POST /optout/status.

One detail deserves a test. The webhook timestamp is a Unix time in seconds, while the opted_out_since value from POST /optout/status is a Unix time in milliseconds. A parser that treats one as the other produces wrong dates. The guide’s own example webhook address uses the placeholder host dsp.example.com, and a test fixture can do the same.

How does a DSP keep latency low?

The guide’s latency advice refers to its C# and .NET example code, and says the Java, Python and C++ SDKs use similar method names. For a low-latency, high-throughput setup it recommends:

  • Keep a local BidstreamClient instance on each server, in-process or out-of-process. In-process is the easiest.
  • Call the client’s Refresh method in the background on a schedule, for example once per hour, with some randomization so servers restarted together do not all call at once.
  • Call DecryptTokenIntoRawUid when a token needs decrypting. In-process is fastest, and the method is thread-safe.

What does UID2 not tell a buyer?

The guide describes a mechanism, not a result. It does not say how many impressions carry a token, how often tokens decrypt, or how a UID2-based campaign performs. Any buyer who wants those numbers should measure them in their own bid logs, per placement, before planning around them.

How does Vectravia handle this?

Audience Lab activates UID2 tokens where publishers pass them. It decrypts them as the UID2 DSP guide describes and honors opt-outs. The coverage question above still applies, and a buyer should ask for token coverage by placement.