Olga Zharuk
Grigoriy MisilyukProgrammatic advertising generates enormous bid request volume. In fact, eMarketer reveals that private marketplaces (PMP) spending has grown nearly 13% in 2025, while open exchange spending has grown approximately 3%. The numbers could grow far less sufficiently if bidding strategies were optimized and businesses took steps to prevent bid request floods.
The bid request flood makes SSP throttling and bid throttling not just useful optimizations, but operational necessities for any platform managing supply at scale. In this article, we take a deeper look at the Smart Throttling feature, why the same term can hide fundamentally different algorithms, and how various models affect SSP revenue and costs. We also cover the latest Smart Throttling update for owners of the TeqBlaze ML-driven white-label SSP + Ad Exchange.
Key points
Smart Throttling is a core component of supply-path optimization (SPO) — it reduces redundant bid requests at the source, cutting infrastructure costs and improving auction quality without sacrificing fill rate.
SSP throttling and bid throttling are not one-size-fits-all: optimization logic varies significantly by platform, ranging from legacy linear models to modern ML-driven systems with self-updating algorithms.
Dynamic models consistently outperform static ones in volatile traffic conditions.
TeqBlaze white-label SSP + Ad Exchange users can now leverage Smart Throttling programmatic approach based on real CPM (RCPM) metrics. This enables simultaneous revenue maximization and cost reduction across DSP connections, with expanded A/B testing and advanced reporting built in.
Smart Throttling as a component of the supply-path optimization (SPO) process
We have already covered the topic of supply-path optimization (SPO) and demand-path optimization (DPO) deeply in one of our previous articles on the Medium blog called: SPO and DPO. The main idea of the article is to show that SPO and DPO are essential elements in the development of a programmatic ecosystem. These two processes are closely related and benefit both the demand and supply sides.
Smart Throttling is SPO's execution layer — filtering bid requests at source to reduce redundancy and maximize impression value. Without it, even a well-designed supply path wastes resources on low-win-probability auctions. It proves to be an essential part of a supply path optimization SSP workflow.are closely related and benefit both the demand and supply sides.
What is Smart Throttling?
Imagine how many bids one supply platform sends each day — millions of bid requests every second — and how many of them are irrelevant due to technical issues. The Smart Throttling programmatic approach uses data-driven algorithms to restrict bidding with non-responding demand-side partners. Unlike DSP-side bid throttling — which filters incoming requests on the demand side — SSP throttling acts earlier, preventing low-value traffic from entering the auction at all. In a smart throttling SSP setup, this logic runs at the platform level before any request reaches a DSP.
This process solves two fundamental issues.
Minimizing expenses by reducing the number of irrelevant bid requests.
Maximizing revenue by prioritizing successful ad bids with good campaign performance.
The Smart Throttling optimization process is unique for each specific advertising platform, being more or less effective depending on the model developed. Various optimization models are based on different metrics and formulas. That's why each specific Smart Throttling model should be tested before scaling over all traffic volumes.
Notably, Smart Throttling also reduces carbon footprint: since SSPs process billions of bid requests monthly, filtering irrelevant ones at source meaningfully cuts unnecessary server load across the programmatic chain.
Throttling Type | Who Controls | Goal | Method |
SSP-side throttling | SSP / supply platform | Reduce outbound request volume; protect DSP relationships | Bid request optimization based on filtering and scoring |
DSP-side throttling | DSP / demand platform | Limit inbound request processing to manageable and winnable volume | Accept or reject incoming requests based on win-rate history and budget pacing |
Bid throttling (demand) | DSP bidder | Avoid overbidding on low-value impressions | Suppress or reduce bids on traffic segments with poor historical performance |
Smart Throttling (ML-driven) | SSP with ML layer | Dynamically optimize request flow based on real-time signals | Self-updating algorithms score and prioritize requests by predicted win probability and CPM |
Static vs. dynamic throttling models: what's the difference?
Legacy linear Smart Throttling models optimize bidding according to a fixed algorithm. Common examples include:
Strict limitation of bid requests to DSPs that have not responded with relevant bids within the last hours.
Substantial or complete restriction of bid requests to DSPs whose bid responses rarely win at real-time auctions.
Lowest priority assigned to DSPs that win auctions but whose impressions fail due to technical issues — timeouts, connection errors, or fraudulent ad redirects.
The core limitation: once restrictions are applied, they stay permanent. A DSP that adjusts its settings and starts performing well remains throttled regardless. Static models do not revise applied restrictions dynamically.
Parameter | Static Scripted Model | Dynamic ML Model |
Restriction logic | Fixed rules, manually defined | Self-updating based on real-time signals |
Adaptability | None — restrictions are permanent | Continuous — adjusts as DSP behavior changes |
Optimization basis | Predefined thresholds | Live performance data and predicted win probability |
Risk | Over-throttling recovering DSPs | Requires sufficient data volume to perform accurately |
Best for | Simple, low-traffic platforms | High-volume SSPs with diverse DSP pools |
Dynamic machine learning model
Dynamic Smart Throttling models are an evolutionary extension of linear optimization. SSP platforms’ developers use different metrics for optimization and apply various restrictions to reduce the expenses on bidding and increase profits. At the same time, all dynamic models are united by the process of collecting feedback: any restriction is not applied permanently, and there is a constant review of trends — the platform tests different approaches for optimization based on updated data.
Dynamic Smart Throttling models use Big Data and Machine Learning technologies to achieve better optimization. For instance, ML-based bid throttling improves results and reduces the level of manual control over the bidding process. By leveraging machine learning for ads, platforms can refine throttling algorithms dynamically, ensuring bid request optimization and higher overall ad performance. This continuous self-learning approach helps SSPs maintain a competitive edge while minimizing wasted impressions.
To measure the efficiency of machine learning bid optimization through throttling, track CPM (RCPM). It is the gross revenue earned by the SSP per thousand impressions.
Advantages of Smart Throttling by TeqBlaze
Next, we will look at the Smart Throttling SSP bidding optimization process designed by TeqBlaze software developers and available to owners of white-label SSP out of the box.
Smart Throttling based on real CPM (RCPM)
As has already been mentioned, CPM (RCPM) is the metric we use to optimize bidding within the Smart Throttling process.
While bidding can technically be optimized across various metrics — keys, impressions, requests, winning bid rate, and others — real CPM SSP optimization has the strongest direct impact on platform revenue, which is why TeqBlaze chose it as the primary signal.
RCPM calculates the real price per thousand impressions relative to all requests made to display a specific ad. It is always lower than nominal CPM because some impressions never materialize due to technical, security, or other issues — and those failed requests still consume resources. By making real CPM the optimization target, the Smart Throttling process filters out traffic that inflates request volume without contributing to actual earnings.
Metric | What It Measures | Why It Matters for SSP |
RCPM (Real CPM) | Revenue per thousand impressions after excluding failed requests | Most accurate reflection of true platform earnings; core signal for RCPM optimization |
Nominal CPM | Theoretical price per thousand impressions before accounting for failures | Useful for pricing benchmarks but overstates actual revenue |
Win rate | Percentage of bid requests that result in a winning bid | Indicates DSP competitiveness but doesn't capture impression delivery quality |
Fill rate | Percentage of ad requests filled with an ad | Measures inventory utilization but ignores revenue quality of filled impressions |
Bid request volume | Total outbound requests sent to DSPs | Tracks infrastructure load; high volume without RCPM growth signals inefficiency |
Dynamic optimization with per-hour updates
The TeqBlaze white-label SSP + Ad Exchange uses machine learning bid optimization with programmatic throttling that self-updates without manual intervention. The core logic:
If there are many requests and low impressions → the platform drops 80% of such traffic to that DSP for the next hour.
Every hour, the system rechecks each restriction against current performance data and adjusts automatically — a DSP that recovers will regain traffic share in the next cycle without any action required from the platform owner.
Optimization Cycle | Stage Trigger Condition | Action Taken | Result |
Detection | High request volume, low impression rate | Flag DSP as underperforming | Inefficient traffic identified |
Restriction | Confirmed low RCPM from DSP | Drop 80% of requests to that DSP | Infrastructure load reduced |
Recheck | 1-hour interval elapses | Re-evaluate DSP performance against current data | Restriction updated or lifted |
Recovery | DSP performance improves | Traffic share gradually restored | Revenue opportunity recovered |
A/B testing for Smart Throttling and other features to fine-tune performance
We are updating A/B testing capabilities so users can test Smart Throttling and other features before scaling them across all traffic volumes. Separate reporting on traffic with different settings means SSP owners can directly compare revenue, RCPM, and infrastructure load between variants — making scaling decisions based on real performance data rather than assumptions.
For example, a platform owner can route 20% of traffic through RCPM-based Smart Throttling while the remaining 80% runs on a legacy model, then compare results side-by-side before committing to a full rollout.
The A/B testing feature reduces reliance on the technical team by letting users enable options via toggles — such as RCPM optimization for bidding or Dynamic Margin for publisher payouts. More enhancements are coming in platform version 2.5.
Unlimited features customization
It’s always the option to contact your account manager for help anytime you have customization requests. We also have two special presents for platform newcomers:
Guide on advanced analysis of SSP + Ad Exchange performance.
Document on how to get the full potential of your SSP + Ad Exchange.
We wish you inspiration to continue developing the platform logic! Our engineering team can step in at any stage and customize the platform to your updated needs, provide advice on how to increase efficiency, and much more. We are motivated to improve the platform as much as you are.
SSP throttling best practices
Effective programmatic throttling requires more than switching on an algorithm — here are six practices that make the difference between optimization and over-restriction.
Start with 10–20% of traffic. Test throttling on a small traffic share before scaling. This limits risk and gives the algorithm enough data to calibrate without affecting overall platform revenue.
Use RCPM as your primary metric. Win rate and bid rate don't reflect actual earnings. RCPM captures what the platform genuinely makes per thousand impressions after failed requests are excluded.
Set per-hour or per-day rechecking — not static blocks. Third-party or white-label DSP performance changes. Fixed restrictions penalize partners that have already recovered, reducing revenue opportunities unnecessarily.
Integrate throttling with fraud detection. Throttling and traffic quality work on the same problem from different angles — running them independently creates blind spots and wastes infrastructure on non-human traffic. Incorporating inventory quality scoring into the throttling logic adds another filter layer of safety.
Monitor QPS optimization per DSP before and after throttling. Queries-per-second data reveals whether restrictions are reducing load as intended or creating unexpected bottlenecks elsewhere in the supply path. These, in turn, require additional effort for establishing supply path optimization SSP workflows.
Document changes with A/B tests. Side-by-side reporting on throttled vs. unthrottled traffic segments makes it possible to validate decisions with data before committing to a full rollout.
Best Practice | Benefit | Complexity | Best For |
Start with 10–20% traffic share | Reduces risk; allows safe calibration before scaling | Low | Platforms implementing throttling for the first time |
Use RCPM as primary metric | Ties optimization directly to revenue rather than proxy metrics | Low | Any SSP prioritizing financial outcomes over volume |
Per-hour or per-day rechecking | Prevents over-throttling recovering DSPs; keeps restrictions current | Medium | High-volume SSPs with dynamic, frequently changing DSP pools |
Integrate with fraud detection | Eliminates non-human traffic before it consumes bid request budget | Medium | Open-exchange platforms with diverse, unverified supply sources |
Monitor QPS per DSP | Identifies bottlenecks and validates that restrictions reduce load as intended | Medium | Platform engineers and ops teams managing infrastructure costs |
Document changes via A/B tests | Enables data-driven scaling decisions with clear before/after comparisons | Low | SSP owners evaluating new throttling models or parameter changes |
Consider TeqBlaze as your trusted partner
TeqBlaze clients running the white-label SSP + white-label Ad Exchange have direct access to ML-based Smart Throttling built into the platform infrastructure. No third-party integrations, no manual scripting. Only pure SSP and tailored Ad Exchange efficiency. One SSP owner reduced infrastructure load and improved RCPM within the first month by enabling RCPM-based throttling on 20% of traffic, validating results via A/B testing, and scaling gradually across all DSP connections.
If you are building or scaling a custom adtech platform, Smart Throttling is one of the highest-leverage optimizations available. Contact the TeqBlaze team to see how the platform performs on your traffic — and what RCPM gains are realistic for your setup, either web or mobile.
Final words
Smart Throttling in programmatic advertising is a great feature for optimizing the outbound traffic of your SSP. To leverage it, you will need a tailored solution that can be configured according to your traffic patterns and specifics. White-label SSP platform and White-label Ad Exchange from TeqBlaze provide you with such an opportunity. Contact us if you are interested in a solution with a pre-built core and rich possibilities for throttling and branding customization!
FAQ
What is SSP throttling?
SSP throttling is the process of controlling which bid requests an SSP sends to demand partners. Rather than forwarding every available impression, the SSP filters and prioritizes outbound requests based on performance
signals — reducing infrastructure costs and improving auction quality without sacrificing revenue.
What is smart throttling in programmatic advertising?
Smart Throttling uses data-driven algorithms to restrict bidding with underperforming DSPs. Unlike static rules, smart throttling models — especially ML-based ones — self-update based on real-time signals, continuously adjusting restrictions to reflect current DSP behavior rather than fixed historical thresholds.
What is bid throttling, and how does it work for SSPs?
Bid throttling limits the volume or frequency of bid requests sent to specific demand partners. For SSPs, it works by:
Scoring each DSP by performance metrics such as win rate optimization results or RCPM
Reducing or suppressing requests to low-scoring partners
Reallocating that request volume toward higher-performing demand sources
Header bidding optimization through filtering out redundant requests before they reach the demand side, reducing auction duplication and infrastructure load
How does ML-based throttling differ from static throttling models?
Static models apply fixed restrictions that stay permanent regardless of how DSP performance changes. ML-based throttling rechecks and updates restrictions automatically — typically per hour — meaning a DSP that recovers regains traffic share without manual intervention. Dynamic models consistently outperform static ones in volatile traffic conditions.
What is RC,PM and why is it used for smart throttling?
RCPM (Real CPM) measures actual revenue per thousand impressions after excluding failed requests. It is lower than nominal CPM because technical issues, timeouts, and fraud prevent some impressions from delivering. RCPM is preferred for throttling optimization because it directly reflects platform earnings rather than proxy metrics like DSP bid rate or fill rate.
How can SSP owners implement smart throttling?
Key steps for implementation:
Start with 10–20% of traffic to calibrate the algorithm safely
Set RCPM as the primary optimization metric
Configure per-hour or per-day restriction rechecking — avoid static blocks
Integrate with fraud detection to address traffic quality simultaneously
Use A/B testing to validate results before scaling across all DSP connections
