How Real-Time Bidding Works

Every time a viewer lands on a page or a CTV app requests an ad, an auction runs in milliseconds. Here’s what happens inside that auction — from the moment the supply source (Publisher) sends a request to the moment a creative is served and revenue is recorded.

The Auction Flow

Timing Breakdown

Step by Step

1. Supply source sends a request

A supply source’s ad server (SpringServe, Google Ad Manager, FreeWheel, or a direct VAST call from a CTV app) sends a request to the Praevis exchange:

• VAST: GET https://rtb.praevis.com/vast?pub={ID}&w={W}&h={H}&ip={IP}&ua={UA}
• RTB: POST https://rtb.praevis.com/rtb with OpenRTB 2.5 JSON body

The request carries context: supply source ID, ad size, device type, geo, user agent, content genre.

2. Defender screens for invalid traffic

Before any auction runs, Defender checks:

• Is the IP from a known datacenter or bot network?
• Is the user agent empty or a known scraper?
• Is this IP sending more requests per second than any human could?
• Does the declared geo match the IP geo?

If any check fails, the request is rejected with a silent 204 No Content — no impression, no cost to the demand source, no revenue recorded. Invalid traffic never reaches the auction.

3. Pathfinder selects eligible demand sources

Rather than sending every bid request to every demand source (DSP), Pathfinder pre-filters using cached eligibility data refreshed every 30 seconds:

• Pool membership — is this demand source subscribed to this supply source’s pool?
• Geographic coverage — does this demand source bid on traffic from this country?
• Format compatibility — does this demand source accept VAST video / banner / native?
• Circuit breaker state — has this demand source been timing out? (auto-excluded until healthy)
• Budget (Guide) — has this demand source’s daily QPS budget been reached?

Result: 40–60% fewer wasted bid requests. Demand sources only receive requests they can act on.

4. Bids are collected in parallel

All eligible demand sources receive the bid request simultaneously. The exchange waits up to 150ms for responses.

Traditional RTB demand sources receive the full OpenRTB 2.5 bid request, run their own bidding logic in their own infrastructure, and return a bid or 204 no-bid.

Delegate demand sources run inside Praevis infrastructure. Their JSON strategy is evaluated in-process in under 1ms — no network round-trip, no timeout risk.

5. The auction runs

Once the bid window closes (or all demand sources have responded), the auction selects the winner:

• First-price auction — the winner pays exactly what they bid
• The winning bid must be above the supply source’s floor price
• If no bid clears the floor, the auction returns an empty VAST (passback)

Exchange margin is deducted from the clearing price. The remainder goes to the supply source.

6. The creative is returned

• VAST: The winning VAST URL is wrapped and returned to the supply source’s ad server as a valid VAST XML response. The ad server renders the creative.
• RTB: A win notification is sent to the winning demand source. The demand source serves its creative directly.

7. Impression is tracked and revenue recorded

When the creative is served (or shortly after the auction in VAST mode):

1. An impression event is written to Redis — zero database writes in the hot path
2. The stream aggregator picks up events every 60 seconds and updates time-bucketed metrics
3. The dashboard receives a WebSocket push every 5 seconds with the latest aggregated numbers

Revenue is stored in micro-dollars (millionths of a cent) to preserve fractional precision at scale.

What Happens When There Are No Bids?

If no demand source bids above the floor price, the exchange returns an empty VAST response (a valid XML with no ad). The supply source’s ad server handles this as a passback — it moves to the next demand source in its waterfall.

No impression is recorded, no revenue is counted, and the supply source’s fill rate for that request is 0%.

Key Terms

→ Full glossary: Key Terms