RTB Traffic Shaping: Cutting QPS Without Cutting Revenue

Every bid request an exchange sends out is paid for twice. The exchange pays to send it: connections, serialization, egress, auction state. The demand partner pays more to receive it — each request that crosses their edge is parsed, enriched, matched against every live campaign and priced, inside a few hundred milliseconds. And most of those requests die right there. No campaign matches, no bid comes back, and both sides have spent real money to establish that nothing happened.

Traffic shaping is the discipline of not sending those requests. The cutting is not the hard part — a bid-rate table and a threshold will slash your outbound QPS by lunchtime. That is precisely the problem. Anyone can cut QPS by 40%; the question that matters is what the cut cost, and most shaping setups cannot answer it. “Revenue looks fine” is not an answer, because traffic mix moves on its own — by hour, by day, by whatever your supply partners shipped this week — and a before/after comparison across a moving mixture proves nothing in either direction.

So this guide is built around one claim: a shaping change is an experiment, not a config edit. The filtering is the easy half. The measurement — the holdout that tells you what would have happened if you had changed nothing — is the half that decides whether shaping made you money or quietly threw it away.

Table of Contents

• The economics of a request nobody bids on
• Why do demand partners impose QPS caps?
• Choosing what to drop
• Dropping a request is not the same as dropping a seat
• The feedback problem: shaping starves its own data
• How do you prove a shaping change did not cost revenue?
• What to monitor while shaping is live
• The failure modes that cost real money
• Buyers are shaping you too
• What kind of machine learning this actually is
• Key takeaways
• Shaping on Floxis
• Sources and standards worth bookmarking

The economics of a request nobody bids on

Programmatic demand is nowhere near uniform. A DSP seat cares about some geographies and not others, some formats, some sizes, some hours of the day — because behind the seat sit campaigns with targeting, and targeting is narrow by design. Fan every request out to every seat and the outbound stream is dominated by pairings that structurally cannot clear: video demand receiving banner requests, US-only budgets receiving APAC traffic, a seat whose campaigns ended on Friday still receiving full volume on Monday.

The waste is real on both sides. On yours, it is infrastructure that scales with requests sent rather than revenue earned — the guide to setting up an RTB exchange walks through what each outbound call involves. On the demand side it is worse: evaluating a bid request is the expensive step in the chain — user matching, campaign selection, pacing, pricing, all under a deadline. A DSP’s cost line scales with requests received; its revenue line scales with impressions won. Every request it will never bid on moves those lines apart.

That gap is why shaping exists, and why it is not a courtesy. An exchange that sends a partner ten requests for every one the partner would consider is charging that partner to be its customer. The partner’s answer is a QPS cap.

Why do demand partners impose QPS caps?

A QPS cap is a demand partner’s way of fixing their unit economics on your traffic without renegotiating anything. Their bidders are provisioned for a certain evaluation rate, every integrated exchange wants more than its share, and the cap rations the capacity. Read it as a statement of terms: we will evaluate this many of your requests per second — make them your best ones. Which requests fill the allotment is left to you, and that decision is what traffic shaping is. An exchange that fills its cap with random traffic and one that fills it with proven-biddable traffic get very different bid rates from the same integration.

What happens when you exceed the cap is the part that catches operators out: usually, nothing visible. Sustained overage is rarely answered with an error code or an email. It is answered at the partner’s edge — requests dropped at their load balancer before a bidder ever sees them, surfacing on your side as timeouts, empty responses, or nothing at all. Your monitoring shows the seat’s bid rate sagging and its timeout rate creeping up, which looks exactly like fading demand or a degrading integration. Silent throttling is the default because it is the cheap option at their end; you will not be told when it starts.

The second-order effect matters more over time. Demand platforms continuously score the supply paths they buy through — bids earned per request evaluated is a number they watch per exchange. Consistently fill your allotment with biddable traffic and you build the case for a bigger one; ship noise and you build the case for a smaller one. The setup guide made the placement argument — per-seat QPS caps belong in the router from the start — and shaping extends the same mechanism: the cap says how much you may send, shaping decides what.

Choosing what to drop

Shaping decisions are made from signals, and every good signal is also wrong in a specific, predictable way. The craft is knowing both columns of this table:

Two principles keep these signals honest.

Segment at the level demand actually varies. Per-seat shaping alone is too coarse — a seat that ignores 90% of your traffic may be the top bidder on the other 10%, and a per-seat cut takes both. The workable grain is the segment: a geo × format × size × supply-source cell coarse enough to accumulate meaningful bid-rate history in hours, fine enough that “this seat does not bid on this cell” is a fact about demand rather than an average across unrelated things.

Rank, don’t just threshold. The naive rule — drop every segment below some bid rate — ignores what the cap is for. If a seat’s cap forces you to choose 60% of your traffic to send, the right 60% is the best-ranked segments by expected value, not whatever clears an arbitrary bar. Ranking also degrades gracefully: when supply shifts, the allotment stays full of the best available traffic.

Every row, though, has a failure mode only a measurement loop catches — which is where this article is headed.

Dropping a request is not the same as dropping a seat

Shaping has two distinct verbs, and conflating them is an expensive habit.

Dropping a seat from a request removes one demand partner from the fan-out while the auction proceeds for everyone else. The common, cheap case: the request had five candidate seats, one has never bid on this segment, so four get called. The impression can still clear, and the cost of being wrong is bounded — one bidder’s participation, for as long as the decision stands. Per-seat drops are also what QPS caps require, since each partner’s cap is its own budget.

Dropping the request entirely means no auction happens at all. Nothing is sent, no bid can arrive, and the impression goes unfilled unless something upstream has a fallback. The cost of being wrong is the whole impression, so the evidence bar is higher: not “few seats bid on this” but “no seat has bid on this segment across a volume that rules out luck, and carrying it costs more than it earns.”

The asymmetry dictates the architecture. Per-seat decisions can be aggressive, numerous and cheap to revisit; request-level drops should be rare, conservative and individually justified. And your drop ledger must record which verb fired and why, because “requests to seat B down 30%” and “auctions down 30%” are different events that a single counter renders identical.

The feedback problem: shaping starves its own data

Here is the trap built into every shaping system, and it is the default unless engineered away. A request you never sent produces no data. Every signal above is computed from traffic you sent; the moment shaping suppresses a segment, that segment stops generating evidence. If the decision was wrong — or was right in March and wrong in June, when a buyer launched campaigns wanting exactly that traffic — nothing in your data will ever say so. The bid-rate history that justified the drop is frozen at the moment of the drop, and the frozen number keeps justifying it forever.

Naive shaping is therefore self-reinforcing. The system converges on the traffic it already believed in, suppressed segments can never rehabilitate themselves, and the error compounds silently — no alert fires, because the revenue being lost never had the chance to appear. Demand is not stationary, so a shaping decision is a hypothesis with an expiry date, not a fact. A system that never re-tests expired hypotheses is not optimizing; it is memorizing the past.

The mitigations are all forms of continuing to buy information:

• A holdout that never shapes. Route a deterministic slice of traffic through the exact status quo — everything sent, nothing suppressed. Every suppressed segment keeps flowing there at reduced volume, generating current evidence that either re-confirms the drop or overturns it. It is the same holdout the next section demands; it earns its cost twice.
• Expiry on every decision. A segment drop should have a time-to-live, after which the segment is re-tested rather than re-assumed.
• Score no-answers as unknown, not as no. Timeouts, HTTP errors and throttled silence are absence of evidence; a valid no-bid is evidence of absence. A model that feeds on both without distinguishing them learns a partner’s bad week as a permanent preference.

How do you prove a shaping change did not cost revenue?

You prove it the way any causal claim is proven: with a concurrent control. Before a shaping rule touches live traffic, requests are hashed deterministically into arms — the same request always lands in the same arm, so arms are stable, comparable populations. One arm, the holdout, receives the exact status quo; the others receive the change. Because both run at the same time, against the same supply mix, hour-of-day curve and demand conditions, the difference between them is the change — not the weekend, not a partner’s budget refresh, not a new app your biggest supply source onboarded on Tuesday.

This is the only honest answer, because the tempting alternatives are all confounded. Comparing this week to last week measures the change plus everything else that moved, and in RTB everything else always moves. The quantity to compare across arms is revenue per thousand requests received — received from supply, not sent to demand, since the denominator must be the thing shaping cannot touch. If the enforced arm earns the same request RPM as the holdout while sending 40% fewer requests to demand, the shaping is free efficiency. If it earns measurably less, you have found the price of the cut before it swallowed your whole book — which is the experiment working, not failing.

Three practices make the experiment trustworthy rather than theatrical:

1. Shadow before enforce. Run the rule in a mode where it scores every request and records what it would have dropped — while still sending everything. Shadow validates the classifier at zero revenue risk: you read exactly which traffic would disappear and what bids it actually earned. Only a rule that looks right in shadow earns promotion to enforcement.
2. Run full traffic cycles. Bid behavior differs by hour and weekday; an experiment read after two quiet hours has seen one face of the traffic. Hold the comparison open across complete daily cycles, and a weekend boundary, before concluding anything.
3. Keep the holdout alive after the verdict. The temptation is to declare victory and reclaim the holdout’s volume. Resist it. A rule that was profitable at launch decays silently unless a control keeps measuring it — and the holdout is also the only thing feeding data to the segments you suppressed. Its cost — it keeps paying the waste shaping eliminates — is the fee for knowing rather than believing.

What to monitor while shaping is live

Every metric here should be read as a comparison against the holdout arm, per seat — not against last week. That is the point of the control: “bid rate is 12%” is uninterpretable alone, while “12% on the enforced arm against 19% on the holdout” is an alarm with a direction.

The last row deserves the same emphasis it got in the setup guide: a shaping layer without a per-reason drop ledger is unauditable. When a demand partner asks why their request volume halved — and a good partner will ask — “the optimizer did it” is not an answer. “We stopped sending the segments you bid on least; here is the list and your bid rate on each” is one, and it is the difference between shaping reading as discipline and reading as a black box.

Alerting should key on the arm gap, not absolute levels. A bid-rate collapse that hits both arms equally is a demand-side event; a collapse confined to the enforced arm is your shaping doing damage right now — the one that should trip an automatic revert.

The failure modes that cost real money

Three failures account for most of the revenue shaping has ever destroyed, and each has a specific defence.

Shaping into a demand outage. A partner has an incident — a bad deploy, an edge problem, a paused spend line — and their bid rate collapses. A shaping system that reads bids as interest reads the outage as disinterest, learns it, and cuts their traffic. When the partner recovers, they receive a fraction of their former volume, bid on what little arrives, and the reduced bids confirm the reduced sending: the outage has been laminated into your config. The defence is layered. Classify silence — a valid no-bid is a preference, a timeout or 5xx is an incident, and only the former feeds the learning loop. Freeze learning while a seat’s error rate is off its own baseline. And put a breaker on enforcement itself: if a shaped arm’s bid rate falls hard relative to the holdout, revert to shadow automatically. A safety mechanism that needs a human to notice first is a postmortem, not a safety mechanism.

Shaping on stale data. The bid-rate table was computed in March; it is June. Campaigns have ended, budgets have moved, a buyer your model wrote off has onboarded a CTV advertiser who wants exactly the traffic you stopped sending. Stale shaping does not fail loudly — it quietly enforces the past against the present. The defence is the expiry-and-retest discipline from the feedback section, plus the live holdout: if the holdout starts out-earning enforcement, the arm gap is a staleness alarm nobody has to remember to check.

Shaping a seat that was misconfigured, not uninterested. A seat goes silent on all video traffic. The bid-rate table records zero, shaping stops sending video, and the number never moves again. The actual cause: their adapter rejects a field your video requests carry, or a VAST version mismatch — a bug, not a preference. Shaping has institutionalized the bug and removed the evidence anyone would use to find it. The defence is to separate the streams at the source: schema rejections and error responses belong in an integration-health ledger that triggers a conversation with the partner, never in the demand model. A segment that went from bidding to zero overnight is a discontinuity, and discontinuities are integrations breaking — genuine demand fades, it does not step to zero.

The common thread: each failure is the system mistaking a measurement artifact for a fact about demand. The experiment machinery — shadow mode, the holdout, arm-gap alerts, the breaker — is what catches all three, which is why it is the spine of the discipline rather than an afterthought.

Buyers are shaping you too

Everything above has a mirror image running on the other side of your integrations. DSPs receive far more traffic than they can profitably evaluate, from you and every other exchange, and they shape it with exactly the logic described here: score the supply paths, keep the ones that convert evaluation cost into wins, throttle the rest. In the buyer’s vocabulary this is supply path optimization, and being on the wrong end of it looks like slow, unexplained demand decay: bid rates drifting down with no incident, no email, no config change on your side.

Buyers’ shaping keys on things you control. Duplicate paths are the first cut — when the same impression reaches a buyer through your exchange and two resellers of your supply, the buyer keeps the shortest, most transparent path and throttles the rest. Path legibility is the second: ads.txt authorization, a sellers.json entry that identifies you, and a complete, consistent schain on every request are what let a buyer’s SPO logic classify your path as verifiable rather than suspect. Signal quality is the third — requests carrying usable identity and consent are worth more evaluation budget than requests without.

Understanding this changes two things. Diagnostically, it adds the missing hypothesis to every bid-rate investigation: alongside “our shaping broke” and “their demand moved” sits “they started shaping us,” and the tell is decay concentrated on one buyer across many segments rather than one segment across many buyers. Commercially, it reframes the partner conversation: both sides of the table are running the same discipline on each other. The exchange that can show its ledger — what it sends, what it suppresses, why, with holdout-measured proof that shaping raises the partner’s bid rate — is making the argument every buyer’s SPO team wants to hear: this path converts your evaluation budget into wins at a rate you can verify. Shaping done with measurement is not just an infrastructure saving; it is the case for being the path buyers keep.

Shaping is one of the recurring jobs that makes an exchange a staffing commitment rather than a project; the build-versus-buy arithmetic prices that decision against your own numbers.

What kind of machine learning this actually is

Worth being explicit, because “AI” now covers two unrelated things in ad tech and the difference decides what you should believe about a platform.

Everything in this article runs inside the auction, which means inside a budget of two or three hundred milliseconds shared with every demand partner you call. That rules out a language model entirely — not as a matter of taste but of arithmetic, and a platform advertising an LLM in its auction path is describing something that cannot work at auction speed. What fits is statistics: floors and scores learned per segment from that segment’s own observed clearing prices, requests hashed deterministically into arms so the split is stable, a test that knows when a difference between arms is real rather than noise, and an automatic retreat when it is not. Unglamorous, decades old in its foundations, and the only thing fast enough to run thousands of times an hour.

Language models are genuinely useful in an exchange — one layer up, where thinking time is free. Working out why last week’s shaping change coincided with a revenue dip is a research question over log-level data, and cross-referencing five differently-grouped reports is exactly what an assistant handles well. So the division is clean, and it is worth holding any vendor to it: statistics decide, in the auction, in milliseconds; language models explain, afterwards, to you. Anyone blurring those two is either confused or selling.

Key takeaways

Shaping on Floxis

Floxis approaches shaping from both positions this article describes, and they are different products, so it is worth being precise.

If Floxis runs your exchange — the white-label platform, your domain and your margin — shaping is one lever inside the optimization engine, which is built around exactly the experiment discipline argued for above. You set an objective per endpoint — net revenue, fill, or win volume — and the engine blocks, scores and floors every auction toward it. Segment blocking runs in Shadow first, scoring and recording what it would drop while still sending everything; only Enforce actually drops. Every lever moves through Off, then Shadow, then Enforce, measured against a live holdout — arm 0, the exact status quo — so uplift is proven against a concurrent control, not read off a before/after chart. The breaker from the failure-modes section is built in: if a test arm’s bid rate falls below 80% of the holdout’s, Enforce auto-reverts to Shadow on its own. The same machinery drives the rest of the engine — per-segment floors set from each segment’s own observed clearing prices, only ever raising above the minimum you set and never overriding your manual floors, and margins that self-tune within bounds you own. Endpoints are configurable from 1 to 100k+ QPS, reporting lands in about a minute, and every bid, win and drop is written to a log-level ledger with drop reasons — the auditability that turns the partner conversation above into an answer rather than a shrug.

If you already run your own stack and have no intention of replacing it, the same discipline is available as a server-side control layer that operates between your demand integrations and your ad server. There, Floxis handles traffic shaping and routing logic, request volume management, floor enforcement and preferred-supply-path (SPO) control — with controlled experimentation for testing pricing and routing strategies — while auction execution, ad serving and your demand relationships stay exactly where they are, in your stack.

Either way, the pitch is this article’s thesis, not a number: shaping changes ship as experiments with a live control, and you read the revenue answer instead of assuming it. Request a technical walkthrough and we will map the mechanics against the stack you run today.

Sources and standards worth bookmarking

• IAB Tech Lab — OpenRTB
• IAB Tech Lab — ads.txt
• IAB Tech Lab — sellers.json
• Google Authorized Buyers — OpenRTB integration guide
• Prebid Server documentation