What is a DSP, and what does it decide for a buyer?
Part of Programmatic media planning
The short answer
A demand side platform (DSP) is buying software that receives bid requests from exchanges and bids on single impressions for advertisers. The buyer sets up a seat, line items, targeting, budgets and bids, and the DSP applies them to every request. It chooses impressions inside those rules; it does not choose the publishers or the brief.
Key takeaways
- A DSP is the bidder in an auction, acting for a seat, which OpenRTB describes as usually the owner of the advertising budget.
- For every bid request, the DSP checks which line items are eligible, whether budget and pacing allow a bid, and what price clears the seller's floor.
- Site lists, app lists and deal IDs reach a DSP as targeting attached to line items, so a wrong list is applied faithfully at full speed.
- Who holds the seat contract decides who keeps the logs, lists and deal relationships when an agency and a brand part ways.
- The brief, the publisher choices, the suitability tolerance and the approval of the list are planning decisions that happen before the DSP sees anything.
What does a demand side platform do?
Definition
- Demand side platform (DSP)
- Software that buys digital ad impressions for advertisers. It listens to bid requests from many exchanges, decides for each one whether any of its campaigns should bid, and submits a price and an ad when one should.
The OpenRTB 2.6 specification (opens in a new tab) never uses the brand term DSP in its terminology table. It uses two roles instead. A bidder is "an entity that competes in real-time auctions to acquire impressions." A seat is "an advertising entity (e.g., advertiser, agency) that wishes to obtain impressions and uses bidders to act on their behalf; a customer of a bidder and usually the owner of the advertising budget." A DSP is the bidder, and the agency or brand account inside it is the seat.
That split explains what a buyer does in the software. The seat owns the money and the rules. The bidder applies those rules to a stream of requests far faster than any person could read them. Names for the levels differ from one platform to the next, but the jobs below follow from the bidder and seat roles that OpenRTB defines.
| Job | What the DSP does | What the buyer supplies |
|---|---|---|
| Seat | Holds the account that bids, pays and appears in the auction as the buying entity | A contract, a billing owner and the users allowed to change settings |
| Line items | Groups budget, flight dates, creatives and targeting into units that bid independently | One line item per tactic, route or list, so results can be read apart |
| Targeting | Filters each request by site or app, deal, geography, device, format and audience rules | The approved site list, the deal IDs and the market settings from the brief |
| Bidding | Prices each eligible impression against the floor and the line item's goal | A bid strategy, a maximum price and pacing and frequency limits |
| Reporting | Logs bids, wins and spend by domain, deal and line item | A plan for reading the logs against the approved list after launch |
How does a DSP decide whether to bid on an impression?
Each bid request arrives with a deadline. OpenRTB's tmax is the "maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout," so the DSP's decision happens in a small part of that window. Inside it, the software runs roughly the same sequence for every request, and the order shows where a planner's settings bite.
The DSP's decision for one bid request
- Find the line items that could apply. The DSP compares the request's site domain or app bundle, deal objects, format, size and country with every active line item, and drops any line item whose list or targeting does not match.
- Check the seller is authorized. The ads.txt specification tells DSPs to consult each exchange's documentation for its canonical domain and "the appropriate field in bid requests to be checked against ads.txt." A request from an account the site never listed can be refused here.
- Check the seat is allowed. A deal can carry a wseat array, the "allowed list of buyer seats (e.g., advertisers, agencies) allowed to bid on this deal." A seat outside that list cannot use the deal.
- Check budget, pacing and frequency. A line item that has spent its daily share, or has already shown this ad often enough, sits out.
- Price the impression. The bid must meet the floor, which OpenRTB defines as the "minimum bid for this impression expressed in CPM." Under a fixed price deal, the deal's auction type 3 means the floor value "is the agreed upon deal price."
- Answer or stay silent. The DSP returns a bid with the seat ID, advertiser domain, creative ID and deal ID, or no bid at all. OpenRTB allows an empty HTTP 204 response as the no-bid signal.
What is a DSP seat and who owns it?
A seat is the buying identity an exchange sees. OpenRTB's bid response carries it in the seat field, the "ID of the buyer seat (e.g., advertiser, agency) on whose behalf this bid is made," and exchanges can allow or block seats per impression with the wseat and bseat fields. The specification adds that seat IDs and the customers they refer to "must be coordinated between bidders and the exchange a priori," which is why a publisher building a deal asks the buyer for its seat ID before anything else.
Ownership is a contract question, not a technical one. A seat can sit in an agency's master agreement with the DSP, with each brand as an advertiser inside it, or in the brand's own agreement with the agency granted access. The structure decides who can export the logs, who keeps the site lists and deal IDs, and whose name the publisher sees on a deal. Settle it in writing before the first campaign, not when an account moves.
Seat questions to answer before a campaign launches
- The seat ID that sellers must allow on a deal is written on the deal sheet.
- The party that signed the DSP contract, and therefore holds the seat, is named.
- Whoever owns the logs can export domain level delivery and bid data, and the contract says for how long.
- Site lists, exclusion lists and deal IDs can be moved to another seat if the agency relationship ends.
- Users who can edit line items are listed, and changes to targeting are recorded with a name and date.
How do site lists and deals get into a DSP?
Nothing in a media plan reaches a DSP as a plan. It arrives as targeting attached to line items: a domain list, an app list, a deal ID or an exclusion list. The DSP then applies each one literally to the values the seller puts in the bid request, which is why the format of a list matters as much as its contents.
| Planning output | How it enters the DSP | What it is matched against |
|---|---|---|
| Approved website list | Uploaded as an inclusion list on the line item, one domain per line | The site domain the seller declares in each request |
| App list | Uploaded as app store IDs or bundle names | The app bundle in the request |
| Exclusion list | Attached at advertiser or line item level, depending on the platform | The same domain and bundle values, as a block |
| Deal ID | Created by the seller, then entered or accepted on the buyer side | The deal objects inside the request's private marketplace field |
| Deal terms | Typed in by hand, or sent between systems where both support a standard feed | Floor, auction type and allowed seats on the deal |
Deal setup has long depended on email and retyping. IAB Tech Lab's Deals API (opens in a new tab) version 1.0 was in public comment until January 31, 2026 and was finalized on February 6, 2026. It standardizes how deal terms move from the system that created the deal, such as an SSP, to the receiving system, such as a DSP. Whether a given pair of platforms uses it is a question for both of them. For the deal side in depth, see what a deal ID is.
Which planning decisions stay outside the DSP?
A DSP optimizes inside the box the buyer draws. It can learn which listed sites deliver an impression at a lower price, but it cannot tell whether a site should have been listed. Each decision below has to be made, written down and approved before the line item exists.
| Decision | Why the DSP cannot make it | Where it is made |
|---|---|---|
| What the client sells and to whom | The software sees requests, not the brief | A written brief the client confirms |
| Which publishers fit | A domain in a request says nothing about the articles behind it | Site review of sampled articles, recorded per site |
| Suitability tolerance | The brand's tolerance is a business choice per category | The brand suitability policy |
| Acceptable selling paths | The DSP can enforce a rule but not set the policy | A seller policy based on sellers.json and ads.txt |
| Approval of the list | No platform signs off for the client | A named approver on a numbered inclusion list version |
How does PlacementGraph prepare site lists for a DSP?
What does a DSP setup look like for one campaign?
Fictional example
A truck accessories retailer in Iowa and Nebraska
A fictional Des Moines retailer of truck bed covers, towing hitches and cargo racks wants display ads in Iowa and Nebraska, in English, beside towing guides, pickup reviews and farm and ranch news. Its agency's trading desk will buy through the agency's DSP seat, with the retailer as an advertiser inside it.
The planner hands the desk an approved list of 60 sites, version 2, and a deal ID from a regional farm and ranch publisher. The desk builds two line items so each can be read apart: one carries the deal ID and the seat ID the publisher allowed, the other carries the site list on open auction. Both use the same geography, Iowa and Nebraska, and the same frequency limit.
In the first week the open auction line item bids on only part of the listed sites. The desk checks the logs and finds that several small blogs send no requests through the exchanges the seat buys on. The planner records this beside version 2 instead of padding the list, and asks the publisher whether a second deal could cover two of its sister sites.
Frequently asked questions
Can one advertiser buy through two DSPs at once?
Yes. An exchange broadcasts each bid request to its connected bidders, so two DSPs acting for the same brand can both receive it and both bid. The exchange treats them as separate bidders. Running two seats means two sets of lists, frequency limits and logs, so the plan should say which campaigns run where.
What is the difference between a self serve and a managed DSP account?
In a self serve account, the agency or brand's own traders build line items, upload lists and set bids. In a managed account, the DSP's staff operate the seat on the buyer's behalf. The planning work is the same either way: someone must supply the approved list, the deal IDs and the rules, and someone must check the logs.
Why does a listed site get no impressions from the DSP?
A site list grants permission, not delivery. The site may not send requests through any exchange the seat buys on, its floor may be above the line item's maximum bid, the account in the request may not match its ads.txt file, or another line item may be winning first. The domain level bid logs show which.
Does a DSP read the page before it bids?
Not in the bidding window itself. The DSP decides from the values in the bid request and from data it or its partners prepared earlier, such as page classifications or lists. That is why page level judgments about context and suitability are made in planning, where a person can read the articles.
Sources
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab
- ads.txt specification version 1.1 (opens in a new tab)IAB Tech Lab
- sellers.json specification (opens in a new tab)IAB Tech Lab
- Deals API (opens in a new tab)IAB Tech Lab
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.