AdOps Core
YIELD AND MONETIZATION

Why did programmatic bid volume drop even though traffic stayed stable?

Stable traffic with lower bid volume can mean a buyer or server-side endpoint hit a queries-per-second limit and started throttling requests. Compare request coverage, endpoint QPS, timeout rate and bid rate before treating the drop as weaker buyer demand.

By AdOps Core. Updated .

Separate coverage from buyer responseIllustrative data, not research results
Eligible opportunities100,000 events
Requests sent60,000 events
Bids returned12,000 events

Illustrative data: coverage is 60% of eligible opportunities. Bid rate is 20% of sent requests. Each percentage has a different denominator.

Programmatic systems have finite request capacity. When traffic peaks above an endpoint or buyer QPS allocation, some eligible auctions are never sent, are sampled, or arrive too late to be useful. Bid volume falls even though page traffic and available impressions remain stable.

Separate request coverage from bid response rate. For the same time window, compare eligible auctions, requests sent to each demand path, throttled or sampled requests, endpoint latency, timeouts and returned bids. Segment by region and traffic peak because an average can hide a short capacity ceiling.

Fix the capacity bottleneck, traffic allocation or timeout hierarchy, then confirm request coverage recovers before evaluating buyer performance. Do not increase browser timeouts blindly, because a later bid still has no value if it misses the ad server handoff.

Separate request coverage and bid rate

Request coverage is sent requests divided by eligible opportunities for a particular demand path. Bid rate is returned bids divided by sent requests. Use consistent definitions and count retries separately.

Inspect capacity at the time of the drop

  1. Compare eligible opportunities with sent, dropped, and sampled requests.
  2. Segment short peak intervals by endpoint and region.
  3. Inspect configured limits, latency, timeouts, and errors.
  4. Check whether the change is capacity-related or an intentional allocation rule.

Confirm capacity recovery before evaluating demand

Coordinate capacity or allocation changes with the endpoint owner. Verify that extra requests complete within useful deadlines and that errors do not rise.

Only then compare buyer response rate, wins, and revenue. More transmitted requests alone do not prove better monetization.

Test your reasoning: Keep bid rate separate

Original simulated exercise. This is not a real client case.

A demand path returns fewer bids.

Evidence available

  • Eligible opportunities remain 100,000.
  • Sent requests fall from 80,000 to 50,000.
  • Bid rate stays at 20% of sent requests.

What explains the arithmetic drop in bid volume?

Read the answer and next check

At the same bid rate, bids fall from 16,000 to 10,000 because fewer requests are sent. Investigate coverage, including capacity or allocation, before concluding demand weakened.

Next check: Inspect peak-time throttling and completed request latency on the affected endpoint.

Research and further reading

Platform documentation

This guide provides context for bidder operation and request handling. The capacity examples here isolate request coverage for teaching; they are not performance guarantees.

Read more on Google's RTB application practices

Go deeper

FAQ

How is request coverage different from bid rate?

Request coverage measures how many eligible auctions were sent to a demand path. Bid rate measures how often that path responded with a bid after receiving a request.

Does lower bid volume always mean lower buyer demand?

No. QPS throttling, sampling, endpoint latency or a timeout hierarchy can reduce the number of requests a buyer receives before buyer demand is measured.

Continue learning

← All guides