A request lifecycle is more useful than a feature checklist because it shows where latency, filtering, commercial rules and failures enter the system.
Receive and validate
The supply request must be structurally valid and acceptable to tenant policy before it consumes downstream capacity. Invalid or unsupported opportunities should produce understandable outcomes.
- Contract validation
- Required context
- Inventory policy
- Source identification
Select and route
Eligible demand endpoints are chosen using availability, capacity, configured policy and the request context supported by the connected auction service.
Observe the outcome
Response rate, bid rate, auction result, timeout and notice behavior create the operational evidence needed to tune routes and partner expectations.
Worked example: follow requests without counting them twice
Synthetic worked example. All traffic counts and timings below are authored test inputs, not customer data, measured platform performance or promised results. Start with an authored batch of 1,000 incoming requests: 80 invalid, 120 not eligible for the selected routes and 800 routed. Assume one impression opportunity per incoming request, two eligible demand endpoints per routed request and at most one acceptable bid per partner response. The 1,600 outgoing attempts yield 940 explicit no-bid responses, 420 acceptable bid responses, 160 timeouts and 80 invalid responses. Separately, 320 of the 800 routed auctions have a selected bid and 480 do not. These are synthetic worksheet categories, not a Nexus export schema or measured outcomes.
Synthetic data · interactive worksheet
Synthetic worked example. All traffic counts and timings below are authored test inputs, not customer data, measured platform performance or promised results.
One incoming batch, two different denominators
- Acceptable bids / outgoing attempts
- 26.25%
- Selected bids / routed auctions
- 40%
| Stage / scope | Authored outcomes | Reconciliation |
|---|---|---|
| Incoming batch | 80 invalid + 120 ineligible + 800 routed | 80 + 120 + 800 = 1,000 requests |
| Outgoing attempts | 940 explicit no-bid responses + 420 acceptable bid responses + 160 timeouts + 80 invalid responses | 800 routed requests × 2 endpoints = 1,600 attempts |
| Routed auctions | 320 with a selected bid + 480 without a selected bid | 320 + 480 = 800 auctions |
Calculation. 420 ÷ 1,600 × 100 = 26.25% per outgoing attempt. 320 ÷ 800 × 100 = 40% per routed auction. Assume 220 auctions receive one acceptable bid and 100 receive two: 220 + 2 × 100 = 420 bid responses across 320 auctions. Several bid responses may belong to the same auction: 420 bid responses do not mean 420 selected bids. The batch has no elapsed-time measurement and cannot establish QPS.
The two-endpoint assumption is not a routing guarantee or an included demand bundle. Prebid integration and a commercial relationship with a buyer are not established by this example.
Review OpenRTB controls and reporting ↗- Reconcile requests, demand attempts, auction selections, delivery events and billed outcomes as separate stages.
- A no-bid is not inherently an error. Classify partner no-bid, timeout and invalid-response behavior against the agreed integration contract.
- Neither percentage is CTR, delivered fill rate, revenue or a guaranteed Nexus result. A selected bid does not prove an impression, playback or payment.
- These exclusive worksheet categories illustrate arithmetic only. Validate the actual report fields, event definitions, period and filters in your deployment.
This guide describes Nexus product architecture and general AdTech operating concepts. Exact enforcement and integration behavior depends on the enabled revenue engine and agreed deployment configuration.
Published by Nexus Soft.
Content revised
Sources and product scope
Product references describe available controls and their limits. Examples are illustrative.