Recovering From Under-Delivery (Without End-of-Flight Dumping)

Every campaign falls behind sometimes. Supply thins out, a daypart underperforms, an exchange has a bad hour, and suddenly delivery is below where it should be. This is normal. What separates a real pacing system from a budget timer is what it does next.

The crude answer is end-of-flight dumping: notice the shortfall late, then spend whatever is left in a frantic burst before the flight closes. It looks like diligence — "we delivered the budget!" — but it is a control failure. It buys whatever inventory is available at any price, ignores quality, spikes CPMs, and concentrates spend exactly when the system has the least ability to spend it well. Hitting the number this way is worse than missing it slightly.

Why dumping happens

Dumping is the natural failure mode of a system that paces by arithmetic. If your mental model is "budget divided by time remaining," then falling behind mechanically inflates the per-unit target: less time left, same budget, so the implied spend rate climbs. Follow that formula to the end and it tells you to spend furiously in the final window — regardless of whether the supply is any good. The math doesn't know the difference between "catch up sensibly" and "panic."

A pacing controller, by contrast, treats delivery as something to regulate, not a quota to force. It can fall behind and recover without ever entering panic mode, because recovery is governed by the same machinery as normal operation.

What disciplined recovery looks like

Consider the hard case from the controller's own simulations: the first ~30 minutes of an hour deliver poorly — very low match and impression rates — and both pacing modes fall well below the expected delivery line. The test is whether the system can recover once conditions improve.

It does. As supply returns, participation ramps and cumulative delivery catches up to the goal by the end of the hour. Crucially, the catch-up is regulated by the same probabilistic gating that governs normal operation — not a reckless "spend whatever is left" dump. The system recovers; it does not panic.

The shape of that recovery curve is the whole point. A dumping system produces a flat line followed by a vertical spike. A controlled system produces a dip followed by a smooth ramp back to the expected curve. Same destination; completely different risk profile.

The mechanism behind graceful recovery

Recovery is not magic; it is specific machinery doing its job under stress:

• Base-floor gating under under-delivery. When a line item is behind, participation is gated against a base floor rather than allowed to explode — recovery is bounded, not unbounded.
• Probabilistic participation. The controller raises the probability of joining auctions to catch up, but it remains a probability, smoothly adjusted, not a switch flipped to "buy everything."
• Pacing memory. Smoothed estimates of submission rate, acceptance probability, and QPS are carried across calls with exponential (ALPHA-weighted) smoothing, so the controller adapts to the improving conditions without overreacting to noise.

Together these mean the system leans in as supply returns rather than lunging at the finish line. The catch-up is aggressive enough to recover and disciplined enough to stay sane.

When recovery shouldn't happen

The honest counterpart: sometimes a campaign falls behind because the supply genuinely is not there, and no amount of ramping will conjure inventory that does not exist. A disciplined controller distinguishes these cases. Under genuine, persistent scarcity it does not try to force delivery — it holds a minimal presence (the trickle floor), reports the shortfall honestly, and stays ready for supply to return. Knowing when not to recover aggressively is as important as knowing how to recover. Forcing spend into a market with nothing to sell is just dumping with extra steps.

Common misconceptions

• "Hitting the budget always means success." Hitting it via an end-of-flight dump can be worse than a small, clean shortfall.
• "Falling behind requires aggressive correction." It requires regulated correction; aggression without bounds is the failure mode.
• "Recovery and dumping are the same thing done at different times." Recovery is a smooth, gated ramp; dumping is an ungoverned terminal burst.
• "If the system is behind, raise the bids." Often the issue is supply, not price; a controller ramps participation within bounds and surfaces genuine scarcity.

What good operation looks like

• Read delivery against the expected curve, and treat a dip-then-ramp as healthy.
• Distrust a terminal spike — it signals dumping, not recovery.
• Let the controller gate recovery against a base floor; don't override it into a buy-everything mode.
• Treat persistent under-delivery as a supply signal — investigate inventory and targeting before forcing spend.

Open questions

• How should recovery aggressiveness be tuned to inventory quality, not just the shortfall size?
• Can the system predict impending under-delivery early enough to recover gently rather than steeply?
• What delivery guarantees can be offered jointly with outcome goals, so recovery protects performance, not just volume?

A budget timer panics at the end of a flight because arithmetic told it to. A pacing controller falls behind, then climbs steadily back, governed throughout by the same rules that keep it sane on a normal day. The difference shows up in the curve: a smooth ramp instead of a terminal spike. Delivering the budget is not the achievement. Delivering it without ever losing control is.