Post

Introduction to AdTech: How Publishers, Advertisers, and Auctions Really Work

Introduction to AdTech: How Publishers, Advertisers, and Auctions Really Work

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 the functional components of the Supply and Demand stacks, specifically focusing on how they handle Guaranteed Deals versus Programmatic Auctions. We will explore how the industry has consolidated specialized tools into hybrid platforms and why the “Dual-Server System” is the foundation of trust between buyers and sellers.

1. The Publisher’s Command Center: Google Ad Manager

While we often talk about SSPs as standalone entities, the modern reality is more integrated. The dominant player 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 automatically 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 millions of advertisers bidding through Google Ads and DV360 .

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.


2. Direct Deals vs. Programmatic: Fulfilling the Promise

Large publishers like The Times of India or New York Times still sell a significant portion of their inventory through Direct-Sold Deals negotiated by human sales teams. The technical “campaign” inside a publisher’s ad server is a delivery campaign focused on fulfilling these pre-negotiated contracts.

FeatureAdvertiser Campaign (DSP)Publisher Campaign (Ad Server)
PurposeTo Buy impressions efficiently to meet a KPI.To Deliver on a pre-negotiated contract.
Primary GoalAchieve objectives like ROAS or CPA.Fulfill a guaranteed number of impressions/clicks.
Key SettingsBudget, bidding strategy, and targeting.Priority levels, flight dates, and impression goals.
CreativesHosted on advertiser server; called via tag.Often uploaded directly by the publisher’s team (trafficked).

3. 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.

  • Publisher Ad Server (1st Party): Used by site owners (e.g., The Times of India) to decide which ad to show.
  • Advertiser Ad Server (3rd Party): Used by brands (e.g., Tata Motors) to host creatives once and run them across hundreds of sites while independently verifying counts .

The “Redirect” Mechanics

When the Publisher Ad Server decides to show a Tata Motors ad, it does not send the image directly to the browser. Instead, it sends an Advertiser’s Ad Tag (a redirect). The browser then makes a second call to the Advertiser’s Server, which logs the impression and finally delivers the creative. This dual-count system prevents fraud and builds trust between parties.

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.


4. The Blurring Lines: Ad Servers, SSPs, and DSPs

Modern AdTech has shifted from separate systems to deeply integrated ones.

  • SSP + Ad Server: In the modern market, the SSP is 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.
  • DSP + 3rd Party 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 .

5. Waterfall Decision Logic: The Traditional Approach

When an ad request hits the Publisher’s Ad Server, it usually follows a strict hierarchy to decide what to show:

  1. Guaranteed Deals: “Is there a high-priority contract (like Tata Safari) I must fulfill?”.
  2. Programmatic Auctions: “If not, can I get a higher price by sending this to an auction via the SSP?”.
  3. House Ads: If no one bids high enough, the server shows an internal ad (e.g., an Amazon banner for “Amazon Prime”) to fill the space for free.

6. Header Bidding: A More Competitive Alternative

The traditional waterfall model 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 multiple buyers at the same time, before the Publisher Ad Server makes its final decision.

How it Differs from the Waterfall

  • Waterfall: Demand sources are queried sequentially based on priority.
  • Header Bidding: Multiple SSPs and buyers bid in parallel, competing purely on price.

What Changes in Practice

  1. The user loads the page.
  2. A header bidding mechanism requests bids from multiple SSPs simultaneously.
  3. The highest bid is passed into the Publisher Ad Server as a line item.
  4. The ad server compares:
    • Guaranteed deals
    • The winning header bid
    • House ads
  5. The highest-value option wins.

Why Publishers Prefer Header Bidding:

  • Higher yield: Every buyer gets a fair chance to bid, increasing competition.
  • Price transparency: Decisions are driven by actual bids, not preset priority.
  • Better market efficiency: Publishers no longer leave money on the table due to rigid ordering.

Importantly, header bidding does not replace the Publisher Ad Server. It simply feeds better price signals into it - allowing the final decision to be both contract-aware and market-driven.


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.

In the next article, we’ll dive into Ad Tags, Tracking Pixels, and the Redirect Loop that makes the millisecond handshake possible.

Enjoyed this article? Never miss out on future posts - follow me.
This post is licensed under CC BY 4.0 by the author.