An ad serving request is one attempt to fill one ad opportunity on a surface: a feed position, search result block, article slot, video break, or native module.
The request path starts when a surface asks the ad server for an ad and ends when the server returns render instructions or no-fill. The render and event paths run afterward: the client tries to display the selected creative, and event systems decide whether an impression, click, conversion, or billable event was recorded. Advertising Money Measurement and Control owns the later money and measurement rules.
Terms Used In This Note
These terms separate the request-time decision from later client and event outcomes.
| Term | Meaning |
|---|---|
| Surface | The place where the user is spending attention: Pinterest feed, Google search results, news article, app screen, video player. |
| Ad opportunity | One concrete slot that may contain an ad. Example: the third module in a feed or a 300x250 slot beside an article. |
| Placement | Product-defined location and format for an ad opportunity, such as feed_card, search_top, article_sidebar, or video_midroll. |
| Request context | Facts sent to serving for this opportunity: surface, placement, country, language, device, content context, privacy state, and any user/session identifiers allowed for ad serving. |
| Candidate | Ad, ad group, product ad, or creative that may be scored for the current opportunity. |
| Creative | The user-visible ad asset and its render metadata: image, video, product unit, native fields, destination URL, trackers, and format constraints. |
| Render instructions | The payload returned to the client: native fields, image/video URLs, destination URL, click tracker, impression tracker, and rendering constraints. Native fields are structured ad components such as title, body text, image, product, and call-to-action. |
| No-fill | A response saying no ad should be rendered for this opportunity. |
| Frequency cap | Delivery rule limiting how often the same user or device can see a campaign, ad group, advertiser, or creative over a time window. |
One Pinterest Feed Example
Pinterest feed example. A user opens the Pinterest home feed. Pinterest builds the feed and reaches a position where it can place an ad. That position is the ad opportunity.
The ad server receives context for that opportunity:
- surface: Pinterest home feed,
- placement: feed card,
- country: United States,
- device: iPhone,
- privacy state: consent, opt-out, age, region, and identifier rules for this request,
- user/session signals allowed for serving,
- content context from the surrounding feed.
The server returns either no-fill or render instructions for a selected creative. If RunCo’s sneaker ad wins allocation, the client still has to load and display the creative. User scroll-away, asset failure, timeout, or a click-priced billing rule can stop the path before spend.
Lifecycle
The diagram splits one ad opportunity into three paths: server request, client render, and event processing. Read it left to right as a time sequence, with the event path continuing after the server has already answered the request.
Request Path
The request path chooses a response under latency. Retrieval and ranking are inside this path; billing and attribution are downstream.
1. Create The Opportunity
The surface creates an ad opportunity when it reaches a slot that can contain an ad.
Common surfaces create different kinds of ad opportunities:
| Surface | Opportunity |
|---|---|
| Feed | A sponsored card between organic posts. |
| Search | A sponsored result block above or below organic results. |
| Article page | A display slot beside or inside the article. |
| Video player | A pre-roll, mid-roll, or post-roll break. |
| Commerce surface | A sponsored product slot in a product grid. |
The opportunity belongs to that page or app assembly. The same user can create many opportunities in one session: feed card, search ad, shopping unit, and video break.
2. Build Request Context
Serving needs the facts for this opportunity. The request context usually contains surface, placement, geography, language, device, content context, privacy state, and any user/session identifiers allowed for ad serving.
Privacy state is the request-time permission envelope for ads. It combines consent choices, opt-outs, age or household restrictions, region-specific legal rules, and whether the platform may use account, cookie, device, session, or clean-room-derived identifiers for this opportunity. A logged-in US adult with ad personalization enabled can usually use audience membership, frequency-cap history, and conversion-matching identifiers. A child-directed surface, a user who opted out of personalized ads, or a request under a stricter regional consent state may force contextual-only serving: the server can use facts about the page, app, search query, placement, and broad geography, but not user-level audience membership or cross-site conversion identifiers.
Privacy state affects the serving path before ranking. It can remove targeting keys, choose a different frequency-cap key, block retargeting campaigns, suppress user-level features, limit which trackers are returned, or prevent conversion-matching IDs from being attached to later events.
Those facts drive four families of serving behavior:
| Request fact | Used by |
|---|---|
| Surface, placement, creative format | Eligibility, retrieval keys, reserves, render compatibility. |
| Geography, language, device | Targeting, legal rules, localization, creative constraints. |
| Privacy state and allowed identifiers | Audience matching, frequency-cap keys, retargeting eligibility, tracker eligibility, conversion matching limits. |
| Content context | Keyword, contextual, product, safety, and relevance features. |
3. Apply Hard Eligibility
Eligibility removes ads that fail contract, safety, privacy, budget, format, or availability rules for this context.
Hard eligibility checks include paused campaigns, closed flight dates, incompatible creative formats, policy blocks, privacy restrictions, budget or frequency blocks, and deleted or out-of-stock products. These checks enforce rules. Relevance and predicted performance usually belong later in ranking unless the product defines a hard quality floor.
4. Retrieve And Trim Candidates
Ad retrieval maps request facts to a bounded set of candidate ads before scoring and ranking run. It answers a lookup question: “which active ads could plausibly serve for this placement and context?” Its output is candidate IDs plus lightweight serving records for the scoring stage.
The ad index is the serving-time lookup layer that maps request facts to candidate IDs. Ads Indexing and Retrieval owns the deeper explanation of index shapes, fresh overlays, and why retrieval is an economic gate.
| Index shape | Example lookup | Where it fits |
|---|---|---|
| Inverted index / posting lists | keyword:running shoes → search ad groups. | Keyword, geo, audience, contextual, placement, product-category retrieval. |
| Bitmap or compressed set index | geo:US-CA AND surface:feed AND format:image. | High-QPS eligibility intersections. |
| Key-value serving record | ad_group:456 → bid owner, creative ids, budget key, serving version. | Fetching fields after candidate IDs are retrieved. |
| Fast state overlay | campaign:123 → paused, policy blocked, budget exhausted, product out of stock. | High-churn blocks that change faster than full index rebuilds. |
| Vector index | User/context embedding → nearby products, ads, or creatives. | Soft retrieval for broad match, recommendations, exploration, sparse contexts. |
For RunCo, geo:US-CA, audience:runners, surface:feed, and format:image can retrieve the sneaker ad group and compatible creative. If privacy state removes the audience:runners key, RunCo may still be retrievable through a contextual key such as context:running or query:trail shoes, but not through that user’s audience membership. A budget overlay can remove the campaign if the pacing system already treats it as exhausted.
Candidate control applies caps and cheap gates before the scoring stage: per-source caps, per-advertiser caps, final candidate count, freshness overlays, and approximate pre-scores. A pre-score is a small heuristic or lightweight model used to decide which candidates deserve expensive feature reads. It is upstream of ranking; the ranker later scores the surviving candidates with the fuller model. A lower cap saves feature reads and model inference, but it also removes advertisers from auction pressure before pricing.
5. Score Candidates
Ranking estimates the value of showing each candidate in this context. Inputs can include predicted click probability, predicted conversion probability, bid or automated bid-strategy output, quality signals, landing-page signals, creative fatigue, pacing state, and the ad product objective.
For a cost-per-click product, a simple score can be:
Three sneaker ads illustrate the difference between raw bid and expected value:
| Ad | Bid | Predicted click probability | Expected click revenue per impression |
|---|---|---|---|
| A | 2.00 per click | 1.0% | 0.020 |
| B | 1.20 per click | 2.0% | 0.024 |
| C | 4.00 per click | 0.3% | 0.012 |
Ranking by raw bid gives the slot to C. Ranking by expected click revenue gives it to B.
6. Allocate And Price
Auction/allocation chooses which candidate gets which slot under bids, scores, reserves, pacing, and page constraints. A reserve is a minimum score, quality, or price threshold for showing an ad. Pacing is the budget-control signal that can throttle or adjust a campaign’s participation in future auctions. Pricing computes the auction price or charge basis implied by the auction rule. Billing later turns recorded events into spend.
Auction families differ by payment idea:
| Shape | Payment idea | Where it appears |
|---|---|---|
| First price | Winner pays its own bid. | Much of modern programmatic display. |
| Second price | Single-slot winner pays the next-highest bid. | Clean theory and historical intuition. |
| Generalized second price | Multi-slot winners pay enough to keep their positions over the next scored bidder. | Sponsored search history. |
| Vickrey-Clarke-Groves | Winner pays the externality imposed on others; under simplified assumptions it encourages truthful bidding. | Mechanism-design reference point. |
| Quality-adjusted auction | Bid is multiplied or blended with predicted response and quality. | Large consumer ad platforms. |
A high-scoring candidate can still be rejected by reserve, budget, policy, pacing, or page constraints. For multiple slots on the same page, allocation may also enforce no duplicate advertiser, category diversity, ad-load limits, position-specific value, or creative-format mix.
7. Return Render Instructions
Serving returns either no-fill or render instructions. Render instructions can include native title/body fields, image or video asset URLs, product data, destination URL, click tracker, impression or viewability tracker, and constraints such as aspect ratio, autoplay policy, or video protocol. A tracker is a callback URL or client/server event hook used to record impressions, clicks, viewability, billing notices, or diagnostics.
At this point the request path is done. The selected ad has won server-side allocation for this opportunity. Spend still depends on later events.
Render And Event Boundary
The selected creative can fail before becoming an impression. This table explains where server selection can stop before measurement.
| Case | What happened |
|---|---|
| User scrolls away | The slot leaves the viewport before the creative reaches the measurement point. |
| Asset request fails | Image, video, or native payload load fails. |
| Creative times out | The client abandons the ad because rendering exceeds the deadline. |
| Layout changes | The feed or page drops the slot before display. |
| Verification blocks render | Safety or verification code prevents display. |
The event path records insertion, render attempt, impression, viewable impression, click, engagement, and conversion events. Advertising Money Measurement and Control owns how those records become spend, pacing input, reporting, attribution, and training labels.
Open-Web Version
In open-web programmatic advertising, the same request lifecycle crosses company boundaries. The ad slot lives on a publisher page, app screen, or video player. That slot is onsite inventory for the publisher and offsite inventory for the buyer-side platform bidding on it. Offsite Ads and OpenRTB Bidding owns the buyer-side bid path in more detail.
- Publisher owns the page or app slot.
- Sell-side platform (SSP) packages the opportunity into a bid request, the message that describes the slot, format, floor price, privacy flags, and context.
- Exchange path routes the bid request to buyers.
- Demand-side platform (DSP) retrieves campaigns, checks budget/frequency state, scores candidates, and returns a bid response or no-bid.
- Exchange path selects a winner.
- Publisher renders the creative.
- Win notices, billing notices, impression trackers, clicks, and conversion streams record later outcomes.
The network hops make latency part of allocation. A DSP timeout removes that buyer from the auction before its advertiser can compete. Advertising Marketplace Players owns the actor boundaries.