Programmatic Lab EXPLORE · EXPERIMENT · LEARN

PROGRAMMATIC ADVERTISING SANDBOX

Understand how an impression becomes an ad.

Run a browser-side header bidding auction, follow the Mini SSP and DSP decisions, inspect the OpenRTB supply path and see why the ad server chose the final creative.

Start exploring How it works
300 × 250 Ad Slot Waiting for an auction…

Simulated inventory. No real ads are served.

ARCHITECTURE

The Programmatic Flow

Follow one impression from the publisher page to the final creative.

01
▣

Publisher Page

A user loads a page containing an available ad impression.

→
02
</>

Prebid.js

The real browser wrapper starts an auction and calls three custom bidder adapters.

→
03
▤

SSP Adapter

Each adapter converts its simulated SSP result into a standard Prebid bid.

→
04
⇄

DSP

The impression is evaluated and a bid or no-bid decision is returned.

→
05
◇

Ad Server

The Prebid winner competes with direct demand under the selected delivery rule.

→
06
▧

Creative

The selected ad is rendered back into the publisher's ad slot.

EXPLORE THE BUILD

Interactive Labs

Choose a module to learn how it was built and get a practical experiment to run.

SERVER RESPONSE

Header Bidding Auction

Auction #—
Header bidding results by SSP supply path
Supply path DSP selected CPM Latency Result
Run an auction to generate SSP responses.
Floor: €0.50 Timeout: 1000 ms SSPs: 3 Winner: —
BROWSER-SIDE HEADER BIDDING

Prebid.js Event Console

Observe the browser wrapper create an auction, request three SSP bids, receive responses and hand its highest eligible candidate to the ad server.

PREBID RUNTIMELoading…
1PUBLISHERAd unit300 × 250
2WRAPPERPrebid.jsDetecting version…
3BIDDER ADAPTERSAtlas · Beacon · CascadeRuntime adapters
4AUCTION SERVICENode.js APIRender
Prebid auction ID
—
Ad unit
/homepage/rectangle
Bidder requests
0
Valid responses
0
Prebid winner
—
Wrapper elapsed
—
LIVE EVENT STREAMEvents emitted by Prebid.js
  1. Run an auction to capture Prebid lifecycle events.
FINAL DELIVERY DECISION

Ad Server Decision

Prebid selects the best programmatic bid. The ad server then compares that candidate with direct demand and chooses what the publisher finally renders.

FINAL DECISIONReady
PROGRAMMATIC
PB

Prebid candidate

— Waiting for the wrapper auction
SIMULATEDAd ServerAwaiting candidates
DIRECT SOLD
DC

Northstar Travel

€2.50 Price-priority campaign
FINAL DELIVERY OUTCOME Run an auction to compare demand.

The header bidding winner is not necessarily the creative that ultimately appears.

This is a deliberately simplified ad server. It teaches price priority and guaranteed sponsorship behavior; it is not Google Ad Manager and does not model pacing, forecasting, targeting, frequency caps or every delivery rule.

LIVE HTTP CONNECTION

Infrastructure Monitor

The browser now requests auction data from a separately deployed Node.js service.

AUCTION ENGINENot configured
CLIENT Publisher UI Vercel · Browser JavaScript
SERVER Auction API Render · Node.js
Endpoint
Not configured
HTTP status
—
Round trip
—
Request ID
—
Data source
Local fallback

Add your Render service URL in config.js to activate the backend.

SUPPLY-PATH AUCTION

Supply Path Explorer

Each SSP asks its connected DSPs for bids, validates the responses, and returns one result to the publisher.

1 DSP auction inside each SSP 2 SSP auction at the publisher
Three SSP paths are ready

Run an auction to inspect the DSP competition inside each path.

Notice the duplicated buyers. The same DSP can access the impression through more than one SSP. Each route is a separate supply path and can produce a different price or latency.

PUBLISHER AUTHORIZATION

ads.txt Authorization Explorer

Compare every SSP route with the publisher's public seller declarations before the simulated buyer allows it into the auction.

BUYER POLICYReady

Important boundary: ads.txt is publicly hosted and normally crawled by buyers outside the live page auction. Prebid.js does not automatically read or enforce it. This lab applies a simulated buyer policy so the authorization consequence is visible.

File status
Available
Seller records
3
Authorized paths
3
Excluded paths
0
PUBLIC PUBLISHER FILEprogrammatic-lab.dev/ads.txt
Open file ↗ 
# Run an auction to evaluate the file.
1 Ad system domain 2 Publisher account ID 3 DIRECT or RESELLER 4 Certification authority ID
SIMULATED BUYER CHECKPath authorization

Run an auction to compare the three supply paths with the selected file scenario.

SELLER IDENTITY + PAYMENT PATH

sellers.json & SupplyChain Explorer

Resolve every asi + sid pair to a disclosed seller, then follow the ordered payment nodes carried in source.schain.

TRANSPARENCY CHECKReady

How the standards divide the work: ads.txt declares which advertising-system account may sell the publisher's inventory; sellers.json identifies the entity behind an account; schain travels with the bid request and orders the entities involved in payment. This lab's public sellers.json is a combined educational snapshot. Normally, each advertising system hosts its own file.

Supply paths
3
Payment nodes
—
Verified nodes
—
Paths with issues
—
EDUCATIONAL SELLER REGISTRYprogrammatic-lab.dev/sellers.json
Open file ↗ 
Run an auction to resolve seller identities.
IDseller_idAccount inside an ad system TYPEseller_typePublisher or intermediary WHOname + domainEntity receiving payment
OPENRTB SOURCE.SCHAINPayment-chain verification
ver 1.0

Run an auction to inspect the SupplyChain object for every SSP route.

asi Advertising system domain sid Seller account ID hp Participates in payment complete All prior nodes are known
PROTOCOL VIEW

OpenRTB Inspector

Inspect the bid request sent by an SSP and the response returned by a connected DSP.

PAYLOAD MODEL OpenRTB 2.6

The payloads are structurally realistic and educational. Each server-generated bid request includes source.schain. The SSP-to-DSP exchange is still simulated inside one Node.js process.

< / > No protocol exchange to inspect yet

Run an auction, then select any SSP path and DSP connection.

CHRONOLOGICAL AUCTION EVENTS

Auction Timeline

Replay the modeled SSP response times alongside the real Prebid auction result and see which supply paths qualified before the timeout.

Ad unit /homepage/rectangle Format 300 × 250 Supply paths 3 SSPs Closes at 1000 ms
◷ No auction to inspect yet

Choose your settings and run an auction. SSP responses will appear here in chronological order.

    AUCTION OUTCOME Waiting for an auction… The highest eligible SSP response received before the timeout wins.
    BEHIND THE LAB

    One interface. Multiple real system boundaries.

    The lab combines browser technology, a separately deployed auction service and controlled market simulations so every decision can be inspected safely.

    1PUBLISHERPublisher page

    Creates the impression and collects the experiment settings.

    2REAL WRAPPERPrebid.js

    Calls three custom adapters and ranks eligible SSP responses.

    3AUCTION SERVICEAuction API

    Validates the request and creates the server-side auction model.

    4CONTROLLED MODELMini SSP + DSPs

    Produces inspectable bids, latency and OpenRTB exchanges.

    5FINAL DECISIONAd server

    Compares the Prebid candidate with direct demand and renders the winner.

    RUNNING TECHNOLOGY

    What is real

    • Prebid.js executes in the browser and emits its real lifecycle events.
    • Custom bidder adapters submit eligible SSP results to the wrapper.
    • The browser sends a real HTTP request to the Node.js API on Render.
    • The API validates inputs and returns structured auction data.
    • OpenRTB-shaped payloads include ads.txt outcomes and source.schain.
    • ads.txt and sellers.json are publicly served files after deployment.
    EDUCATIONAL MODEL

    What is simulated

    • The SSPs and DSPs are learning models, not commercial platforms.
    • CPMs, no-bids and processing latency are generated by controlled lab logic.
    • SSP-to-DSP exchanges run as separate responsibilities inside one service.
    • The ad server demonstrates selected priority rules rather than every GAM behavior.
    • No media is purchased, no real ad is served and no advertising identifier is collected.
    FOLLOW THE PIPES

    The demand path inside Programmatic Lab

    One impression fans out through three SSP routes. Each SSP runs its own DSP competition and returns one candidate to Prebid. Direct demand enters later, at the ad server, after header bidding has finished.

    INVENTORYPublisher impression

    Floor, timeout and consent

    IMPRESSION
    HEADER BIDDINGPrebid.js

    Sends parallel requests

    BID REQUESTS
    SUPPLY + DEMANDThree SSP auctions run in parallel
    SSP AtlasDSP AlphaDSP Beta
    SSP BeaconDSP BetaDSP Gamma
    SSP CascadeDSP AlphaDSP Delta

    Each SSP returns only its strongest valid DSP bid.

    3 SSP RESPONSES
    WRAPPER AUCTIONPrebid winner

    Highest eligible SSP response

    CANDIDATE
    DIRECT ENTERS HEREDirect campaign

    Price priority or guaranteed

    FINAL DECISIONAd server

    Prebid candidate vs. direct demand

    WINNER
    DELIVERYCreative renders

    One final ad reaches the slot

    Important: the direct campaign does not bid through an SSP and does not compete inside Prebid. It joins only when the ad server compares the completed header-bidding result with direct demand.

    Turning invisible infrastructure into an observable product.

    Programmatic advertising is difficult to learn because the most important decisions happen across systems that users rarely see together. This project exposes those decisions in one coherent experience.

    THE CHALLENGE

    Explain browser auctions, supply paths, transparency files, protocol payloads and final delivery without relying on disconnected diagrams.

    THE APPROACH

    Model one impression end to end, keep every module synchronized to the same auction and make each rejection or winning decision explainable.

    WHAT I BUILT

    Interactive controls, Prebid adapters, a Node.js API, Mini SSP/DSP logic, OpenRTB inspection, authorization explorers, infrastructure monitoring and automated tests.

    WHAT IT DEMONSTRATES

    Programmatic architecture, technical product thinking, troubleshooting, API design, data visualization and the ability to translate complexity into practical learning.

    Programmatic Lab is an independent educational project created by a programmatic advertising professional with experience across campaign operations, consulting and platform solutions.

    Contact the Creator ✉
    Help keep the Lab running

    Programmatic Lab is free to use and independently maintained. If it helped you learn, you can make an optional contribution toward hosting and future improvements.

    The complete learning experience remains free.
    Privacy and project disclosure

    Educational purpose: Programmatic Lab models advertising infrastructure for learning. It does not sell media, serve commercial ads or represent an SSP, DSP or ad server vendor.

    Data boundary: The lab does not intentionally collect advertising identifiers or build user profiles. Auction settings are used to generate the demonstration and may be sent to the configured auction API.

    External services: Prebid.js is loaded from a CDN. Ko-fi opens as an external website and applies its own privacy terms.

    Audience measurement: Vercel Web Analytics records anonymous, aggregated page-view information to help improve the Lab. It does not use third-party cookies or associate visits with an individual or IP address.

    Before activating support: Add the provider identification, tax and privacy information required for your own location and payment setup. Optional contributions do not unlock features.