Category: TCF and Vendors
OpenRTB
Also known as: Open RTB, OpenRTB Protocol
Simply put
OpenRTB is a standardized protocol that enables real-time bidding (RTB), the practice of buying and selling individual online ad impressions through instantaneous automated auctions. When a webpage or app loads, an ad impression can be put up for bid, and advertisers compete in real time to display their ad to that specific user. It is maintained as an open industry standard rather than being owned by any single company.
Formal definition
OpenRTB is an open protocol, developed and maintained by the IAB Technology Laboratory, that defines the standardized communication and data structures used for conducting real-time bidding on digital ad impressions between supply-side and demand-side systems (such as ad exchanges, SSPs, and DSPs). It specifies request and response formats, commonly implemented in JSON, with some implementations also supporting Protocol Buffers, that allow individual impressions to be offered for auction and bid on programmatically within the time it takes a page or app to render. OpenRTB is a general programmatic advertising protocol and is distinct from consent frameworks such as the IAB Transparency & Consent Framework (TCF); while consent signals may be passed within bid requests, the protocol itself governs the auction mechanics rather than establishing the legal validity of consent. The privacy implications of data flows within OpenRTB bid requests, including whether they constitute processing of personal data under the GDPR, remain a contested area and are outside the scope of this definition.
Why it matters
OpenRTB underpins much of the programmatic advertising ecosystem, defining how individual ad impressions are offered and bid on in the fraction of a second it takes a page or app to load. For privacy and compliance professionals, its significance lies in the fact that bid requests exchanged during these auctions can carry a range of information about the user and their context. Whether, and to what extent, such data flows constitute the processing of personal data under the GDPR is a contested area that has drawn scrutiny from data protection authorities and privacy advocates in the EU and UK. This definition does not attempt to resolve that debate, but the volume and breadth of these automated exchanges is why the topic recurs in regulatory and legal discussions.
Who it's relevant to
Privacy officers and data protection professionals
Those responsible for GDPR and ePrivacy compliance may need to understand OpenRTB because bid requests can carry information about users, and the question of whether such flows involve processing of personal data is a contested area under EU and UK law. Understanding that OpenRTB defines auction mechanics, and not the legal validity of consent, helps in scoping where compliance responsibilities actually sit.
Legal counsel and compliance teams
Lawyers advising on programmatic advertising should note that OpenRTB is a general industry protocol maintained by the IAB Technology Laboratory, distinct from the TCF. Consent signals may be transmitted within bid requests, but the protocol does not by itself demonstrate that consent was freely given, specific, informed, and unambiguous, or that other jurisdictional requirements are met. Legal judgment remains necessary.
Ad operations and marketing technology teams
Teams integrating with ad exchanges, SSPs, and DSPs work directly with OpenRTB's standardized JSON (and, in some implementations, Protocol Buffers) request and response formats. Understanding how impressions are offered and bid on in real time is essential to configuring integrations, though technical implementation should be aligned with the organization's separate consent and compliance controls.
Web and app developers
Developers who embed advertising into websites or applications trigger OpenRTB auctions when a page or app loads and an impression is put up for bid. Awareness of how these automated exchanges operate helps developers coordinate with privacy teams on where and how consent signals and data handling need to be addressed, since the protocol itself does not resolve those questions.
Inside OpenRTB
Bid Request
A structured data message sent from a publisher's supply-side platform to prospective buyers, offering an available advertising impression. In the cookie consent context, bid requests may carry user-related identifiers and signals that can constitute personal data, which brings the transmission within the scope of the GDPR where EU users are involved.
Bid Response
The reply from a demand-side platform or bidder indicating a bid amount and the creative to be served. The processing and onward sharing of user data during this exchange may require a lawful basis and, for the placing of or access to identifiers on a device, prior consent under the ePrivacy Directive in most EU jurisdictions.
User and Device Identifiers
Fields that may include cookie IDs, device identifiers, IP addresses, or other signals. These are frequently treated as personal data under the GDPR, and reading identifiers already stored on a device generally engages ePrivacy consent obligations in the EU.
Consent and Transparency Signals
OpenRTB requests can carry fields intended to communicate a user's consent status or applicable privacy signals to downstream participants. These extension fields depend on the accuracy of the upstream consent capture; carrying a signal does not by itself establish that valid consent was obtained.
Supply Chain Participants
The publishers, exchanges, SSPs, DSPs, and other vendors that receive and process the bid request. Each participant that processes personal data typically has its own accountability obligations, and the number of recipients has implications for the 'informed' element of consent under EU law.
Common questions
Answers to the questions practitioners most commonly ask about OpenRTB.
Is OpenRTB part of the IAB Transparency and Consent Framework (TCF)?
No. OpenRTB is a general programmatic advertising protocol that standardizes how real-time bidding requests and responses are exchanged between publishers, ad exchanges, and demand-side platforms. It is distinct from the TCF, which is a separate framework designed to communicate consent and other transparency signals among participating vendors. The two can interoperate, consent signals produced within the TCF may be passed alongside or referenced by bid requests, but OpenRTB itself is not a consent framework and does not, on its own, establish a valid legal basis for processing. Treating OpenRTB compliance and TCF compliance as the same thing is a common misconception.
Does using OpenRTB automatically mean cookie consent has been handled correctly?
No. OpenRTB is a technical transport mechanism for bidding data; it does not obtain, record, or validate consent by itself. In most EU jurisdictions, the placing of and access to information on a user's device is governed by the ePrivacy Directive as implemented nationally, and any subsequent processing of personal data must have a valid basis under the GDPR. Whether the data flows involved in a bid request are lawful depends on factors outside the protocol, such as whether valid consent was collected beforehand and how it is signaled. Requirements also differ outside the EU, for example, several US state regimes rely on opt-out rather than opt-in. Using OpenRTB does not substitute for that separate consent and legal-basis analysis.
How can consent signals be conveyed within an OpenRTB bid request?
OpenRTB provides fields that can carry regulatory and consent-related information alongside the bidding data, allowing downstream vendors to receive a representation of the user's choices. In practice, organizations operating in the EU often populate these fields with signals generated by their consent management platform (CMP), which may include TCF-based strings where the CMP participates in that framework. The exact fields, formats, and expectations depend on the OpenRTB version in use and on any additional frameworks layered on top. The presence of a field, however, does not guarantee that the consent it represents was validly obtained; that remains a separate question of fact and legal judgment.
What is the relationship between a CMP and OpenRTB in a live implementation?
A CMP is generally responsible for presenting consent choices to the user, capturing those choices, and producing a machine-readable signal, while OpenRTB is the protocol that transports bidding data, potentially including that signal, between systems. In a typical setup, the CMP runs first to collect the user's decision, and the resulting signal is then made available so it can be inserted into subsequent bid requests. The two components serve different roles: the CMP supports collection and record-keeping, and OpenRTB handles transmission. Neither, on its own, ensures compliance; they are supporting tools that must be configured consistently with the applicable legal requirements.
Do non-cookie technologies referenced in OpenRTB bid requests fall under the same consent rules as cookies?
Where they involve placing or accessing information on a user's device, similar technologies are generally treated the same way as cookies under EU rules. Bid requests can carry device- and identifier-related information derived from pixels, local storage, mobile SDKs, or other identifiers, and the use of such techniques, including fingerprinting-style methods, typically falls within the same ePrivacy and GDPR obligations even though they are not literally cookies. Whether prior consent is required depends on the specific technology, its purpose, and the jurisdiction, so each identifier flow should be assessed rather than assumed to be exempt.
What should be logged or retained when consent signals are passed through OpenRTB?
Consent record-keeping is generally handled at the CMP or consent-collection layer rather than by the OpenRTB transport itself, since the protocol transmits a representation of a choice rather than proof of how it was obtained. Organizations subject to the GDPR are typically expected to be able to demonstrate that valid consent was collected, which usually means retaining records of what the user was shown and what they chose. The signal carried in a bid request may reflect that choice but does not by itself constitute an auditable record. The specific retention practices and their sufficiency depend on the applicable framework and evolving guidance from data protection authorities, and are outside the scope of the protocol definition.
Common misconceptions
OpenRTB is part of the IAB Transparency and Consent Framework (TCF).
OpenRTB is a general programmatic advertising protocol that defines how bid requests and responses are exchanged. It is distinct from the TCF, which is a separate consent-signaling framework. The two are sometimes used together, TCF consent strings can be passed within OpenRTB fields, but OpenRTB itself is not a consent framework and does not establish the validity of consent.
Passing a consent signal within an OpenRTB request means valid consent has been obtained.
A consent field only communicates a claimed status; it does not verify that consent was freely given, specific, informed, and unambiguous as required under the GDPR, nor that any ePrivacy consent for accessing device identifiers was validly captured. Whether the underlying consent is valid depends on how it was collected, which is outside the protocol itself.
Because OpenRTB is a technical advertising standard, only web developers need to worry about it, not privacy or compliance teams.
Bid requests routinely include identifiers and signals that may constitute personal data, and the associated reading of device identifiers generally engages both GDPR and ePrivacy obligations in the EU. This makes OpenRTB data flows a matter of concern for privacy, legal, and compliance functions, not solely technical teams. Requirements and enforcement positions differ across the EU, the UK, and individual US states.
Best practices
Map which OpenRTB fields in your bid requests may carry personal data (such as cookie IDs, device identifiers, or IP addresses) and document the lawful basis and, where relevant, the ePrivacy consent that supports transmitting them, noting that requirements differ between the EU, UK, and US state regimes.
Ensure that any consent or privacy signals passed within OpenRTB requests are derived from validly captured consent at the point of collection, and do not rely on the presence of a signal alone as evidence of compliance.
Assess the downstream supply chain of recipients when relying on consent in the EU, because the number and identity of vendors receiving the data bear on whether users have been adequately informed.
Coordinate between technical, marketing, and privacy or legal teams so that OpenRTB implementation choices reflect current data protection guidance rather than being treated as a purely engineering decision.
Where OpenRTB is used together with a consent framework such as the TCF, keep the two conceptually separate in your documentation and verify that consent strings are only populated when the corresponding consent is genuinely present.
Treat consent management tooling and signal-passing as support for compliance rather than a guarantee of it, and obtain legal judgment on contested points such as how bid-stream data sharing is treated in your target jurisdictions.
