What is ID bridging in programmatic advertising?
Short answer
ID bridging is populating a device or user identifier in a bid request with one that was not actually observed on that impression: reusing a stale IFA, filling device.ifa on inventory that cannot legitimately carry one, or passing a probabilistic household match as if it were deterministic. The buyer sees a targetable, cappable identifier and pays accordingly; what it bought was a guess. No validator can detect it from a single payload, but the EID provenance fields added in OpenRTB 2.6-202409 (inserter, matcher, mm) plus consistency between device.ifa, lmt, and dnt make the origin of an ID inspectable.
What the practice is
A bid request is a set of claims about one impression opportunity. Some of those claims are structural (this is a 1080 by 1920 screen), some are contextual (this is a sports app), and some are about who is on the other end: device.ifa, user.id, user.buyeruid, and the extended identifiers in user.eids.
ID bridging is populating that last category with an identifier that was not observed on this impression. Common shapes: reusing an identifier seen on a different device in the same household, carrying a stale identifier forward long after it was collected, or filling device.ifa on inventory that structurally cannot produce one. The request stays valid. The buyer's model of the world does not.
Why it pays
Addressable inventory clears higher than anonymous inventory. A CTV impression with a usable device identifier can be targeted to a segment, capped against previous exposures, and attributed to an outcome, so it commands a premium over the same impression sold blind. Anyone in the middle who can attach an identifier captures that premium, and the cost of being wrong lands on the buyer's measurement rather than on the seller's invoice.
That asymmetry, easy to do, hard to detect, valuable when undetected, is what makes this a structural problem rather than a matter of a few bad actors.
The fields that make provenance checkable
| Field | Since | What it should tell you |
|---|---|---|
user.eids[].source | 2.6 | The canonical domain of the ID provider, the namespace for the value |
user.eids[].uids[].atype | 2.6 | Agent type: which kind of agent the ID was observed on |
user.eids[].inserter | 2.6-202409 | The entity that inserted the ID into the request |
user.eids[].matcher | 2.6-202409 | The entity that performed the match, which is often not the inserter |
user.eids[].mm | 2.6-202409 | ID match method, from the AdCOM ID Match Methods list |
device.ifa, device.lmt, device.dnt | 2.x | The platform identifier and the user's tracking preference |
The 2.6-202409 snapshot exists precisely because buyers asked to know how an identifier was derived. An eids entry that names an inserter, a matcher, and a match method is making an auditable claim. One that supplies a bare id and nothing else is asking to be trusted. Field-level detail is in OpenRTB user identity: eids and buyeruid.
What you can actually check
- Structural validity. Every
eidsentry has asourceand a non-emptyuidsarray,atypeandmmhold values defined in the AdCOM lists rather than invented integers, and the whole block is underuser.eidsrather than the pre-2.6user.ext.eidspath. RTBlint reports these asopenrtb.value.invalid,openrtb.field.moved, andopenrtb.type.mismatch. - Internal consistency. A populated
device.ifaalongsidelmtset to 1 is a contradiction: the user asked not to be tracked and an identifier arrived anyway. - Plausibility at fleet scale. Identifier cardinality per app bundle, churn rate per supply path, and the share of requests carrying an ID on device types that rarely expose one. Bridging shows up as a distribution anomaly across millions of requests, never as a single bad payload.
- Path accountability. Correlate the anomaly with
source.schainnodes to find which intermediary introduces it, then treat it as a supply path decision.
The honest limit
No payload validator, RTBlint included, can tell you whether an identifier is real. It can tell you whether the request is structurally capable of carrying provenance, and it can hold your fixtures to that standard in CI so the fields you would need for an investigation are present when you need them. Paste a request with an eids block into the tester to see what survives validation and what does not.