Blog · Privacy

What is bidstream data? Everything a bid request broadcasts, field by field

July 14, 2026 · rtblint

"Bidstream data" used to be industry shorthand. Now it appears in federal enforcement orders. The term means something precise: the data carried inside OpenRTB bid requests, broadcast to every party invited to an auction, whether they bid or not. Nothing about it involves a breach or a hack. It is the protocol doing exactly what the protocol says. This post maps the term to the actual fields, because the privacy conversation and the engineering conversation are about the same JSON.

Where the term comes from

On January 14, 2025, the FTC finalized orders against two data brokers, Mobilewalla and Gravy Analytics, over the collection and sale of sensitive location data. The Mobilewalla case was the FTC's first action aimed squarely at bidstream collection: the complaint described a company that participated in RTB auctions, received bid requests containing mobile advertising IDs and precise geolocation, and retained that data even when it did not win the auction. The final order prohibits collecting or retaining consumer data from RTB exchanges for any purpose other than participating in the auction itself.

That is the mechanism to understand: losing an auction still means receiving the request. A bidder invited to a hundred billion auctions a day receives a hundred billion payloads a day, and until recently nothing but contract language governed what it kept.

What a bid request actually carries

The bid request exists to let bidders value an impression, and value comes from context. The spec therefore defines fields for exactly the data the privacy debate is about:

Location. device.geo carries lat and lon, with a type field distinguishing GPS-derived coordinates (type 1) from IP-derived ones (type 2), plus accuracy in meters. device.ip and ipv6 locate the device even when the geo object is absent.
Identity. device.ifa is the mobile advertising identifier the Mobilewalla order is about. user.id, user.buyeruid, and the user.eids array carry exchange, buyer, and third-party identifiers.
Device fingerprint surface. device.ua or the structured device.sua, plus make, model, os, osv, screen dimensions, carrier, and connection type.
Context that classifies the person. site.page is the URL being read. app.bundle names the app in use, and the app itself is a signal: a bid request from a health tracker, a dating app, or a prayer app says something about its user before any other field is read. The content object can add title, genre, and language.

A stripped-down but realistic mobile request:

{
  "id": "b7c1...",
  "imp": [{ "id": "1", "video": { "mimes": ["video/mp4"] } }],
  "app": { "bundle": "com.example.periodtracker" },
  "device": {
    "ifa": "8a6f3b2e-...",
    "ip": "203.0.113.44",
    "geo": { "lat": 52.2297, "lon": 21.0122, "type": 1, "accuracy": 10 },
    "make": "Apple", "model": "iPhone15,3", "os": "iOS"
  },
  "user": { "id": "u-91f..." }
}

Every recipient of this request learns that a specific device, at specific GPS coordinates, is using a specific reproductive health app right now. That inference requires no data science. It is the payload, read once.

The fan-out is the point

A single impression does not generate one bid request. The exchange fans it out to every connected bidder eligible for the auction, and resellers can fan it out again. Dozens to hundreds of companies can receive the payload for one ad slot, and exactly one of them wins. The rest received the data as the cost of asking them to bid.

The protocol has no mechanism to audit what recipients retain. HTTP requests do not come with a delete button. This is why the policy fight landed where it did: the FTC order does not change the protocol, it changes what a specific recipient is allowed to do with what the protocol delivered.

What the protocol can say, and what it cannot do

OpenRTB carries the legal context alongside the data. The privacy signals: regs.gdpr flags GDPR scope, user.consent carries the TCF consent string, regs.gpp and gpp_sid carry the Global Privacy Platform string, regs.coppa flags children's services, and device.lmt says the user limited ad tracking, which should zero out ifa.

These fields describe obligations. They do not enforce them. A consent string is an instruction to the recipient, and the recipient's compliance happens in the recipient's infrastructure, invisible to the sender. The protocol's honest contribution to privacy is different: it gives the sender precise control over what goes into the request in the first place. Senders can truncate IPs, coarsen geo to city level, omit eids for unconsented traffic, and drop ifa when lmt is set. Every one of those is a field-level decision in code you own.

If you send bid requests, you are publishing data

The practical takeaway for a seller or exchange is to treat the bid request as a publication, because that is what fan-out makes it. That means knowing exactly what your requests contain, per partner, per traffic type:

Inventory your emitted fields. Not what your docs say you send; what production actually sends. Paste a live request into the tester and read it as a stranger would.
Audit your ext blobs. SDKs and intermediaries attach custom ext objects that ride along unreviewed. Unknown fields are where surprising data hides.
Check the lmt and coppa logic. lmt=1 with a populated ifa is a contradiction your pipeline should catch, not your partner's compliance team.
Send privacy signals at the paths your partners read. A consent string at a path the recipient does not parse protects no one. Version mismatches turn correct signals into absent ones.
Minimize by default. Precision is a choice. If a buyer does not need GPS-grade coordinates to price your inventory, city-level geo bids nearly the same and publishes much less.

Sources

The OpenRTB specification is published by IAB Technology Laboratory under a Creative Commons Attribution 3.0 License. Field definitions referenced here are drawn from it; the analysis is our own. rtblint is independent and not affiliated with IAB Tech Lab.