Pacing in Amazon DSP is how an order's actual spend tracks against what it should have spent by now: pace % is actual spend to date divided by expected spend, and expected spend is the budget divided by flight days, times days elapsed. It is the discipline that separates a DSP operation that hits its numbers from one that explains itself at the end of the month, and it is strangely underdocumented: Amazon's own material covers the console alerts and little else. This guide covers the full practice: the math, the diagnosis, the daily workflow, and the client report.
It is written for the people newly running Amazon DSP self-service. There are a lot of you: Amazon removed the DSP self-service minimum spend at unBoxed in November 2025, practical entry budgets dropped to around $5-10k per month (Marketplace Ad Pros), and DSP has grown from under 10% to roughly 20% of global programmatic spend in about 15 months (ppc.land). Amazon has since folded the DSP into Amazon Ads Agent: in the US, programmatic campaigns now run as DVA+, while advertisers in most other markets still see the DSP console. The pacing math is the same in both. Most of the tooling assumes you have either an Amazon account team or a $3-5k per month enterprise platform. This guide assumes you have neither.
What is pacing in Amazon DSP?
Pacing is how an order's actual spend tracks against what it should have delivered by this point in its flight. An order pacing at 100% has spent exactly the share of budget that matches the share of flight elapsed. Below 100% is underdelivery: you risk leaving budget unspent at the flight end. Meaningfully above 100% means the budget exhausts early and the campaign goes dark before the flight ends.
Both directions are failures from a client's point of view. Underdelivery means impressions they paid to plan around never ran. Overdelivery-then-dark means the last week of a product launch had no media behind it.
The flight math
The standard assumption is even delivery across the flight. Three numbers define everything:
expected spend = (total budget / flight days) x days elapsed
pace % = (actual spend to date / expected spend) x 100
projected final spend = (actual spend to date / days elapsed) x flight days
A worked example. An order has a $30,000 budget on a 30-day flight, and it is the end of day 12:
- Expected spend: ($30,000 / 30) x 12 = $12,000
- Actual spend to date: $9,600
- Pace: $9,600 / $12,000 = 80%
- Projected final spend at this run rate: $24,000, leaving $6,000 undelivered
The useful reading of 80% is not "we are 20% behind." It is "at this rate the flight ends $6,000 short, and every day we wait, the daily spend needed to catch up rises." On day 12 the catch-up rate is $1,133 per day against an original plan of $1,000. By day 20 it is $1,440. Pacing problems compound quietly, which is why they are caught early or not at all.
Two refinements worth knowing:
- Custom delivery curves. Some orders intentionally front-load or back-load (a launch spike, a holiday ramp). Then expected spend follows the planned curve, not a straight line. If you did not explicitly plan a curve, use even delivery.
- Blended CPM as the companion metric. Spend pace alone can hide a delivery problem. If pace is 100% but blended CPM (total spend / total impressions x 1,000) has drifted well above plan, you are buying fewer impressions than the client expects at full budget. Track both.
Why is my DSP order underdelivering?
Underdelivery has a short list of causes. Diagnose in this order, because the earlier items are both more common and faster to fix:
- Bids below the winning range. The most common cause. Your bid clears too few auctions for the inventory you are targeting. Raise the bid or loosen the supply constraint before touching anything else.
- Audience too narrow. Layered targeting (audience x geo x device x deal) multiplies down fast. Check the scale estimate against your daily budget.
- Frequency caps set too tight. A cap that made sense at planning can strangle delivery once the reachable audience is smaller than estimated.
- Creative approvals and rejections. A creative stuck in review or rejected mid-flight silently removes line items from delivery. Days lost to approval do not come back; the remaining flight has to absorb the budget.
- Supply constraints on specific deals. A PMP deal or narrow inventory type (a specific Fire TV placement, a single publisher deal) may simply not have the volume.
The reverse problem, pacing far over 100%, is usually a bid well above the winning range or an audience much larger than planned, and it deserves the same-day attention underdelivery gets: budget that exhausts on day 22 of a 30-day flight is a client conversation nobody enjoys.
What should you do when an order underdelivers in the first days?
Act on day 3, not day 10. Take a 14-day order with a $14,000 budget and even pacing: by the end of day 3 it should have spent $3,000. If it has spent $1,800, it is pacing at 60%, and the remaining 11 days now need $1,109 a day against a plan of $1,000. Wait until day 7 at the same run rate and the remaining 7 days need $1,400 a day, which few line items can absorb without overpaying for the extra delivery.
Raising the maximum average CPM and widening the audience are the right first moves when the diagnosis points to the two most common causes above: bids below the winning range and an audience too narrow. Make one change at a time, give it a day, and check pace again. If delivery does not respond, work down the rest of the list: frequency caps, creative approvals, then supply.
Should you split line items by device or supply source?
Split where the inventory behaves differently; combine where it does not. Streaming TV, mobile, desktop display and individual deals clear at very different prices, so one line item with one bid either overpays for cheap supply or loses the expensive auctions, and its pacing hides which part is failing. Separate line items give each its own bid, budget and frequency cap, and make pacing and supply reports readable.
The cost is fragmentation. Many small line items each have less budget and data to learn from, and each one can underdeliver on its own. A practical rule: split inventory that has a materially different price or goal, and keep together line items that share both.
How do you catch overspend on weak inventory before the flight ends?
Break spend down by supply source every week, not at the end of the flight. A line item can pace at exactly 100% while most of its money goes to inventory that delivers impressions and little else. For each source, compare its share of spend with its CPM and the outcome the line item is bought for (clicks, detail page views, purchases). A source taking a growing share of spend at a worse cost per outcome is the one to cap or exclude while there is still budget left to move.
Amazon's Performance+ reporting includes domain delivery, "to see which websites are showing your ads and which ones work best." Across many advertisers, a supplier view that shows spend, impressions, CTR, CPM and share of spend by supplier for every client, like Peachblue's, turns the weekly check into one table.
The daily workflow (and why it breaks at agency scale)
For a single order, pacing hygiene is simple: check pace % daily, react when it drifts outside roughly 90-110%, and diagnose against the list above. Amazon has made the single-order case easier: the console now shows in-line pacing alerts with one-click fixes for underpacing orders (Amazon Ads release notes).
The practice breaks at portfolio scale, and DSP reporting makes it worse in two specific ways:
- The console is per-advertiser. An agency with 15 client seats checks 15 consoles. There is no cross-client view of every active flight, and the common agency staffing pattern, 30 to 50 accounts per strategist with roughly 30 minutes of senior attention per account per week (SellerApp), does not leave room for 15 daily console tours.
- Reporting is export-shaped. DSP reporting lives in downloads and a Reports API with real constraints (Amazon's own attribution rules, 31-day requests and 95 days of history on the older v3 reports). Most teams end up in a spreadsheet ritual: download, paste, rebuild formulas, repeat per client.
The fix at scale is a portfolio pacing view: every active order across every client in one table, sorted by risk, checked once a day in minutes. That is the shape of the Reports and Pacing product in Peachblue: per-order budget, spend to date, pace %, blended CPM, and CPM goals across all clients, with agency margin applied where it should be. But the principle matters more than the tool: if your pacing check takes longer than your coffee, you will stop doing it daily, and daily is the whole game.
Reporting pacing to clients
A pacing report answers three client questions: are we on plan, if not why, and what are you doing about it. The columns that answer them:
| Column | What it answers |
|---|---|
| Order / flight dates | What is running and when it ends |
| Budget | What was committed |
| Spend to date | What has delivered |
| Expected spend to date | What should have delivered by today |
| Pace % | On plan or not, in one number |
| Blended CPM vs plan | Whether full delivery still buys the planned impressions |
| Status + action | Your diagnosis and fix, in one line |
Copy that structure into a sheet and you have a serviceable manual pacing report; the formulas are the three lines of flight math above. Send it weekly as a table, not a dashboard link, and lead with the exceptions: clients read the two orders that are off-plan, not the twelve that are fine.
Two reporting habits that build trust: report pace against the original budget even when you have applied an agency margin (margin belongs on spend and spend-derived metrics, not on delivery math), and when a flight is off-plan, state the cause from the diagnosis list rather than a generic "optimizing delivery." Clients forgive underdelivery caught on day 8 with a named cause and a fix. They do not forgive discovering it on day 28.
Where this is heading
Amazon is clearly investing in single-account pacing hygiene: console alerts, one-click fixes, and Amazon Ads Agent, which the DSP has now evolved into, with conversational recommendations in closed beta that summarize proposed changes for your approval before they apply. Legacy reporting retires at the end of 2026, and existing Amazon DSP certifications remain valid, Amazon says, with the course now named Amazon Ads Programmatic Solutions. Expect the basics to keep commoditizing. What Amazon has shown no interest in building is the agency layer: cross-client portfolio views, margin handling, and client-ready reporting. That layer is where pacing practice actually lives for anyone running more than one advertiser, and it is where we have focused Peachblue's DSP tooling.
If you run DSP for clients and want the portfolio version of everything above, Peachblue's Reports and Pacing ships it today, alongside AI creative analysis across Meta, TikTok, Google Ads, and Amazon DSP. And if you are migrating off another analytics tool entirely, start with our guide to the post-MagicBrief landscape.