The Five Parties in a Programmatic Auction
Every programmatic impression passes through the same five parties, and each has a different job. The advertiser and the publisher never deal with each other directly.
| Party |
Side |
What it wants |
What it controls |
| Advertiser |
Demand |
Reach an audience at an acceptable cost |
Budget, targeting, creatives |
| Demand-side platform |
Demand |
Win the right impressions at the lowest winning price |
Bid price, filters, pacing |
| Ad exchange |
Middle |
Run a fast auction and take a fee |
Auction rules, timeout, its own fee |
| Supply-side platform |
Supply |
Sell each impression as high as possible |
Floor prices set for the publisher, buyer allow lists |
| Publisher |
Supply |
Fill inventory without hurting the page |
Formats shown, advertisers blocked |
How One Impression Goes From Request to Render
One impression goes from request to render in the time a page takes to load. The publisher offers the slot through an SSP, the exchange describes it as a bid request to the demand-side platforms it expects to bid, those platforms reply with prices, and the winning creative renders in the slot.
- A visitor opens a page or an app screen with an ad slot on it.
- The publisher's server offers the slot through a supply-side platform (SSP), or through header bidding, which asks several supply-side platforms at once.
- The SSP packs the details into a bid request and sends it to the exchange.
- The exchange passes the request to the DSPs it expects to bid on it.
- Each DSP that wants the impression returns a price and a creative.
- The exchange runs the auction and tells the winner.
- The winning creative loads in the slot.
Steps 4 to 6 are real-time bidding. Steps 1 to 3 happen on the publisher's side, and the DSP never sees them: it knows only what the seller chooses to disclose. That gap causes most of the problems described later on this page.
A worked example. A publisher sets a minimum price of $2.00 CPM, the cost of a thousand impressions. Three DSPs submit bids of $2.40, $3.10 and $4.00. This is a first-price auction, the standard in real-time bidding, so the highest bidder wins and pays exactly what it bid: $4.00 CPM.
A DSP that judges $3.30 to be enough can bid that instead of the full $4.00 it is willing to pay. It still wins the impression and saves $0.70 CPM. The exchange and the SSP take their fees out of that $3.30 before the publisher is paid.
What the DSP reads in a bid request
A demand-side platform reads structured fields, not the page: where the impression is, what the slot looks like, who the user is, and what the seller will accept for it. Those fields are the only information the platform has when it prices the impression, and the list below is what a bidder works from.
| What arrives |
What it decides |
| Site domain or app bundle ID |
Whether the placement passes your allow list |
| Slot size, format, position |
Which creative can be served there |
| Country, region, city |
Geotargeting, as precise as the seller passes |
| Device, OS, browser, connection |
Device targeting and creative weight |
| User identifier, or its absence |
Whether audience data can be matched at all |
| Floor price |
Whether a bid can clear |
| Blocked categories and domains |
Whether your creative is eligible before the auction |
| Consent signals (TCF string, GPP) |
Whether personal data can be processed at all in that market |
| Supply chain object (schain) |
How many intermediaries sit between you and the publisher |
| Auction timeout (tmax) |
How long your bidder has to answer before the response is discarded |
Missing fields matter as much as present ones. An impression with no usable identifier cannot be matched to a retargeting list, so the demand-side platform prices it as cold traffic or skips it.
Two fields go missing more often than any others when a new supply partner connects. Without the referrer, contextual targeting collapses to domain level and every page on a site gets priced the same.
In push traffic the gap is the subscription date. A user who subscribed last week and one who subscribed two years ago behave nothing alike, and without that date they reach you at the same CPM. Those are the first two fields we ask about when ADMY onboards a new supply partner.
Why a DSP does not bid on most requests
A DSP does not bid on most requests because several gates sit in front of the bidding logic, and a request only has to fail one of them. Getting no answer is normal operation rather than a fault.
Pacing comes first: if the campaign has spent its share for the hour, the DSP stops bidding until the next window. Frequency rules cut the next slice, because a user who has hit the daily cap gets no bid. Then come allow lists, block lists, category filters and fraud checks.
Capacity is the gate nobody mentions in a demo. Exchanges limit how many requests per second they send each buyer, and the DSP sets its own ceiling to stay inside the timeout. Past that, requests are dropped unread.

The filtering runs both ways. Exchanges score which buyers actually bid on which supply and stop sending the rest, so a DSP answering a tiny fraction of what it receives gets sent less over time, and narrow targeting shrinks the pool it draws from.
When a partner's campaign cannot spend, the bid price is the last thing we check. Usually a pacing window or a request cap keeps the impressions from being evaluated, so a higher bid changes nothing. The hourly report shows which: a campaign that stops at the same hour every day is pacing, and one that never starts is a filter.

Why a bid loses even when it is the highest
The highest bid does not always win, because price is one condition among several. The floor is the simplest: a bid below the publisher's minimum is dropped before ranking. Deal priority is the common one, and it depends on how the impression was sold.
| Deal type |
Price |
Inventory guaranteed |
Auction |
| Programmatic guaranteed |
Fixed, agreed in advance |
Yes |
No auction |
| Preferred deal |
Fixed, agreed in advance |
No, first refusal |
No auction |
| Private marketplace |
Auction, with a floor |
No |
Invited buyers only |
| Open exchange |
Auction |
No |
Any connected buyer |
Guaranteed and preferred inventory is claimed before the open auction, so an open-market bid competes for the remainder. According to the ANA's Programmatic Transparency Benchmark, private marketplace deals took 85 percent of programmatic spend in Q1 2026, up from 79.2 percent a quarter earlier.
Creative rejection accounts for another share: the publisher may exclude your domain or category, or a creative may not pass moderation. In our experience a blocked creative stops volume more often than a low bid, so we check creative status first and recommend three variants per size. The last case is the timeout, where a late response counts as no bid.

What Changes When You Buy Through a DSP Instead of Direct
Buying through a demand-side platform changes the levers you hold, and price is only one of them. The three routes to the same inventory hand you different ones.
|
Direct insertion order |
Ad network |
Demand-side platform |
| Unit of purchase |
Placement for a period |
Package of traffic |
Single impression |
| Price set by |
Negotiation |
The network |
Your bid, per impression |
| Audience control |
Publisher's audience |
Network segments |
Your own and bought data |
| Placement visibility |
Full, agreed in advance |
Often partial |
Full, in reporting |
| Speed of change |
Days |
Hours |
Minutes |
| Entry threshold |
High, per publisher |
Low |
Medium, seat plus minimums |
What a DSP replaces is manual buying: insertion orders, negotiated CPMs, fixed placements for a fixed month. DSP advertising lets you pay for one specific person on any page, and leaves you to decide what that person is worth.
What Types of DSP Exist
Demand-side platforms come in five groups, and they differ on three things: how many channels they buy, whose data they run on, and whether you rent a seat or own the brand. Those three questions settle more than any feature list does.
| Type |
What it is |
Who it fits |
| Omnichannel independent |
Buys display, native, video and more across open supply, owning none of it |
Advertisers who need one buying point across channels |
| Channel specialist |
Built around one environment, such as mobile in-app or connected TV |
Buyers whose budget sits in that single channel |
| Platform-owned |
Tied to the commerce or app data of the company that owns it |
Advertisers whose audience lives inside that ecosystem |
| White-label |
A licensed bidder run under the licensee's own brand and domain |
Networks and agencies reselling media as their own product |
| Managed-service reseller |
Sells outcomes on top of a bidder belonging to someone else |
Teams with nobody to run trading in-house |
A seat is your account inside the platform: the login, the contract and the exchange access that come with it. Self-serve means your team logs into the DSP platform and carries the result, while managed means the vendor's traders run it on the same bidder.
A programmatic DSP can belong to any of these five groups and still work the same way underneath. The choice follows from what you sell: if you resell media under your own brand, only white-label answers, and if your budget sits in one channel, a specialist beats an omnichannel seat.
A platform is a DSP if it bids on impressions itself, and a reseller if it passes your budget to someone else's bidder. The term demand side platform gets applied loosely, so I run the same five questions before any integration call goes further:
- Does it hold its own seats at ad exchanges, or buy through another platform's seats?
- Can you see and change bid prices, or only a budget and a goal?
- Does it give impression-level data, or summary reports only?
- Can you upload your own audiences and use your own measurement vendor?
- Who is named in the contract as the buyer of the media?
The first and the last questions are disqualifying: a platform with no exchange seats that is not named as the media buyer is reselling access. A "no" on the middle three leaves you unable to verify the rest, and managed service on someone else's bidder is fine as long as the fee matches it.
What Data Does a DSP Use for Targeting
Targeting in a demand-side platform runs on three kinds of signal: data you collected, data you bought, and the data inside the bid request. Only the last one is present on every impression.
Request-level signals cost a DSP nothing extra and need no identifier: country, device, operating system, connection, time of day, page content. Your own data is the strongest layer, and it exists only where you collected it.
Segments bought from a data provider sit in between, priced as an extra CPM on top of the media. The comparable number is the data CPM plus the media CPM, since a segment can cost more than the impression it rides on.
First-party audiences, the pixel and what a DMP adds
First-party audiences start with a retargeting pixel on your site, and a data management platform (DMP) organizes them once more than one source feeds in. The pixel turns visited pages and fired events into a list the DSP can bid against, for retargeting or remarketing alike. CRM uploads work the same way, and a lookalike audience is only as good as its seed list.
The split between the two is simple: the data management platform stores, deduplicates and models the data, and the DSP decides what an impression showing that audience is worth. Segments built on third-party data have thinned, so how much data you own now decides how precisely a DSP can target.
The identifier picture in 2026 is the reverse of what the industry planned for. Google dropped the cookie deprecation timeline in July 2024 and retired most of the Privacy Sandbox on October 17, 2025, including Topics, Protected Audience and Attribution Reporting.
Chrome is removing those APIs by version 150 in July 2026 while keeping third-party cookies. Safari, Firefox and Brave still block cookies by default, so a large share of open-web traffic stays cookieless.
Where cross-exchange frequency capping breaks
Frequency caps are reliable inside one identity graph and unreliable across the open web. A DSP counts impressions per identifier, so when the same person appears as one ID on one exchange, another in an app and none in a privacy-restricted browser, the platform sees three strangers and caps each separately.
A cap of three per day can therefore deliver well over three to one person, while the report still shows the cap respected. Consolidating spend into fewer exchanges where your match rate is high narrows the gap without closing it. The cap stays a cost control: it describes what you paid for, never what the person saw.
A demand-side platform buys banner, native, video, in-page, push and pop, which covers most of the open web and apps. DSP ads have one hard limit: a format exists for you only if your connected exchanges carry it, and connected TV, digital audio and digital out-of-home each need their own integration.
| Format |
Where it runs |
What it suits |
| Banner |
Web and in-app slots |
Reach and retargeting at low CPM |
| Native |
In-feed and content blocks |
Traffic from content audiences |
| Video |
In-stream and out-stream |
Upper-funnel reach |
| In-page |
Fixed or sticky page elements |
Visibility without interrupting the page |
| Push |
Subscribed device and browser notifications |
Return visits from an opted-in base |
| Pop |
Separate window or tab on click |
Volume where CPM beats context |
In-app requests carry a bundle ID and a device advertising ID instead of a URL and a cookie, and the conversion after an in-app impression is counted by a mobile measurement partner (MMP) on the device. An MMP added mid-flight means the tracking gets rebuilt, and the first weeks of data stop being comparable with everything after.
How a DSP Optimizes Bids and Pacing
A demand-side platform optimizes by changing two numbers: how much to bid, and how fast to spend. What vendors describe as AI optimization runs on those two decisions plus the choice of creative. Bid shading handles the first: instead of bidding its full valuation, as in the example above, the platform estimates the lowest price that still clears.
The saving tracks bid density, and it runs opposite to intuition. With five or six bidders the top competing bid sits close to your valuation and little is left to shade, while with two the gap is wide, so thin competition is where shading saves most.
Pacing handles the second. A campaign left to itself would spend its budget in the cheapest hours, so the demand-side platform spreads delivery and shifts weight toward what performs. Both mechanisms learn from conversions, so below a few dozen conversions a week manual rules on placement and segment work better.
What a DSP Reports and Why the Numbers Disagree
Impressions won and rendered, clicks, spend, attributed conversions: that is the reporting set a demand-side platform gives you, and none of it will match your analytics or your MMP exactly. Three systems count three different events.
The DSP counts an impression when the creative renders, analytics counts a session when the landing page loads, and the MMP counts an event on the device, each with its own time zone and attribution window. In three years of wiring postbacks for partner launches I have yet to see three systems return the same number, and a steady gap is something you can plan around.
A gap that moves week to week usually comes down to the click id. Either the partner does not return the one passed on the redirect, or returns it under a different name: the platform expects clickid, and the postback arrives with click_id. Either way conversions arrive without attribution, and the campaign looks as if it is not converting.
One test conversion fired through the full redirect before launch catches both cases, long before anyone raises a bid. Read the parameter name off the postback itself, since both sides can be configured correctly and still name the field differently.
One question settles most of the rest: what lookback window applies to view-through and to click-through conversions. Two platforms counting the same campaign over different windows will not reconcile however clean the tracking is, so agreeing the window in advance removes the argument before it starts.
Do you still need an ad server with a DSP
You need one when you want a count that sits outside the buying platform. The DSP decides which impression to buy; a third-party ad server decides which creative goes into it and keeps that separate count. Both serve ads, which is why vendors describe the ad server as a component of the DSP.
In a DSP ad server setup the DSP wins the impression and calls a third-party tag, and the ad server delivers the creative and logs the event. The two totals differ because one records the win and the other the delivery, and agencies keep a separate ad server so one creative can run across several buying platforms under one set of numbers.
What Buying Through a DSP Costs
Buying through a DSP costs the media price plus several layers on top, and only the media price is visible by default. The rest is disclosed unevenly from vendor to vendor, so the stack is worth naming in full:
- Media cost. What the winning bid pays for the impression.
- Platform fee. The DSP's share, usually a percentage of media spend.
- Exchange and SSP fees. Taken on the sell side, before the publisher is paid.
- Data fees. An extra CPM for every bought segment applied.
- Ad serving, verification, measurement. Small per-impression fees that add up.
What sets your real CPM is how much of the budget reaches the publisher. Before signing, ask what percentage the platform takes and on what base, whether data and ad serving are included, and whether a minimum commitment applies, and ask for the answers as a worked example on a round budget, since percentages on different bases do not compare.