Transaction IDs in Prebid just changed. Here’s what Publishers need to know.

Prebid.js 10.9.0 (released 27 Aug, 2025) now generates a different Transaction ID (TID) for each Bidder. That breaks the long-standing practice where one TID was shared across exchanges/paths for the same impression, which DSPs used to de-duplicate auctions and power SPO. The IAB Tech Lab says the change is “materially non-compliant” with OpenRTB and is calling for a collaborative fix.

What is a Transaction ID (TID) in programmatic?

In OpenRTB, source.tid is an auction-level identifier meant to be the same for all participants who see the same impression opportunity – across SSPs, exchanges, and paths. Buyers use that shared key to detect duplicates and avoid bidding against themselves. The spec describes tid as “common across all participants in this bid request.”

How Prebid treated TIDs until now

Prebid exposed two places for IDs that map to this concept:

• ortb2.source.tid: auction identifier
• ortb2Imp.ext.tid: impression/Ad unit identifier

If you turned them on, Prebid generated one TID per Ad unit per auction and sent the same value to every Bidder – aligning with how DSPs deduplicated requests.

The change: bidder-specific TIDs (Prebid.js 10.9.0)

On 27 Aug, 2025, Prebid.js 10.9.0 shipped a core change: Prebid now generates unique TIDs per Bidder instead of one shared ID across all exchanges/paths. Concretely:

• ortb2.source.tid is unique per Bidder
• ortb2Imp.ext.tid is generated per Bidder × transaction
• Adapter-visible .auctionId/.transactionId now reference those ORTB2 fields
• Publisher-provided first-party values are ignored for these fields

This change affects Prebid.js; similar logic would need separate rollout in Prebid Server. Impact: buyers can no longer use a shared cross-exchange TID to spot duplicates. That removes the deduplication mechanism many DSPs used for SPO and bid-collision control. Of course, that applies only to auctions run through Prebid 10.9.0 (or newer if released when you read this article).

Standards view: IAB Tech Lab’s objection

OpenRTB’s intent is clear: TID should be common across participants. The IAB Tech Lab publicly said Prebid’s new behavior is “materially non-compliant with the OpenRTB specification” and urged the industry to address concerns through the spec process, not unilateral changes.

The Publisher perspective: risks, trade-offs, and what to do next

1. Yield protection vs. buyer efficiency A shared TID helps DSPs cut waste – but it can also expose your effective floors and path economics across SSPs. If buyers can “map” your paths, they may favor cheaper routes or avoid deals/PMPs, pressuring net CPMs. Bidder-specific TIDs reduce that stitching risk.
2. Privacy & contractual posture Some publishers have contractual limits on data sharing and want to minimize cross-party joins that piece together user or deal metadata. Prebid previously made TIDs opt-in for similar reasons; the bidder-specific shift extends that posture.
3. Auction integrity means different things Buyers see integrity as avoiding duplicate auctions. Publishers see it as keeping competition strong without exposing pricing or path details. Without a clear standard, buyers may push you to make paths more transparent for SPO.
4. Product reality: change is opt-in Nothing flips on unless you enable TIDs. With 10.9.0+, enabling TIDs gives you Bidder-scoped TIDs by default; you cannot force a single cross-exchange TID from Prebid.js anymore. (Prebid Server would need its own update to match).

Practical guidance for Publishers

Decide at the Domain level (recommended):

• If you enabled TIDs to help a key buyer deduplicate, check if Bidder-specific TIDs still meet their needs. Many DSPs will now use heuristics (GPID/Ad unit, timestamps, SSP seller IDs) to deduplicate.
• If you kept TIDs off for privacy or yield, 10.9.0 helps: you can enable TIDs without exposing a shared cross-SSP join key.

Configuration checklist (Prebid.js):

• Audit your wrapper version. If moving to 10.9.0+, document that TIDs are Bidder-specific.
• If you want any TID at all, set pbjs.setConfig({enableTIDs:true}). Keep a runbook that explains to commercial teams what this means for SPO conversations.

Signals to offer instead of shared TID (case-by-case):

• GPID (global placement) and stable Ad unit identifiers
• Deal hygiene: clean, consistent naming and clear package structures reduce buyer need to infer paths
• Server-side parity: if you use Prebid Server, coordinate with your Vendor to keep policies aligned

You can also prepare a brief FAQ for demand partners explaining why your TIDs are Bidder-scoped and which alternative “deduplication” signals you support.

Measurement:

Track bid density, win rate, and net CPM by SSP before/after upgrading. If buyers change routing behavior, you’ll see it quickly.

Where this likely lands

There’s a standards gap: OpenRTB expects one shared TID, but Prebid.js now makes TIDs Bidder-specific. IAB Tech Lab is calling for a joint fix. Possible options include publisher-controlled scope, privacy guards, or a dedup-only token. Until then, expect context-based buyer deduplication and more one-off policies.

Bottom line for Publishers

• If you value yield protection/path opacity: 10.9.0 is aligned with your goals; you can enable TIDs without exposing a universal join key.
• If a key buyer insists on dedup via TID: align expectations – Prebid can’t provide a cross-exchange TID client-side anymore; offer GPID/placement stability and collaborate on heuristics.
• Stay engaged with standards: the outcome will shape SPO, privacy, and data rights for years.