What is an SSP, and what does a buyer see of it?
Part of Supply path transparency
The short answer
A supply side platform (SSP) is the software a publisher uses to sell its ad space programmatically. It turns each ad opportunity into a bid request, applies the publisher's price floors, blocks and deals, and collects bids from buying platforms. A buyer meets the SSP as a domain in ads.txt, a sellers.json file and a node in the bid request.
Key takeaways
- An SSP works for the publisher: it sets the terms under which each impression is offered and collects the bids that answer it.
- The SSP's auction may not be the last word, because a header bidding wrapper or the publisher's ad server can make the final decision.
- One SSP account leaves the same ID in four places a buyer can read: ads.txt, sellers.json, the publisher object and the supply chain node.
- Knowing the SSP tells a buyer whether a deal can run, which seat is needed and which path the money takes.
- Publishers connect several SSPs to reach more demand and formats, which is also why the same impression can arrive by several routes.
What is a supply side platform?
Definition
- Supply side platform (SSP)
- A platform that sells a publisher's ad inventory to automated buyers, impression by impression, under rules the publisher controls: minimum prices, blocked advertisers, approved buyers and deals.
The OpenRTB 2.6 specification (opens in a new tab) from IAB Tech Lab describes two sides of the market. Suppliers of publisher inventory include exchanges, networks working with publishers and sell side platforms; the buyers are bidders, demand side platforms and networks working with advertisers. The SSP sits on the first side. Its customer is the publisher, and its job is to get the publisher a fair price for each ad slot while keeping out the ads the publisher does not want.
| SSP job | What it means for the publisher | Where the buyer sees it |
|---|---|---|
| Connect demand | Sends each opportunity to many buying platforms at once | The bid request arrives from the SSP's own endpoint |
| Set a price floor | Refuses bids below a minimum the publisher chose | imp.bidfloor, with bidfloorcur for the currency |
| Block unwanted ads | Keeps out advertiser categories or brands the publisher rejects | bcat for blocked categories and badv for blocked advertiser domains |
| Package deals | Offers chosen impressions to chosen buyers on agreed terms | imp.pmp and its Deal objects |
| Pay the seller | Collects from buyers and pays the account that sold the impression | publisher.id, which matches a seller_id in the SSP's sellers.json |
The word exchange can name the same company, and the line between the two terms has blurred. The ad exchange page explains where the terms overlap; this page stays with the publisher side of the job.
How does an SSP decide which bid wins?
An SSP runs an auction for each impression, but it follows the publisher's rules first and the money second. The OpenRTB request it sends can declare those rules, so a buyer who reads the request can see why a bid was rejected before price was even considered.
How an SSP auction runs for one impression
- Build the request. The SSP describes the slot, the site and any deals, sets the floor, and names a tmax, the maximum time in milliseconds it allows for bids to arrive.
- Filter the bids. Bids under the floor, from blocked advertiser domains or categories, or from seats not invited to a deal are set aside.
- Apply the deal rules. When the request marks private_auction as 1, only bids on the listed deals are accepted; a deal can also carry its own price and auction type.
- Pick the highest eligible bid. The at field says how: 1 means first price, so the winner pays what it bid, and 2 means second price plus.
- Hand the winner on. If the Source object sets fd to 1, an upstream source such as a header bidding wrapper or the publisher's ad server makes the final sale decision, and the SSP's winner competes again there.
How does an SSP appear in ads.txt and sellers.json?
An SSP account is the thread a buyer pulls to trace an impression. The same account ID is meant to appear in the publisher's file, in the SSP's own file and in every bid request the account sends. The ads.txt 1.1 specification (opens in a new tab) says the account ID must contain the same value used in transactions, typically publisher.id in OpenRTB, and the sellers.json specification (opens in a new tab) says every advertising system listed in an ads.txt file should publish a sellers.json file.
| Where | What the SSP contributes | What the buyer confirms |
|---|---|---|
| ads.txt, field 1 | The SSP's canonical domain, the one bidders connect to | The domain is a system the buyer's platform actually receives requests from |
| ads.txt, field 2 | The seller account the publisher authorized on that SSP | The account ID is written exactly as the SSP issues it |
| sellers.json at the SSP's domain | One entry per account, with seller_type, name and domain | The account named in ads.txt exists and points back to the site's owner or manager |
| publisher.id in the bid request | The exchange specific seller ID behind this impression | The ID matches a seller_id in the SSP's sellers.json |
| A node in source.schain | asi, the SSP's domain, and sid, the same seller account | The node agrees with the files and the chain is marked complete |
Field by field reading of these files has its own guides: ads.txt, sellers.json and the supply chain object. For an SSP the point is simpler. A seller account that shows up in only one of these places is a path the buyer cannot fully confirm.
What does a buyer gain from knowing the SSP?
A buyer does not need to log into an SSP to buy through it. A buyer can bid through a demand side platform, and the SSP is a name in a report. Knowing which SSP sells each site on a plan still changes practical decisions, because deals, seats, fees and data access all live with the SSP, not with the site.
Questions to settle per SSP before a site list goes live
- The buying platform receives bid requests from this SSP, so the site can be bought at all through it.
- The site's ads.txt lists this SSP, and the line agrees with the SSP's sellers.json entry.
- The deal, if there is one, is set up on the SSP that holds the site's direct account.
- The seat ID the SSP needs for the deal belongs to the right advertiser or agency.
- The SSP passes a complete supply chain on requests for this site.
- Delivery reports can be broken out by SSP, so paths can be compared after launch.
The OpenRTB 2.6 specification defines a seat as the advertising entity, such as an advertiser or agency, that uses bidders to act on its behalf, usually the owner of the budget. When an SSP restricts an impression to certain seats through the wseat field, a bid from any other seat is not eligible, however high it is. A seat mismatch can leave a deal looking live on both sides while it delivers nothing.
Why do publishers use more than one SSP?
Each SSP brings its own set of connected buyers, its own deal tools and its own strengths in formats such as video or in-app. A publisher that connects several of them invites more bidders to each impression. Header bidding made this routine: the publisher's page or player asks several SSPs for bids at the same time, then lets the best one compete in the ad server. The header bidding guide covers how that works.
For the buyer, several SSPs on one site means several routes to the same reader. Each route can carry a different seller account, a different fee and a different level of transparency, and a buying platform connected to all of them may receive the same opportunity more than once. That is the problem the supply path optimization hub is built around: choosing which of those routes deserve the budget.
What does an SSP check look like on a real plan?
Fictional example
A veterinary clinic group in Calgary and Edmonton
A fictional group of veterinary clinics in Calgary and Edmonton wants display ads beside local news, pet care advice and community sites in both cities, in English. Its trading desk buys through one demand side platform, which receives bid requests from a set of SSPs, and the desk prefers a private auction deal over open bidding.
The planner reads the ads.txt file of each candidate site and groups the lines by SSP. Two SSPs appear on almost every site, so the planner asks each one which sites it holds as DIRECT accounts and confirms those accounts in each SSP's sellers.json, where the entries name the publishers themselves.
One Edmonton pet care blog sells only through an SSP the desk's platform does not connect to. The planner keeps the blog on the plan as a note for the client rather than dropping it, and asks the publisher whether a second SSP is planned. The deal goes to the SSP with the most direct accounts, and the desk checks that its seat ID is on the deal before launch.
How does PlacementGraph show which SSPs sell each site?
Frequently asked questions
Is an SSP the same as a publisher ad server?
No, though some companies offer both. The ad server decides which ad fills a slot across everything the publisher sold, including direct campaigns. The SSP sells the programmatic part and returns its best bid. In Google Ad Manager, for example, programmatic demand competes with other line items, and guaranteed transactions take priority over non-guaranteed ones.
Can an SSP block a specific advertiser?
Yes. OpenRTB gives the SSP fields to declare blocks in each bid request: badv lists blocked advertiser domains and bcat lists blocked advertiser categories. A bidder that respects them will not bid with those ads. The blocks come from the publisher's settings, so they can differ from one site to the next on the same SSP.
Does an SSP know which sites are on a buyer's inclusion list?
Not on its own. A buyer's inclusion list lives in its demand side platform, which simply declines to bid on sites outside the list. The SSP sees the list only when the buyer turns it into a deal on the SSP, such as a curated or private auction deal built from the chosen domains.
What is a seat in an SSP deal?
A seat is the buying entity, such as an advertiser or agency, that a bidder acts for. OpenRTB 2.6 lets the SSP allow only certain seats through the wseat field. If the seat on the deal does not match the seat the buyer bids with, the buyer's bids are ignored even when the deal ID is correct.
Sources
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab, OpenRTB 2.x repository
- OpenRTB 2.6 implementation notes (opens in a new tab)IAB Tech Lab, OpenRTB 2.x repository
- ads.txt Specification Version 1.1 (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
- sellers.json specification (opens in a new tab)IAB Tech Lab, Supply Chain Validation repository
- Ad Exchange line items (opens in a new tab)Google Ad Manager Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.