What bidstream data is and how publishers control it

Bidstream data is the information packed into every bid request your page sends to ad buyers: the page URL, the device, a rough location, user IDs and consent signals. Buyers read it to decide what to bid. Every bidder that gets the request sees it, whether it wins or not.

That last part is the problem. You might send one impression to ten bidders through Prebid and Ad Manager, and only one of them buys it. The other nine still saw who your reader was and what they were reading. Calling fewer bidders where they never buy is the idea behind traffic shaping in your own wrapper.

Most guides stop at "it's anonymous and useful for targeting", which isn't the full picture. This guide shows what your own bid requests carry, who gets to keep it, and the settings that limit it. If the auction itself is new to you, start with our guide to how real time bidding works.

What is bidstream data?

Bidstream data is the data inside the stream of bid requests that sellers send to buyers during programmatic auctions. "The bidstream" just means all those requests flowing out, millions a second across the web. The data is whatever each request carries.

Almost all of it follows one format: IAB Tech Lab's OpenRTB. The current line is OpenRTB 2.6, which since its 2.6-202211 release only changes its version number on breaking changes. IAB Tech Lab's OpenRTB page now keeps the full version history on GitHub. So when someone says "bidstream data", they mostly mean the fields of an OpenRTB bid request.

Here's the thing to hold on to. Bidstream data isn't a product you choose to sell. It's a side effect of selling ads in an auction. You can't switch it off without switching off programmatic demand, but you can decide how much goes into it.

What's inside bid request data, block by block

An OpenRTB bid request is a JSON object made of a few blocks. Each one tells buyers something different. This table maps the main blocks in the 2.6 spec to what they reveal about your reader.

A few spec details are worth knowing. The user.id field is expected to be "the exchange's user ID from its cookie", and buyeruid comes from an ID sync (our post on how cookie syncing matches those IDs explains the mechanics). The app field ifa is an ID "sanctioned for advertiser use in the clear (i.e., not hashed)". And the old yob and gender fields were deprecated in 2.6.

How bidstream data is collected

Bidstream data is collected the moment your ad code runs. Your page builds a request, an SSP or exchange adds its own fields, and the request goes out to every connected buyer at once. If those tool names are new, our plain-English map of ad tech shows who does what.

On a typical site with Prebid and Ad Manager, the path looks like this:

1. Your page loads. Your consent banner sets the TCF or GPP string, and Prebid's consent module reads it.
2. Prebid builds a request for each bidder, adding any user IDs and first-party data you've configured.
3. Each SSP adds what it knows: its own cookie ID, IP-based location, its supply chain node.
4. The SSP fans the request out to the DSPs it works with. Each DSP may then pass it to its own bidders.
5. Buyers reply with bids. One wins. Every buyer along the way has already seen the request.

That fan-out is why one page view can put your reader's data in front of dozens of companies. The schain object shows some of the path, but only on the selling side. You can't see which buyers received the request downstream.

How bidstream data is used, and why buyers want it

Buyers use bidstream data first to price your impression. A DSP checks the page category, the device and the user ID against its campaigns and its own records, then decides how much the impression is worth. That's the honest, intended use, and it's why richer requests often get higher bids.

Some companies use it for other things. Here are the uses publishers worry about most:

• Profile building. A bidder logs the user ID and page URL from requests it never wins, and learns what each reader reads.
• Bidstream location data. In apps, requests can carry precise GPS plus the advertising ID. Collected over time, that's a movement history.
• Audience resale. A buyer learns that your readers are, say, keen home cooks, then targets the same people on cheaper sites.

The last one is what ad-ops people call data leakage. You did the work of building the audience, and someone else gets to buy it without paying your price. Nobody can measure exactly how much of this happens. The safer working assumption is that anything you put in the bidstream may be stored.

Bidstream data privacy: is it anonymous?

No, not by default. Bidstream data contains IP addresses, device IDs, user IDs and sometimes precise location. Each of those can single out a person or a device, and some vendor guides still describe it as free of personal data, which is wrong.

Regulators have noticed. In December 2024 the FTC acted against Mobilewalla, saying it "collected data from real-time bidding exchanges and third-party aggregators". The FTC's announcement says the company kept the information in the bid request "even when it didn't have a winning bid". The order bans it from collecting consumer data from ad auctions for purposes other than taking part in them. The FTC called it the first time it had alleged that practice was unfair.

The spec itself puts the duty on the sender. On extended IDs, OpenRTB 2.6 says "the exchange should ensure that business agreements allow for the sending of this data". It also says each implementer is responsible for complying with the law. In practice that means you, your SSPs and your consent setup share the job.

What the consent strings do, and don't do

Consent strings travel inside the request. user.consent carries the TCF string, and regs.gpp carries the Global Privacy Platform string. Prebid's TCF consent module fetches the string from your CMP and adds it to the auction so adapters can read it.

A string records what the reader chose. It doesn't stop a bidder from receiving the rest of the request. That's why the controls in the next section matter: they decide what's in the request before it leaves your page.

How publishers control bidstream data

You control bidstream data at three points: your Prebid config, your Ad Manager settings and your SSP contracts. Start with Prebid, because that's where you have the most direct say over each bidder.

Prebid activity controls

Since version 7.52, Prebid.js has activity controls, one central place to allow or deny privacy-sensitive actions per bidder or module. The ones that shape the bidstream are these:

• transmitEids: whether a bidder gets your user IDs.
• transmitUfpd: whether a bidder gets user first-party data.
• transmitPreciseGeo: if denied, the bidder gets latitude and longitude at 2-digit precision only.
• syncUser: whether a bidder can run user syncs on your page.
• fetchBids: whether a bidder takes part in the auction at all.

This example stops one bidder from receiving user IDs while every other bidder keeps them. Swap in the bidder code you want to restrict.

pbjs.setConfig({
  allowActivities: {
    transmitEids: {
      rules: [{
        condition: ({componentName}) => componentName === 'exampleBidder',
        allow: false
      }]
    }
  }
});

Limit user IDs and first-party data to named bidders

Prebid's User ID module takes a bidders array per ID: "an array of bidder codes to which this user ID may be sent". Leave it out and the ID goes to every adapter. We'd set it for any ID a partner gave you on contract terms.

First-party data works the same way. Prebid's first party data docs put site data in ortb2.site and user data in ortb2.user, and setBidderConfig() sends a block only to the bidders you list. Our first party data strategy guide covers which segments are worth sending in the first place.

Google Ad Manager and Authorized Buyers

On Google's side, much of the trimming happens for you. Google's OpenRTB guide for Authorized Buyers says the IP field can be "truncated: IPv4 to /24 or IPv6 to /48", with the cut part replaced by zeros. A privacy_treatments object tells buyers what was coarsened, including the user agent.

The PPID is yours to share or not. Google's PPID help page says it's an Ad Manager 360 feature, must be hashed or encrypted, and lets you "choose who to share PPIDs with programmatically". Ad Manager passes it to third-party buyers "exactly as it's received". PPID for non-Google demand isn't available in the EEA, Switzerland or the UK, or in US states with comprehensive privacy laws.

How to read your own bidstream data

You can read your own bidstream data in about five minutes with a browser. When we review a publisher's setup, this is one of the first things we open, because the defaults are rarely what people think.

1. Open a page on your site in Chrome with the developer tools on the Network tab.
2. Filter by "Fetch/XHR" and reload. Look for requests to your bidders' endpoints and to securepubads.g.doubleclick.net.
3. Click a Prebid bidder request and open its Payload. Most adapters send OpenRTB-shaped JSON.
4. Find user.eids, device.geo and regs. Note which IDs and segments are there.
5. Repeat for two or three bidders and compare. Then test again from a VPN in the EEA to confirm consent changes what's sent.

Adding pbjs_debug=true to the URL makes Prebid log more detail to the console. Our Prebid.js setup walkthrough shows the debug steps in full.

Here's what we look for. Does every bidder get every ID, even ones nobody asked for? Is precise location going out from a website that has no reason to send it? Are segments flowing to bidders who've never bid well? Each "yes" is a setting you can change today.

Bidstream data without third-party cookies

Bidstream data doesn't depend on third-party cookies. Pages, devices, contextual signals and consent strings all travel without them. What cookies add is the cross-site user ID in user.id and buyeruid.

Many guides still say Chrome is about to remove third-party cookies. Google dropped that plan and has retired most of its Privacy Sandbox APIs, as our Privacy Sandbox update for publishers explains. Safari and Firefox already block them, though. So on a big share of your traffic, the bidstream carries no cookie ID at all. Our step-by-step guide to selling cookieless traffic covers what to send instead.

That gap is filled by the eids array: shared IDs, hashed-email IDs and publisher IDs. It's a move from many cookie IDs to fewer, stronger ones. Our universal ID guide compares the options. Stronger IDs make the bidstream more valuable and more sensitive at the same time, which is exactly why the bidder limits above matter.

Frequently asked questions

What is the meaning of bidstream?

The bidstream is the flow of bid requests and bid responses between sellers and buyers in programmatic auctions. Bidstream data is the information those requests carry about the ad slot, the page, the device and the user.

Is bidstream data personal data?

Often, yes. IP addresses, advertising IDs, user IDs and precise location can identify a person or device. Treat bid requests as carrying personal data and set up consent and bidder limits on that basis.

Who can see my site's bid request data?

Every SSP, exchange and DSP the request reaches, whether it bids or not. You choose your direct partners in Prebid and Ad Manager, but you can't see every buyer further down the chain.

Can I stop bidders from storing bidstream data?

Not technically, once the request leaves your page. You can limit what's in it with Prebid activity controls and bidder lists, and set data terms in your SSP contracts. Dropping a bidder that adds no revenue is the simplest fix.

What is bidstream location data?

Bidstream location data is the device.geo block: country, region, city and postal code, and in apps sometimes GPS coordinates. It's the most sensitive part of the request, and the part the FTC's 2024 cases focused on.

Does sending less data lower my ad revenue?

It can, for some bidders. Buyers bid more when they recognise the user. That's why we'd restrict IDs and data per bidder rather than strip everything, then compare each bidder's win rate and CPM before and after.

Next step

Bidstream data is how your inventory gets priced, so send each bidder what it needs and nothing more. If you want a second pair of eyes on what your bid requests carry and which partners earn their access, our header bidding setup service starts with exactly that review.