Ad Exchange vs SSP vs Ad Network: Which One Do You Actually Need?

Ask five people in this industry to define an SSP and you will get five answers, at least two of which describe an ad exchange. Ask what separates an exchange from a network and someone will say “real-time bidding,” which was true in 2012 and has not been reliably true for a decade — plenty of networks run auctions now, and plenty of things called exchanges are reselling somebody else’s.

This is not a vocabulary problem. It is a symptom: the three categories were defined by capabilities that have since become commodities, so the labels stopped tracking anything real. Everyone runs an auction. Everyone connects to Prebid. Everyone has a dashboard.

Which leaves anyone actually choosing a platform — or deciding what to build — without a useful question. So here is one that still works: which decisions do you want to own, and which are you happy to rent? That question separates the three cleanly, it predicts what you will spend and earn, and unlike the labels, it does not change with the marketing.

Table of Contents

• What is an ad network?
• What is an ad exchange?
• What is an SSP?
• Why did the three categories collapse?
• The question that actually separates them
• Where the money is different
• Which one do you actually need?
• What running your own marketplace actually requires
• The mistake: buying a category instead of a capability
• Key takeaways
• Running your own exchange on Floxis
• Sources worth bookmarking

What is an ad network?

An ad network aggregates inventory from many publishers, packages it, and sells it to advertisers as products — “automotive audiences in Germany,” “premium sports video,” “US mobile gaming.”

The defining property is not technological, it is commercial: the network takes a position. It decides what the inventory is worth, what to charge for it, and which advertisers see it. Publishers hand over supply and receive a rate; advertisers buy a package and receive delivery. Neither sees the other’s side of the transaction, and the network’s margin lives in that gap.

That opacity is the model, not a flaw in it. A network earns by being better at packaging and selling than its publishers would be alone, and the spread is the fee for that service. It works well when the network has genuine sales capability, genuine advertiser relationships, or a specialized inventory type that programmatic channels price badly.

Where it struggles is scale and scrutiny. Manual packaging does not scale linearly, and the same buyers running the supply path analysis that reshaped exchange relationships are asking networks the same questions about what they take. A network that cannot answer them is competing on relationships alone.

What is an ad exchange?

An ad exchange is a marketplace. It does not take a position on what inventory is worth — it runs an auction and lets the participants decide.

Supply connects and offers impressions. Demand connects and bids. The exchange matches them in real time, applies whatever rules each side configured, and takes a fee for operating the market. It is closer to a stock exchange than to a broker: the value of the thing being traded is discovered by the trading, not set by the venue.

That neutrality is why exchanges scaled where networks plateaued. There is no packaging step to staff, so adding supply is an integration rather than a sales cycle. It also creates the exchange’s characteristic problem: a marketplace with no position has no inherent margin, so exchange economics depend on volume, on the fee being defensible, and increasingly on the marketplace being better run than its competitors — cleaner declarations, tighter latency, richer signal.

An exchange is defined by owning the auction and the rules around it. Not by using RTB, which everyone does now.

What is an SSP?

A supply-side platform is a set of tools for a publisher to manage their programmatic selling: connect demand sources, set floors, manage brand safety and blocklists, look at reporting, get paid.

Historically, an SSP was a client of exchanges — it plugged a publisher into several, optimized between them, and did not run an auction itself. That distinction died. Every major SSP now runs its own auction and sells directly to DSPs, which makes it, functionally, an exchange with a publisher-facing product wrapped around it.

The label persists because it describes a posture rather than an architecture. “SSP” signals that the product is built for the publisher: the interface, the reporting, the support model and the defaults are all oriented toward the seller. “Exchange” signals a venue serving both sides. Same auction underneath, different customer in the design.

That is worth knowing when evaluating vendors, because the posture shows up in what the product makes easy. An SSP will make floor management and revenue reporting excellent and demand-side configuration shallow. An exchange platform will expose both sides and expect you to have an opinion about each.

Why did the three categories collapse?

Four things happened, none of which anyone planned.

Header bidding removed the exchange’s structural advantage. Once publishers could call many demand sources simultaneously from the page, the “premium exchange” position — privileged access to good inventory — largely evaporated. Everyone got to bid on everything, so the differentiator moved from access to execution.

The auction became a commodity. Running a first-price auction at scale was a genuine engineering achievement in 2012. It is now something a competent team assembles from open-source components in a quarter. When the defining capability becomes commodity, the definition stops defining anything — a point we made at length about the cost of building an exchange, where the auction turns out to be the cheap part.

Everyone integrated with everyone. Networks added RTB endpoints to buy programmatically. SSPs added direct DSP relationships. Exchanges added publisher tools to compete with SSPs. Each moved toward the others because each had customers asking for what the others had.

Buyers stopped caring what you call yourself. SPO analysis evaluates a path on fee, duplication, latency, reliability and signal. None of those inputs is your category. A network, an SSP and an exchange with identical path characteristics score identically, and a category label has never saved anyone from a cut list.

The question that actually separates them

Strip the labels and three decisions distinguish these models. Each can be owned or rented, and the combination you choose is your business model.

Read down the columns and the models resolve into something clearer than their names. A network owns pricing and demand selection and monetizes the information gap. An SSP owns the machinery and rents it to publishers who keep control of rules. An exchange owns the venue and rents participation to both sides.

Now read across the last two rows, because that is where a decision that feels technical turns out to be strategic. Whoever owns the brand and the demand relationship owns the customer. A publisher selling through an SSP has a relationship with the SSP; the advertiser has a relationship with their DSP; nobody in the middle owns anything durable. An operator running their own exchange owns both sides of that relationship — which is why the question “which of these do I need” is so often really the question “do I want to be a customer of this market or a venue in it.”

Where the money is different

The three models make money in genuinely different shapes, and the shape determines what you need to be good at.

A network earns on spread, which means it earns on judgment. Buy well, package well, sell well, and the margin can be large — considerably larger than any exchange fee. The costs are sales headcount and the risk of holding a position on inventory that does not sell. It scales with people.

An SSP earns a take rate on publisher revenue, so it earns on the publisher’s success. Its incentive is well-aligned and its ceiling is bounded by the take rate and the publisher base. Costs are product and support: publishers are demanding customers with real integration needs. It scales with the number of publishers and how much each one grows.

An exchange earns a fee per transaction, so it earns on volume and on being a path buyers keep. The margin per impression is thin, the operating leverage is high — the marginal cost of another impression is close to nothing once the platform exists — and the entire model rests on the fee being defensible when audited. It scales with throughput.

The failure mode differs too, and it is worth knowing which one you are signing up for. A network fails by losing the sales relationships. An SSP fails by losing publishers to a better product. An exchange fails by being cut from supply paths — quietly, without notice, discovered as a volume decline nobody can explain for a month.

Which one do you actually need?

Matching the model to the situation, honestly:

You have inventory and want it monetized with minimum effort. You need an SSP, or several. Do not build anything. The programmatic stack is a mature product category and your marginal hour is better spent on your audience than on an auction. Run the path-count audit annually and otherwise leave it alone.

You have advertiser relationships and inventory access, and your edge is selling. You are a network, whatever you call yourself. Your investment belongs in sales capability and in the packaging that makes your inventory worth more than its programmatic clearing price. Where you need programmatic infrastructure, buy it.

You aggregate supply from others and resell it. You are already an intermediary and the SPO question is existential rather than theoretical. What matters is whether you add something — demand, enrichment, market access — beyond a hop. If you do, owning the marketplace makes that value yours instead of your platform’s. If you do not, no amount of infrastructure will save the path.

You have both supply and demand relationships and you are currently paying someone to sit between them. This is the clearest case for running your own exchange. You are paying a fee on transactions you already source both sides of, and the platform in the middle owns the data, the brand and the relationship. The arithmetic is straightforward: at sufficient volume the fee you are paying exceeds the cost of the platform, and everything above that line is margin you are currently donating.

You want to offer monetization to your own customers under your own brand. Publishers with a network of partner sites, ad tech companies wanting a supply product, agencies building a media practice. You need a marketplace that is yours, which is what white-label exchange platforms are for — the point being that your customers are your customers rather than a vendor’s.

What running your own marketplace actually requires

If the last two cases apply, the honest inventory of what “running an exchange” involves — because the auction is the part everyone imagines and the smallest part of the work.

The auction and the pipeline. Receive OpenRTB, apply rules, call demand, pick a winner, return a response, do it in single-digit milliseconds of your own overhead inside a 200–300 ms buyer budget. Genuinely solved.

The integration treadmill. Every partner has quirks. Non-standard endpoints, custom macros, odd VAST handling. This never ends and it is the work that most surprises teams who budgeted for the auction.

The compliance surface. ads.txt and app-ads.txt crawling, sellers.json publication, schain validation, TCF and GPP passthrough. Not optional, not one-time, and increasingly the thing that determines whether buyers can transact with you at all.

Settlement. Log-level records reconciling what buyers paid, what publishers earned and what you kept, at a granularity that survives a dispute. This is where “we will fix reporting later” becomes an accounting problem with real money attached.

Signal and enrichment. The requests you send need to describe their inventory completely, or your path loses the tiebreak against exchanges carrying the same impressions. Covered in full in our bid request enrichment guide.

Operations. Someone watches latency tails, breaks circuits on failing partners, chases declaration drift, and answers a publisher asking why revenue dropped on Tuesday.

Six areas. One is a solved engineering problem and five are ongoing operational commitments — which is the real content of the build-versus-buy decision, and why it so rarely comes down to whether you can write an auction.

The mistake: buying a category instead of a capability

The recurring error in platform selection is shopping for a label. “We need an SSP” is a decision made before the real questions, and it produces predictable regret: a publisher-oriented product bought by someone who needed demand-side control, or an exchange platform bought by someone who needed excellent publisher reporting and got a toolkit instead.

The questions that actually discriminate, in the order they matter:

1. Whose brand is in front of your customers? If the answer must be yours, most of the category collapses immediately.
2. Who owns the demand relationships? If you have them, paying someone else to intermediate them is the most expensive line item you are not looking at.
3. What must you be able to change without asking? Floors, fees, routing, partner terms. Anything that requires a support ticket is not something you control.
4. What does the fee look like from both sides? If you cannot reconcile it in both directions, neither can your buyers — and they are checking.
5. What happens to your data? Log-level access to your own transactions is the difference between a business you can optimize and one you can only observe.

Answer those five and the category names become irrelevant, which is the point. The right platform is the one that leaves the decisions you care about on your side of the line.

Key takeaways

• The three categories were defined by capabilities that are now commodities, so the labels no longer predict much. Everyone runs an auction.
• What still separates them: who decides the price, who selects the demand, who sees the fee, whose brand is on it, and who owns the relationship.
• Networks earn a spread and scale with people. SSPs earn a take rate and scale with publishers. Exchanges earn a per-transaction fee and scale with volume.
• If you only have inventory, buy an SSP and stop thinking about it. If you have both sides and are paying someone to sit between them, that fee is the case for owning the venue.
• Running a marketplace is one solved engineering problem and five permanent operational commitments. Budget for the five.
• Shop for capabilities and control, not for a category. Ask whose brand, whose relationships, what you can change without asking, whether the fee reconciles both ways, and who owns the data.

Running your own exchange on Floxis

Floxis exists for the two cases at the bottom of the decision list: you have both sides of the transaction, or you want to offer monetization to your own customers under your own brand.

It is a white-label RTB exchange you run as your own — your domain, your branding, your invoicing, your margin at a rate you set. The five permanent commitments come with the platform rather than with a hiring plan: custom adapters for non-standard partners are built and maintained for you; ads.txt, sellers.json, schain validation, TCF and GPP are built in and continuously re-crawled; settlement reads from a log-level bid, win and drop ledger about a minute behind the auction; requests are enriched with geography, identity, placement and content signal before they leave; and per-endpoint QPS, timeout and routing are yours to change without a support ticket.

The decisions stay on your side of the line. You connect the demand, you set the fee, you own the relationships, and your customers see your brand rather than ours.

If you are still working out which model fits, our build versus buy analysis puts numbers on the operational side, and the white label exchange guide is the vendor checklist. Book a demo and we will work through your own supply and demand mix.

Sources worth bookmarking

• OpenRTB 2.6 specification — the protocol every one of these platforms speaks, whatever it calls itself.
• IAB Tech Lab sellers.json specification — where a platform declares whether it is a publisher or an intermediary, which is the one categorical distinction that is machine-readable.
• IAB Tech Lab ads.txt specification — the authorization layer that made supply chains legible.
• Prebid documentation — the header bidding infrastructure that dissolved most of the distinctions in this article.