Bidstream data: where it comes from, what a bid request really carries, and why the account it names can be wrong.

Definition

Bidstream data is the information carried inside the bid requests that an ad exchange broadcasts to bidders during a real time bidding auction: a description of the page or app, the device and the audience that an advertisement would be shown to.

It is a byproduct, not a designed product. The bid request exists so a buyer can decide whether to bid on one impression, and OpenRTB, the IAB Tech Lab standard that defines the message, says its intent is not to regulate exactly how each business operates. It aims to make integration easier.

When a company collects those requests and keeps them, it holds a running record of which pages were loaded from which networks. Sold into B2B, that record is converted into a claim about which companies are researching a topic, which in this page's view is a much bigger claim than the raw data supports.

Bidstream data vs a bid request

A bid request is one message about one impression opportunity. Bidstream data is the stream of those messages taken together, as a bidder, an exchange or a data company sees them over days and weeks. The difference is scale, and scale is what turns an auction message into a dataset.

One request tells a buyer enough to price a single ad. Millions of them, stored and joined by identifier, describe what a device read, where it was and when. That is why the same fields look harmless in a specification and sensitive in a regulator's report.

How real time bidding produces bidstream data

A page or an app loads and an ad slot has to be filled. The publisher's supply side platform builds a bid request, and an exchange broadcasts that request to bidders. Bidders answer inside a deadline the request itself sets, the exchange applies its auction rules, and one bidder wins the impression.

The OpenRTB specification describes it plainly: for each inbound ad request, bid requests are broadcast to bidders, the responses are evaluated under the prevailing auction rules, and a winner is selected. The request carries a maximum response time in milliseconds, and the specification defines RTB as bidding for individual impressions while a consumer is waiting.

After the auction, the specification provides a win notice for the winner, a billing notice for when spend should actually apply, and a loss notification that can tell a bidder why its bid did not win. None of those notices asks a losing bidder to discard the request it received.

Bidstream data is what those broadcast requests contain, gathered at volume. The point many buyers miss is in the word broadcast. Every bidder invited to the auction receives the full request, including every bidder that never bids and every bidder that loses.

Who is in the auction, in the specification's own terms

Vendor material about bidstream data assumes you know the cast. The OpenRTB terminology table defines four roles: exchange, bidder, seat and publisher. Its introduction names the rest, describing suppliers of inventory as exchanges, networks and sell-side platforms, and buyers as bidders, demand side platforms or networks working with advertisers.

Notice which role has the best seat. A bidder receives every request it is offered, whether or not it ever spends a cent. In this page's view, that is exactly the position a data collector needs, and the specification itself leaves the rules on who may connect to each exchange.

What a bid request actually contains

OpenRTB 2.6 defines the objects a bid request can carry. Only a few attributes are required, such as the request ID and at least one impression, and the specification warns that recommended attributes may not be available from all supply sources. The schema shows the ceiling: the most a recipient could be handed.

Two details stand out. The specification deprecated the year of birth and gender fields in version 2.6, which tells you they were once part of the schema. And the privacy section states that each implementer is responsible for making sure its implementation complies with applicable law, so the standard hands the obligation to the participants.

What one request looks like

The specification publishes its own worked examples rather than leaving readers to imagine them. Its simplest banner example carries an auction ID, a first price auction flag, a currency, one impression with a floor price and a three hundred by two hundred and fifty banner, a site block and a user ID.

The site block in that example holds a site ID, a content category, a domain, the full URL of the page and a publisher. The user block holds a single long hexadecimal string. Nothing in it says a name or an employer. Everything in it is the raw material from which both are later guessed.

That gap between what the message carries and what a vendor sells from it is the whole subject of this page. Understanding it is the difference between buying B2B intent data with clear eyes and buying a story about it.

Cookie syncing, and how identity gets into the request

A request only becomes useful across sites if the same user can be recognized twice. The specification devotes an appendix to how that is arranged. Because cookies are specific to one domain, two parties have to learn each other's user IDs first, a process it calls cookie syncing, user syncing or cookie matching.

In a cookie sync, a pixel loads, one party reads or sets its cookie, and a redirect passes that ID to the other party, which does the same. The pairing is stored in a match table. The specification says syncs are classically set up between DSPs and exchanges or SSPs, and between DSPs and DMPs.

The result shows up in the bid request itself. When the exchange holds the match table, it looks up its own cookie for the user, finds the buyer's ID, and writes that ID into the buyer user ID field. That is the identity layer, assembled from cookies before any auction starts.

The appendix notes that cookies are short-lived, so it is customary to limit match table retention to a period such as 14 to 60 days and refresh the match while a user is still active. Identity in the bidstream is perishable, which matters when a vendor claims a long history for a device.

It is worth understanding because it explains what a collector can join. Without a sync, a request is an isolated observation. With one, requests from different sites can be stitched into a history of users, which is what makes bidstream data commercially interesting and legally awkward at the same time.

How advertisers and publishers use bidstream data

Before bidstream data was resold as intent, it had a job inside programmatic advertising, and that job is still the main one. The fields exist so that each side of the auction can make a decision about one impression in real time.

For advertisers and DSPs

• Whether to bid. A DSP reads the site, the page categories, the device and the location to judge whether the impression fits a campaign, and how much it is worth.
• Audience targeting. The specification says a DSP acts on a synced user ID for audience targeting, frequency capping and measurement.
• Contextual targeting. Content categories, keywords and the page URL let a buyer target what is being read rather than who is reading, which does not depend on a user ID.
• Deals. A private marketplace object carries direct deals, which the specification defines as pre-arranged agreements between a publisher and a seat on agreed terms.

For publishers and SSPs

• Floor prices. Each impression can carry a minimum bid, expressed in CPM, set by the seller.
• Block lists. A request can block advertiser categories, advertiser domains, apps and buyer seats, which is how a publisher keeps unwanted ads off its pages.
• Supply chain transparency. The Source object can carry the chain of intermediaries, so buyers can see who handled the impression and who is paid.
• Revenue. The more a request describes the page and audience, the more a buyer can value it. In this page's view, that is the commercial pull toward sending more data, not less.

The ICO's own foreword accepts that a system allowing revenue for publishers and audiences for advertisers is needed. Its objection is to how personal data moves through that system, not to advertising itself. Keep that distinction when a vendor answers a privacy question with a description of ad targeting.

Who receives bidstream data, and who keeps it

In its 2019 update report on adtech and real time bidding, the UK Information Commissioner's Office found that a single request can result in personal data being processed by hundreds of organizations, and that one visit to a website, prompting one auction, can put a person's data in front of that many parties.

The report names the structural problem directly. Many parties receive information about a user, but only one wins the auction, and there are no guarantees or technical controls covering what the others do about retention or security. Once data leaves one party, that party cannot guarantee it stays protected.

The ICO called the creation and sharing of these profiles disproportionate, intrusive and unfair, particularly because in many cases people are unaware the processing is happening at all. That is a regulator's characterization of the mechanism, not of any one vendor.

How bidstream data becomes bidstream intent data

Bidstream intent data is what you get when a collector takes those requests and rewrites them as account level research signals. As this page describes the pipeline, it has four steps, and every one of them adds an assumption.

• Resolve. The IP address in the Device object is matched to an organization, so a device becomes a company.
• Classify. The page URL, the site categories and the keywords are mapped to a topic in the provider's taxonomy.
• Count. Requests for that topic from that organization are tallied over a window the provider chooses.
• Compare. The count is set against some baseline, and an account above the baseline is reported as surging.

Each step is defensible on its own. Stacked, they turn a request that said only "this IP loaded this URL" into a sentence a sales rep will read as "this company is in market." The provider knows the difference. A rep working a queue may not.

It matters that bidstream data records an ad impression opportunity, not a deliberate act. Nobody chose to generate a bid request. They loaded a page that happened to carry advertising, which in this page's view is a weaker signal than filling in a form on your own site.

Where bidstream intent data fits in B2B go-to-market

Third-party intent data is sold to B2B teams as an answer to one question: which accounts should we work this week. Bidstream is attractive to sellers of that answer because ad auctions run across the ad-supported web, and a product label does not always say where its signals come from.

Sales teams

Sales teams use intent signals to order a queue. An account that surged on a topic moves above an account that did not, and reps work down the list. That is a reasonable use, as long as the list was already filtered for fit and nobody treats a topic score as a buying decision.

Marketing teams

Marketing teams use the same intent signals to decide where content and budget go: which topics to write about, which segments to retarget, and which accounts to put into a nurture track. Here the cost of a false positive is lower, so broad third-party intent data does less damage than it does in sales.

ABM programs

In ABM strategy, intent is one input into account selection and timing, alongside firmographics, technographics and relationship data. In this page's view, fit comes first and intent second, because an in-market account that cannot buy your product is not a target.

Across all three, bidstream intent data narrows attention. It does not tell you a buying committee has formed, it does not name the people in it, and it cannot see research that happens in private channels or on gated content. That is why prospect targeting still starts with fit.

It also pays to know which kind of intent signals you are buying. Search behavior, content consumption, review site activity, product usage and advertising auctions are all sold under the same words, and only the last of them is bidstream.

IP to company resolution, and where it breaks

The resolution step is the load-bearing wall. As this page understands it, a provider can draw on registry records, reverse DNS, commercial IP databases and its own observed history to name an organization. It works best when an office holds a stable block of addresses and everyone inside uses it.

Several ordinary facts about modern networks break that link. In this page's view they are everyday conditions, not edge cases.

The specification itself concedes the softness. The Geo object includes a field naming which service was used to derive location from an IP address, which exists because that derivation is an estimate with a provenance, not a measurement.

No error rate is given on this page. Anyone quoting a single accuracy figure for IP to company resolution is quoting a number measured on their own sample, with their own definition of correct, and it will not transfer to your account list.

Accuracy problems beyond resolution

• Topic mapping is shallow. A page is classified from its URL and category, so a news article that mentions your category can count the same as a buying guide.
• Volume is not intensity. A count of impressions cannot tell a five second bounce from a thirty minute read, because the bid request is sent before either happens.
• Coverage is uneven. Only pages with programmatic advertising generate requests, so specialist trade sites and gated research can be missing entirely.
• Bots and fraud. Invalid traffic can generate bid requests too, and that traffic is designed to look like a real reader.
• No role. The request says nothing about who the person is, so an intern and a chief information officer produce the same row.
• Baselines are private. Surge is a comparison against a baseline you cannot inspect, so you cannot tell whether a spike is real or a quiet week elsewhere.

The privacy objections, stated fairly

The common defense is that bidstream data holds no personally identifiable information. That defense uses an American term to answer a European rule, and the European rule is written differently.

Article 4 of the GDPR defines personal data as information relating to an identified or identifiable person, including identification indirectly through location data or an online identifier. Recital 30 names internet protocol addresses and cookie identifiers as such identifiers, and says the traces they leave can be used to create profiles and identify people.

The ICO report went further. It found that the schemas used in OpenRTB, in the Transparency and Consent Framework and in Google's Authorized Buyers include fields relating to politics, religion, ethnic groups, mental health and physical health.

Article 9 of the GDPR prohibits processing that kind of data unless an exception applies. The ICO said the only exception available in RTB is explicit consent, and that the consent requests under the TCF and Authorized Buyers frameworks were non-compliant.

The US regulator reached a similar point by another route. An FTC technology post on its Avast, X-Mode and InMarket cases said browsing and location data are sensitive even though none of the datasets were alleged to contain names or other traditional standalone identifiers.

A further objection has nothing to do with sensitivity. The data was collected so that someone could bid on an advertisement. Article 5 requires that personal data be collected for specified purposes, and not further processed in a way incompatible with them. Reselling a losing bidder's copy as a research signal is a different purpose.

What regulators and courts have actually said

None of that makes every bidstream product unlawful, and none of it is legal advice. It does mean the burden of explaining the consent chain sits with the supplier, and a buyer who never asks is choosing not to know.

The European rulings in more detail

The Belgian authority explained that a consent management platform asks users for consent, stores their choices in a TC String and places a cookie, and that when combined these can be linked to the user's IP address. That is why the consent record is treated as personal data.

The Court of Justice drew a limit too. It held that the joint controllership of a standard-setting body does not extend automatically to later processing by third parties, such as website owners, for targeted advertising. Each downstream user of the data still answers for its own processing.

The FTC on location data and data brokers

The FTC's January 2025 release said the Mobilewalla order was the first time the agency alleged that collecting consumer data from advertising auctions for other purposes was an unfair act or practice. The order also restricts the use of location data from sensitive places such as health clinics and religious organizations.

Not every location case is a bidstream case. In its X-Mode and InMarket matters, the FTC said the companies collected precise location data through software development kits inside their own and third-party apps. The Avast matter concerned browsing data collected through antivirus software and browser extensions.

The lesson the FTC drew across those cases transfers anyway. Its technology post said contract clauses restricting use may not deter misuse by downstream buyers, and that data handling must align with the purposes for which the data was collected.

The obligations that land on you

If you buy a feed built this way and act on it, you are likely to be a controller of the personal data you use for your own marketing. Several duties follow, and in this page's reading no supplier contract removes them. This is not legal advice.

• Lawful basis. You need one for your own processing, and you need to be able to say what it is before the first email goes out.
• Source disclosure. Article 14 requires you to tell people, when data did not come from them, which source it originated from.
• Purpose limitation. Your use has to be compatible with the purpose the data was collected for, not merely convenient.
• Accuracy. Inaccurate personal data must be erased or rectified without delay, and an account wrongly named by IP resolution is inaccurate data.
• Objections. Under Article 21 a person can object at any time to direct marketing, including related profiling. You need a working route for that and evidence you acted on it.

California's data broker rules

In the United States, California regulates data brokers, which state law defines as businesses that knowingly collect and sell the personal information of consumers they have no direct relationship with. The California Privacy Protection Agency says brokers must register every year under the Delete Act.

From August 1, 2026, the agency says data brokers must access a central deletion mechanism at least once every 45 days and process consumer deletion requests, with limited exceptions. If your supplier is a registered broker, ask how those deletions reach the data it sold you.

These are the same duties that apply to any bought B2B data. Bidstream sourcing simply makes them harder to satisfy, because the chain back to the point of collection is longer and less documented.

Alternatives to bidstream sourcing

Bidstream is one way to get research signals, not the only way. The others trade reach for traceability, and in this page's view that is the right trade for many B2B teams.

Mixing them beats picking one. A first party signal tells you someone is close, a co-op topic tells you a category is warming, and an observable fact tells you why now, which is the raw material for trigger marketing.

Bidstream against the other sources

Rank them by how short the chain is between the person's action and your record of it. That single question sorts much of this market without any vendor comparison.

Questions to ask a provider

• Is any part of this feed derived from bid requests? Ask for a yes or no in writing, not a description of methodology.
• What consent was collected at the point of capture, and by whom? Then ask who holds the record of it.
• Do your contracts with sources permit using a bid request for anything other than bidding? The FTC's Mobilewalla order turned on exactly this.
• How do you resolve IP addresses to companies, and how do you handle shared and residential addresses? A good answer names the failure modes unprompted.
• What is the baseline behind a surge score? If the answer is proprietary, the score cannot be audited.
• Which publishers or feeds cover my topics? In this page's view, vagueness here suggests open web collection.
• What happens when someone objects or asks for deletion? Ask how a suppression flows back upstream, and whether the provider is a registered data broker.

Put the answers in the contract, not the deck. Ask the same set of questions when you buy lead enrichment, wire up a data enrichment API or add any other sales intelligence feed, because the sourcing question is identical.

How bidstream intent data is packaged

You rarely buy raw requests. You buy something derived from them, and in this page's view the packaging decides how much of the underlying weakness you ever see.

• Topic subscriptions. You pick topics from the provider's taxonomy and receive scored accounts against them on a schedule.
• Account list monitoring. You supply a named list and get alerts when an account on it crosses a threshold.
• Audience segments for advertising. The same data sold as targeting segments to run campaigns against, rather than as a list for sales.
• Contact-level add-ons. Intent joined to contact data, which is where sourcing questions get sharpest, because a person is now named.
• Platform bundles. Intent included inside a sales intelligence or ABM platform, where the source is hardest to see.

This page quotes no prices. What matters more than price is whether the contract lets you leave with your own records, and whether it names the data sources you are paying for.

How to test a feed before you trust it

Run the test on ground you can check. Take accounts where you already know what happened, then see whether the feed knew it too. The checks below were written for this page.

Two of those checks cost nothing and, in this page's view, catch the worst problems: look up your own offices, and replay last year's closed deals. If the feed cannot name your own building, do not ask it to name your buyer's.

Using it without overreaching

Treat a bidstream signal as a tiebreaker, not a trigger. It can decide the order of a list that was already filtered by fit, and that is a real contribution. It cannot justify contacting a company that does not match your ideal customer profile.

Never write the signal into the message. Telling a stranger that their company was seen reading about a category sounds like surveillance and, given the resolution problems above, can be wrong. Use it to choose who to write to, then write about the problem.

Keep it inside a system your team already reads. In this page's view, a feed that lands in a separate dashboard gets checked for two weeks and then ignored, which is one way a target account list project quietly stalls.

What changes as identifiers disappear

The specification already assumes identifiers can be withheld: it carries a do not track flag and a limit ad tracking signal it describes as commercially endorsed, for example on iOS and Android, and version 2.6 deprecated the hashed device ID and MAC address fields. Requests can still carry the page, domain, categories and IP address.

For B2B that cuts both ways. Account level resolution leans harder on the IP address, the weakest link, while person level linking gets worse. In this page's view, claims about individuals will become less credible, and claims about accounts will stay roughly as shaky as they are.

Contextual signals survive best, because they describe the page rather than the person. That helps advertisers who target content, and it does little for a B2B buyer who wants to know which company was reading.

The durable answer is unglamorous: build first party collection you control, and treat bought signals as supplementary. Your own customer data does not depend on anyone else's consent chain.

Common mistakes with bidstream data

• Accepting "no personally identifiable information" as an answer about GDPR, when the regulation counts online identifiers as personal data.
• Believing an account is in market because a surge score said so, without checking fit or a single human signal.
• Buying a feed without asking whether it comes from bid requests, then discovering the answer during a security review.
• Referencing the signal in outreach, which tells the recipient you are watching and may be wrong anyway.
• Comparing vendor accuracy claims as if they were measured the same way. They are not.
• Assuming all location data is bidstream data. Some of it comes from SDKs inside apps, and the questions to ask differ.
• Skipping the test on your own offices and your own closed deals, which is the cheapest evidence available.
• Assuming the contract transfers your obligations to the supplier. In this page's reading, it does not.

In a sequence

If a signal moved an account up your queue, the first email should not mention the signal. It should name a problem that a company of that shape may have, and ask one question. The template below was written for this page.

Subject: {{problem}} at {{companyName}}

Hi {{firstName}},

Many {{companyType}} teams your size run into {{problem}} once {{context}} is in place. It can show up as {{symptom}} before anyone names it.

If that is on your list this quarter, I can send how {{similarCustomer}} handled it. If it is not, tell me and I will stop.

{{senderName}}

Frequently asked questions