Foundations

The AdTech auction, from request to impression

Trace the handoffs between publisher, exchange, DSP, and ad server.

Skills Labs Tech editorial · Updated 30 September 2026 · 7 min read · Educational examples

Start with the inventory, not the bid

A publisher owns the context in which an ad may appear. An ad slot has a location, supported sizes, and a format. An opportunity to show an ad becomes an auction request only when the integration reaches the relevant trigger. A page view is therefore not interchangeable with an ad request: a page may contain multiple slots, lazy loading may defer them, and a visitor may leave before a slot is requested.

Follow one request across the boundary

The exchange describes the opportunity to eligible buyers. A DSP evaluates whether the request fits a campaign and whether a bid is appropriate. A response is a proposed price and creative, not proof that an impression happened. Validation, auction selection, ad server competition, creative delivery, and browser execution can all occur after a buyer has returned a bid.

Build a stage ledger

For a integration investigation, record the page or app context, slot identifier, auction identifier, request timestamp, response timestamp, accepted bid, selected creative, and impression event. Keep identifiers at their real scope: an auction can contain several impressions, and separate systems may generate different event IDs. Never join reports on timestamp alone when concurrent auctions can overlap.

A worked example

Imagine 1,000 slot requests. Of those, 800 receive a buyer response, 650 contain a valid bid, 500 win the relevant competition, and 460 render successfully. Calling the response rate a 80% fill rate hides later losses. These are illustrative figures, not business results. Report each denominator explicitly and inspect the 40 selected ads that did not render before increasing demand.

Turn the trace into a product requirement

Require an observable state at every handoff and a documented reason when the flow stops. Useful outcomes include no eligible buyer, buyer timeout, invalid creative, auction loss, and render failure. The acceptance criterion should verify that the reason appears in the appropriate log or report. A dashboard total without traceable definitions is difficult to use during incidents.

Further reading

IAB Tech Lab OpenRTB. Product behavior depends on the version and integration; check the documentation used by your implementation.

Define the object being counted

Begin a trace by distinguishing a page, placement, opportunity, auction, and bid. A placement describes where an advertisement can appear. An opportunity is a particular chance to fill that placement. An auction can evaluate several buyers, and a buyer can return a response without offering a usable bid. Write these objects into the reporting contract before implementing a dashboard. For example, a page containing three placements might create only two opportunities if the third placement never enters the viewport. Counting the page as three delivered impressions would inflate the result. The contract should specify which event creates each record and which identifier links related records.

Create a synthetic trace

Use a synthetic example with one banner opportunity and two eligible buyers. Buyer A responds before the deadline with a valid creative. Buyer B responds after the deadline. Record that the request reached both buyers, but only one response was eligible for this auction. Then simulate a creative delivery failure after Buyer A is selected. The expected record should show an accepted bid and a failed render, rather than an impression. This example tests whether the system preserves intermediate outcomes. It also demonstrates why revenue and delivery reports cannot be inferred simply from the presence of a successful HTTP response.

Specify deadlines and late results

An auction deadline needs an owner and a clear clock. Document whether timing begins when the opportunity is created, when requests are dispatched, or when a downstream service receives them. Those choices produce different latency measurements. Record processing time separately from network time when the implementation permits it. A late response should have an explicit outcome, even if it is excluded from winner selection. Otherwise an engineer investigating buyer performance might interpret an absent result as a request that was never sent. Use controlled delays in a sandbox to check the boundary immediately before, at, and after the deadline.

Treat currency as part of price

A bid value without a currency is incomplete business information. If an integration converts currencies, document the source currency, destination currency, conversion reference, effective time, and rounding rules. Keep the original amount available for investigation. An illustrative bid of 2.00 in one currency is not directly comparable with a bid of 2.00 in another. Do not quietly assume a default that differs between systems. Product requirements should describe what happens when a currency is missing or unsupported. This is particularly important when an exchange, buyer, and reporting interface each display amounts using different defaults.

Separate identifiers from sensitive context

A trace can be useful without publishing its complete raw request. Start with auction identifiers, impression identifiers, timestamps, and outcome reasons. Remove personal identifiers and confidential commercial fields before using a trace in a ticket, article, or shared demonstration. Keep access to raw production data restricted to the people authorized to investigate it. Specify retention according to the operational need and applicable policy, rather than retaining every request indefinitely. Synthetic fixtures should use fictional domains and identifiers so a developer can reproduce the sequence without accidentally contacting real inventory or exposing an actual partner account.

Write acceptance criteria around transitions

For each transition, describe its precondition, permitted action, expected state, and observable evidence. A valid response arriving before the deadline should enter candidate selection. An invalid creative should produce a documented rejection reason. A render failure should not create a successful impression record. Include a duplicate callback scenario so a repeated event does not inflate counts. Keep the outcome independent of the exact wording of a log message: a stable event code is easier to assert than a sentence. These acceptance criteria can guide product discussions, integration checks, and the dashboard definitions used by operations.

Choose the next investigation from the ledger

Review losses stage by stage rather than changing several settings together. If requests are not dispatched, adding more buyers will not fix the initial trigger. If valid bids arrive but do not compete, inspect the handoff and targeting. If selected creatives fail to render, investigate delivery and browser execution. Compare a failing fixture with a successful one that differs in one important condition. Record the hypothesis, the observation that would support it, and the observation that would disprove it. A useful investigation ends with an explained transition and a repeatable check, rather than a temporary increase in a dashboard total.

Apply this guide with anonymized fixtures. Add your own verified operational examples when documenting a real integration.