Is bidstream data personal data under GDPR?

Why the answer is usually yes

GDPR Article 4(1) defines personal data as information relating to an identified or identifiable natural person, and it names online identifiers explicitly as a way a person can be identified. A standard OpenRTB bid request carries several at once, all tied to a single moment of browsing:

Any one of these might be argued about in isolation. Together, in one message, about one person, at one instant, they are what the definition was written to cover. The field-by-field breakdown is in what is bidstream data.

What the courts and regulators have said

The most cited decision is the Belgian Data Protection Authority's 2022 finding against IAB Europe's Transparency and Consent Framework, followed by the Court of Justice of the EU in Case C-604/22 in March 2024. The Court held that a TC String is personal data when it can be combined with an identifier such as an IP address, and that IAB Europe is a joint controller for that processing.

Note the shape of that reasoning, because it generalises: the string alone is not obviously about a person, but it travels next to an IP address, and the combination makes the person identifiable. The same logic applies to most of the fields above, which is why arguments of the form "this single field is not personal data" rarely survive contact with how a bid request is actually structured.

What the protocol gives you to work with

OpenRTB does not decide legality; it carries the declarations. The signals that matter, with their exact paths:

• regs.gdpr (0 or 1): whether the request is subject to GDPR, first-class since 2.6, previously regs.ext.gdpr.
• user.consent: the TCF consent string, first-class since 2.6, previously user.ext.consent.
• regs.gpp and regs.gpp_sid: the Global Privacy Platform string and the section ids it contains. These two are a pair; one without the other is unusable, which is why RTBlint flags openrtb.regs.gpp_without_gpp_sid and openrtb.regs.gpp_sid_without_gpp.
• regs.coppa, device.lmt, device.dnt: child-directed treatment and the user's tracking preference.

Full paths, versions, and the migration from the ext locations are in the privacy signals reference.

The engineering consequences

1. Correctness of the signal is a compliance artefact. A request that says regs.gdpr is 1 with no user.consent, or a GPP string with no section ids, does not fail safe: it fails ambiguously, and every downstream recipient resolves the ambiguity its own way.
2. Old paths still leak. Sending consent only at user.ext.consent means partners reading the 2.6 path see no consent at all. RTBlint reports this as openrtb.field.moved.
3. Minimisation is a field-level decision. Precise coordinates, full IPs, and identifiers with no legitimate downstream use are the ones that draw scrutiny. Coarsening them is a change to the payload, which means it is testable.
4. Every recipient is a decision. A bid request is broadcast to many bidders at once, so the number of parties receiving the data is a design choice, and it is visible in source.schain and your partner list.

Validate the privacy block on real traffic in the tester, and keep a fixture per market in CI so a refactor cannot silently drop a consent field.

Scope of this answer

This page describes how the fields work and what has been decided publicly. It is engineering guidance for people building bid requests, not legal advice, and it does not address whether any particular processing has a valid legal basis. That question depends on your role, your jurisdiction, and facts that are not in the payload.

Sources

• GDPR Article 4(1): definition of personal data
• Court of Justice of the EU, Case C-604/22, IAB Europe v Gegevensbeschermingsautoriteit
• OpenRTB 2.6: Regs (3.2.3), User (3.2.20), Device (3.2.18)
• IAB Tech Lab Global Privacy Platform