Real-time bidding explained
By Theaimart ADX ·
2 minute read · AI-assisted technical review
Real-time bidding lets buyers respond to an advertising opportunity through an auction protocol. A bid response is not proof that an ad rendered or became billable.
An auction is one stage of delivery
A useful engineering model has six boundaries: opportunity, eligibility, bid request, auction outcome, rendering and measurement. Each boundary needs its own success definition. A bid can win while the creative later fails to load; a rendered creative still needs the required measurement events.
OpenRTB is an industry interface for programmatic buying. Its existence does not establish that two implementations agree on every field, extension, creative type or operational policy. Check the actual version and partner contract.
Trace a hypothetical opportunity
Suppose a page has one eligible placement. The supply system describes the opportunity and invites bids within its configured constraints. Some buyers decline, one response is malformed, and another supplies a usable candidate. The auction can select that candidate, after which the delivery path must still render it.
If the browser closes before rendering, record an auction outcome separately from an impression. Do not make request success, winning response, rendered impression and billable event aliases of the same counter.
| Boundary | Record | Do not infer |
|---|---|---|
| Request | Eligible opportunity and request result | An ad was visible |
| Auction | Candidate selected or no fill | Revenue was settled |
| Renderer | Load or playback outcome | A viewability threshold was met |
| Measurement | Documented event and identifier | Payment eligibility |
Design failure paths before optimizing bids
Define behavior for timeouts, empty responses, unsupported creative assets and duplicate callbacks. Use a correlation identifier to investigate the same opportunity across stages, but keep sensitive request data out of general application logs.
A deterministic local fixture should cover a usable response, a no-fill response and a renderer failure. It is more informative than a demo that always returns a successful auction. Product-specific event names and retry policies must come from the supported integration contract.
Protocol support is not operational acceptance
A backend field for video does not prove a compatible player is installed. An SDK repository does not prove clean installation or target-device acceptance. A public specification does not prove live buyer demand. Verify those claims independently through integration availability and documented partner evidence.
This is an architecture explainer, not a claim of ADX OpenRTB certification, bidder connectivity or supported auction features beyond the current capability evidence.