Introduction to AdTech: Who Decides Which Ad Gets Served?
In our first post, we looked at the high-speed “Invisible Auction” that happens every time a webpage loads. In this post, we’ll move from the marketplace overview to a single question that turns out to sit at the center of the whole supply side: when an ad slot becomes available, who decides which ad gets served, and how? Answering it means separating guaranteed contracts from programmatic auctions, understanding why buyers and sellers each run their own ad server, and seeing why “highest bid wins” is almost never the full story.
1. Functions First, Products Second
Before naming any product, it helps to separate the functions a supply-side stack performs from the vendors that happen to bundle them. Confusing the two is the single most common source of AdTech misconceptions, because one company’s suite can quietly span several functions that are, in principle, distinct:
- Publisher ad serving: deciding which creative fills a given slot on a given page load, and recording that decision.
- Inventory and line-item management: defining ad slots, and the campaigns (“line items”) eligible to fill them.
- Yield decisioning: choosing the most valuable eligible option, balancing guaranteed obligations against market demand.
- Sell-side auction and access: exposing inventory to programmatic buyers (the SSP function).
- Advertiser creative serving: hosting a brand’s creative once and delivering it across many publishers.
- Independent measurement: counting deliveries and outcomes with one consistent rule set, on either side.
- DSP buying: deciding, on the advertiser’s behalf, whether and how much to bid.
The rest of this article maps these functions onto real products, using Google’s stack as a dated implementation example (accurate as of writing) rather than as the definition of how every publisher operates. Different publishers integrate, separate, or outsource these functions in different combinations.
2. The Publisher’s Command Center: Google Ad Manager
While we often talk about SSPs as standalone entities, the modern reality is more integrated. A widely used platform on the supply side is Google Ad Manager (GAM), formerly known as DoubleClick for Publishers (DFP). It is a hybrid platform that functions as an air traffic control tower for a publisher’s website, managing all ad slots (inventory) and deciding which “plane” (ad creative) gets to land where and when.
Google Ad Manager combines three critical functions into one “brain”:
- The Publisher’s Ad Server (Primary Role): The centralized system for managing inventory, defining ad slots (e.g., “homepage_top_banner”), and trafficking direct-sold campaigns.
- A Supply-Side Platform (SSP): An integrated engine that auctions off “remnant” or unsold inventory to programmatic buyers.
- The Gateway to AdX: A privileged connection to Google’s Ad Exchange, providing a direct pipeline to advertisers bidding through Google Ads and DV360.
This tight integration is a feature of this platform, not a law of the supply side. In general the SSP function may be integrated into the ad server, contracted separately, run client-side or server-side, or reached through yet another exchange. Google happens to fuse them; many publishers deliberately do not.
The Analogy: Think of the Publisher Ad Server as the General Manager of a 5-star hotel. They manage the rooms (ad slots), handle large direct corporate bookings (direct deals), and oversee the online system for filling rooms nightly. The SSP is the hotel’s built-in Online Booking Engine - a specialized sub-component that offers available rooms to thousands of travel agents (DSPs) simultaneously to get the highest possible price.
3. Direct Deals vs. Programmatic: Fulfilling the Promise
Large publishers like The Times of India or New York Times still sell part of their premium inventory through Direct-Sold Deals negotiated by human sales teams (the exact share varies widely by publisher and is not a fixed rule). The technical “campaign” inside a publisher’s ad server is a delivery campaign focused on fulfilling these pre-negotiated contracts.
| Feature | Advertiser Campaign (DSP) | Publisher Campaign (Ad Server) |
|---|---|---|
| Purpose | To Buy impressions efficiently to meet a KPI. | To Deliver on a pre-negotiated contract. |
| Primary Goal | Achieve objectives like ROAS or CPA. | Fulfill a guaranteed number of impressions/clicks. |
| Key Settings | Budget, bidding strategy, and targeting. | Priority levels, flight dates, and impression goals. |
| Creatives | Hosted on advertiser server; called via tag. | Often uploaded directly by the publisher’s team (trafficked). |
4. The Dual-Server Architecture: Why Two Ad Servers?
One of the most fundamental concepts in AdTech is that there are two types of ad servers that sit on opposite sides of every transaction. A quick terminology note first: it is common to hear these called “first-party” and “third-party” ad servers, but that borrows browser vocabulary for a business-side distinction and invites confusion. Whether a given network request is same-site or cross-site from the browser’s perspective is a separate question (one the next article tackles directly). Here we use publisher-side and advertiser-side to mean simply who operates the server.
- Publisher-side ad server: Used by site owners (e.g., The Times of India) to decide which ad to show.
- Advertiser-side ad server: Used on behalf of brands (e.g., Tata Motors) to host creatives once and run them across many sites while independently counting deliveries. In practice this server is frequently operated by the brand’s agency or ad-tech platform, not literally by the brand itself.
How the Handoff Works
When the publisher-side ad server decides to show a Tata Motors ad, it does not send the image directly to the browser. Instead, it returns an ad markup / ad tag that instructs the browser to make a second call to the advertiser-side server, which logs the delivery and returns the actual creative. (The precise redirect and pixel mechanics are the subject of the next article; here we only need the fact that two servers each get to count.)
This independent double-count improves auditability - each side measures with its own rules - but it is worth being precise about what it does not do. It does not by itself prevent fraud, and it does not produce a single source of truth. The two numbers routinely disagree, for entirely legitimate reasons: different impression definitions, time zones, cache-busting, JavaScript failures, ad blocking, invalid-traffic filtering, viewability standards, and attribution windows.
The Analogy
Think of a large supermarket ecosystem.
The Publisher Ad Server is like the manager of a single BigBasket store. They decide which products get shelf space in that store, when they are displayed, and they record sales only for that location.
The Advertiser Ad Server is like the Nestlé brand manager responsible for KitKat sales across every supermarket chain - BigBasket, Reliance, Amazon Fresh, and more. Instead of relying on each store’s sales report, the brand manager tracks shipments and sales from Nestlé’s own systems, using the same measurement logic everywhere.
Why?
Because each store:
- Reports sales slightly differently
- May apply its own discounts, bundling, or accounting rules
- Has an incentive to report numbers that favor their performance
To understand how much KitKat actually sold globally, Nestlé needs one independent, consistent source of truth - even if it doesn’t perfectly match every store’s numbers.
That’s exactly why Advertiser Ad Servers exist:
- Publishers report what they showed and counted
- Advertisers track delivery and performance independently, using the same rules across all publishers
Both numbers matter - but they serve different purposes.
One clarification so the analogy does not mislead: in the ad world, the thing being counted is not a sale but an impression render (and later, clicks and conversions). Nestlé counting KitKat shipments is the intuition for independent measurement with a consistent rule set; it is not a claim that an impression equals a unit sold. Swap “units sold” for “ads rendered and counted” and the logic transfers exactly.
A small reconciliation
To see why two honest parties report different numbers, walk one impression through the parties that count it:
| Party | What it counts | Typical definition |
|---|---|---|
| Publisher-side ad server | An eligible ad response was returned | Server logged a delivery decision |
| Advertiser-side ad server | The creative actually rendered | Browser fetched and ran the ad markup |
| Verification vendor | The impression was viewable | ≥50% of pixels on screen for ≥1 second |
| Billing | The agreed billable event | Whichever definition the contract names |
None of these is “wrong.” They count different events, so a 100-impression campaign can legitimately show four different totals. Which number gets paid on is a contractual choice, not a technical inevitability - a thread the series picks up again in the later measurement and billing articles.
5. The Blurring Lines: Ad Servers, SSPs, and DSPs
Modern AdTech has shifted from separate systems to deeply integrated ones.
- SSP + Ad Server: In tightly integrated suites, the SSP behaves as a component within the publisher’s ad server - the ad server is the operating system, and the SSP is an application running inside it to manage programmatic yield. This is common but not universal: plenty of publishers run an SSP that is separately contracted from, and only loosely coupled to, their ad server.
- DSP + advertiser-side Ad Server: These remain functionally separate systems that work in sequence. A DSP is for media buying, while the ad server is for measurement and creative hosting. Even when sold as a single suite (like Google’s DV360 and Campaign Manager 360), they perform distinct sequential tasks.
6. Waterfall Decision Logic: The Traditional Approach
A common first-pass mental model is that the publisher’s ad server follows a strict hierarchy: guaranteed deals first, then a programmatic auction, then house ads. That story is a useful starting point but it is genuinely incomplete, so it is worth stating more carefully.
The real decision is eligibility and opportunity cost, not a fixed running order:
- Build the eligible set. Which line items and deals may serve this impression at all, after applying targeting, delivery goals, pacing, priority, frequency caps, and policy?
- Value the guaranteed obligation. A reserved campaign that is behind pace carries real cost if it under-delivers (a “makegood” later), so its effective value is not just its nominal CPM.
- Compare against market demand. Where the platform supports dynamic allocation, a programmatic bid is allowed to win an impression that a reservation could have taken - but only when the bid clears the opportunity cost of setting the reservation back. Google’s own ad-selection documentation describes this reservation-protecting comparison (a dated implementation example, not a universal definition).
- Select and record. Pick a creative and log the decision.
- Fall back. If no monetized option is eligible, show a house ad (e.g., an internal “Amazon Prime” banner) to fill the space for free.
So “guaranteed always runs first” is closer to a default than a law: a high enough programmatic bid can, under dynamic allocation, outrank a reservation that is comfortably ahead of pace.
7. Header Bidding: A More Competitive Alternative
The traditional tag waterfall works sequentially - but that sequencing is also its biggest limitation. Each demand source is tried one after another, meaning high-paying buyers further down the chain may never even see the impression.
Header bidding changes this.
Instead of asking demand sources one by one, the publisher exposes the impression to several selected demand partners at the same time, before the publisher-side ad server makes its final decision. Two things are worth being precise about right away, because the marketing gloss oversells both: header bidding invites a chosen set of partners, not “every buyer,” and the bids it collects are compared net of fees and subject to deal, creative, and price rules - not “purely on price.”
What Changes in Practice
- The user loads the page.
- A header-bidding mechanism requests bids from several demand partners simultaneously, under a timeout (late bids are simply dropped).
- The winning bid is passed into the publisher-side ad server as a line item (usually via key-values).
- The ad server compares that header bid against guaranteed deals and house ads, applying the same eligibility and opportunity-cost logic from the previous section.
- The most valuable eligible option wins.
So header bidding does not erase contracts or make every buyer equal; it improves simultaneous competition relative to a sequential waterfall, and then hands a better price signal into the same contract-aware decision.
Client-side, server-side, or waterfall
“Header bidding” is really a family of designs with different tradeoffs:
| Legacy waterfall | Client-side header bidding | Server-side (Open Bidding) | |
|---|---|---|---|
| Where it runs | Ad server, sequential | In the browser, in parallel | On a server, in parallel |
| Competition | One source at a time | Several partners at once | Many partners at once |
| Latency cost | Low per call, high in total | Adds browser-side delay | Lower browser delay |
| Transparency | Poor (priority-driven) | Good, but partner-limited | Fees/logic less visible |
| Main drawback | Leaves money on the table | Page-load latency, complexity | Trust in the server operator |
Why Publishers Prefer Header Bidding
- Higher yield: Selected buyers compete at once, increasing competition versus a rigid order.
- Price transparency: Decisions are driven by actual bids, not preset priority - though how transparent depends on the client/server variant.
- Better market efficiency: Publishers leave less money on the table from rigid ordering.
The tradeoffs are real, though: header bidding adds latency, operational complexity, and duplicate-auction risk. And it does not replace the publisher-side ad server - it feeds better price signals into it, letting the final decision be both contract-aware and market-driven.
8. A Worked Decision: Three Candidates for One Slot
Everything above becomes concrete the moment we make the ad server choose. Priya has just loaded Wanderlust Weekly, and one slot is up for grabs. Three candidates are eligible:
| Candidate | Headline price | Delivery state | Other constraint |
|---|---|---|---|
| Urban Hiker guaranteed line item | ₹120 CPM (reserved) | Behind pace | Frequency cap allows |
| Header-bidding winner | ₹150 gross CPM | No obligation | ₹20 CPM in fees |
| House campaign | ₹0 | Unlimited | Fallback only |
A naive “highest bid wins” reading picks the ₹150 header bid instantly. But the real decision asks four sharper questions:
- Is ₹150 gross comparable to ₹120 reserved? No. The header bid is quoted gross; net of its ₹20 fee it clears ₹130 to the publisher.
- What is the opportunity cost of the guaranteed goal? The Urban Hiker line item is behind pace. Skipping it now raises the risk of an under-delivery makegood later, which has its own cost. That makes its effective value higher than its ₹120 face rate.
- Is the creative even eligible? A bid the ad server cannot serve (blocked category, wrong size, failed policy) is worth ₹0 regardless of price.
- What actually wins? Depending on how the publisher weights the makegood risk, either the ₹130-net header bid or the pace-protected reservation can win. The house ad only serves if both fall through.
The point is not the specific winner. It is that “priority order” and “highest bid” are both incomplete: the genuine logic is eligibility, net value, and opportunity cost together.
Two ledgers for the decision
As with the intro, it helps to read the money and data trails side by side.
Money ledger (if the header bid wins):
| Event | Amount | Recipient | Caveat |
|---|---|---|---|
| Advertiser bid (gross) | ₹150 CPM | Enters the auction | Not yet publisher cash |
| Header-bidding / SSP fee | ₹20 CPM | Intermediary | Fee stacks vary |
| Publisher recognized revenue | ₹130 CPM | Publisher | Subject to reconciliation and IVT deductions |
| Makegood exposure (if reservation slips) | later cost | Publisher | Why the ₹120 reservation isn’t simply “lower” |
Data ledger:
| Stage | Data created or shared | Why |
|---|---|---|
| Ad request / line-item match | Slot, page, device, targeting keys | Build the eligible set |
| Header-bidding call | The impression opportunity, sent to several partners | Parallel competition |
| Advertiser-side creative call | A second request to the winner’s server | Creative + independent count |
| Measurement / vendor calls | Delivery, viewability, verification events | Counting and billing |
Privacy and power (in brief). Notice a quiet asymmetry in the data ledger: to run parallel competition, the header-bidding step broadcasts the same impression opportunity to several demand partners, so many organizations receive data about Priya’s page load even though only one ad ever renders. Competition that raises the publisher’s yield also widens the set of parties who observe the request - a tradeoff we keep returning to.
Conclusion & Continuity
The publisher’s stack is a complex machine balancing guaranteed revenue with real-time competition. By integrating SSP functionality and coordinating with advertiser-side ad servers, publishers can maximize their yield while maintaining trust - but “who decides which ad serves” is answered by eligibility, net value, and opportunity cost, not by a fixed running order or a single highest number.
In the next article, we’ll dive into Ad Tags, Tracking Pixels, and the Redirect Loop that makes the millisecond handshake possible.