An online advertising revenue system sells ad opportunities on a user surface. Advertisers configure demand, the serving path chooses ads for individual opportunities, and event pipelines decide which observed outcomes become spend, reporting, pacing input, attribution, and model-training data.
RunCo is the running example. It sells running shoes, creates a campaign with a daily budget, uploads a shoe image, targets runner audiences, and chooses purchase as the outcome it wants optimized. When a user opens a feed or article page, the ad system decides whether RunCo can enter that opportunity, whether RunCo wins, what the client receives, which event charges RunCo, and which later purchase appears in reporting.
Surface means the product experience where the user is spending attention: feed, search results, article page, video player, app screen, or product grid. Ad opportunity means one concrete slot on that surface that may contain an ad.
Recommended reading order
- Online Advertising Revenue Systems — the end-to-end map and reading path.
- Advertising Marketplace Players — who owns the surface, buyer path, seller path, auction path, and measurement numbers.
- Offsite Ads and OpenRTB Bidding — how buyer-side systems bid for inventory they do not own.
- Advertiser Control Plane — what the advertiser configures and how those objects become serving records.
- Ads Indexing and Retrieval — how advertiser objects become candidate sets for request-time serving.
- Ad Serving Request Lifecycle — one opportunity from request context through retrieval, ranking, auction, render, and event emission.
- Advertising Money Measurement and Control — how events become spend, pacing, reports, and provisional feedback.
- Ads Attribution and Incrementality — how conversions become reporting credit and causal lift estimates.
- Ad Product Slices and Delivery Debugging — how to trace one product or placement through the whole system.
System Map
The diagram maps the whole sequence: advertiser configuration flows into request-time serving, then event streams flow into spend, pacing, reporting, attribution, and training.
The left side is advertiser and platform control state. The middle is request-time allocation. The right side is event processing: billing, reporting, attribution, pacing feedback, and model training.
Core States Moving Through The System
This table is the compact mental model for the rest of the sequence. Each later note owns one or two rows rather than repeating the whole system.
| State | Example | Canonical note |
|---|---|---|
| Marketplace ownership | Surface owner, advertiser buyer, publisher seller, demand-side platform (DSP), sell-side platform (SSP), exchange, measurement party. | Advertising Marketplace Players |
| Advertiser intent | Budget, target audience, creative, bid controls, optimization event, measurement source. | Advertiser Control Plane |
| Serving indexes | Targeting keys, candidate sources, fresh overlays, retrieval caps, forward records. | Ads Indexing and Retrieval |
| Serving decision | Eligible candidates, scores, winner, clearing price or charge basis, render instructions. | Ad Serving Request Lifecycle |
| Observed outcome | Render, impression, viewability, click, engagement, purchase. | Advertising Money Measurement and Control |
| Feedback state | Spend counters, pacing controls, reports, attributed conversions, lift estimates, model labels, cost controls. | Advertising Money Measurement and Control, Ads Attribution and Incrementality |
RunCo End To End
This trace follows RunCo’s sneaker campaign from configuration to later outcomes. It is product-level; the linked notes own the detailed mechanisms.
- RunCo creates campaign config: budget, audience, creative, bid strategy, objective, and measurement event.
- Config processing builds serving-facing records: lookup keys for retrieval, eligibility flags, spend-state keys, render records, log dimensions, and attribution config. Advertiser Control Plane defines those records.
- A user opens a surface with an ad opportunity: feed slot, search block, article placement, video break, or product grid unit.
- Serving builds request context, applies hard eligibility, retrieves candidates, trims the set, scores candidates, runs allocation/pricing, and returns render instructions. Ads Indexing and Retrieval owns the candidate lookup layer; Ad Serving Request Lifecycle owns the request sequence.
- The client may render the creative, record an impression, record viewability, or stop before measurement if the user scrolls away or the asset fails.
- A click, engagement, or conversion may arrive later.
- Billing decides whether one observed event creates spend.
- Pacing reads spend estimates and changes future auction participation.
- Reporting and attribution decide which campaign/ad group/creative receives credit.
- Training pipelines use joined events as labels for later retrieval, ranking, bidding, and pacing decisions.
RunCo can win allocation without a charge when the event chain stops before the product’s billing rule. If the creative fails to load, the chain stops before impression measurement. If the product charges for clicks, render alone leaves the billing rule unsatisfied. Advertising Money Measurement and Control owns that distinction.
Three Loops
These loops share events but run at different speeds. The main source of confusion is treating them as one pipeline.
| Loop | Fast path | Slow path | What goes wrong |
|---|---|---|---|
| Request loop | Eligibility, retrieval, ranking, auction, response. | Index rebuilds, feature backfills, model retraining. | Lost demand, lower auction pressure, worse relevance, timeouts. |
| Money loop | Event dedupe, spend counters, pacing input. | Reconciliation, credits, invalid-traffic filtering, invoices. | Overspend, underdelivery, billing disputes. |
| Learning loop | Fresh clicks, renders, provisional conversion labels. | Attribution backfills, incrementality studies, model training. | Miscalibration, biased labels, weak exploration. |
Infrastructure cost controls sit inside those loops. A smaller candidate set changes auction depth. A cheaper ranker changes allocation. Sampled diagnostic logs reduce debuggability. Slower spend updates affect pacing. Cost cuts in ads systems need CPU and storage checks plus revenue, trust, and reporting checks.
Where Each Question Belongs
Use this routing table when a detail starts to feel duplicated. The answer should live in the canonical note and be linked elsewhere.
| Question | Canonical note |
|---|---|
| Who owns the surface, auction path, or report? | Advertising Marketplace Players |
| How can a platform buy inventory it does not own? | Offsite Ads and OpenRTB Bidding |
| What did the advertiser configure? | Advertiser Control Plane |
| How does one opportunity become a selected ad? | Ad Serving Request Lifecycle |
| What is the ad index, and why are there different index shapes? | Ads Indexing and Retrieval |
| How do ranking, auction, pricing, and whole-page constraints fit together? | Ad Serving Request Lifecycle |
| Why did the winner create spend, or fail to create spend? | Advertising Money Measurement and Control |
| Why did delivery speed up, slow down, or stop? | Advertising Money Measurement and Control |
| Why do platform, advertiser, and third-party numbers disagree? | Ads Attribution and Incrementality |
| How do I debug one ad product end to end? | Ad Product Slices and Delivery Debugging |
Sources
- OpenRTB 2.6 Specification
- MRC Viewable Ad Impression Measurement Guidelines
- Google Ads auction documentation
- Google Ads Ad Rank documentation