Reconciling DSP and Search in Amazon Marketing Cloud
Reconciling DSP and sponsored ads means querying both channels' pseudonymized exposure and purchase data together inside Amazon Marketing Cloud, identifying shoppers touched by both, and removing the duplicate credit before reporting a combined figure. It's a specific, repeatable query pattern — not a one-off audit — and it's the only way to get an honest combined ROAS.
What this looks like in a real account
Why this needs to be a standing process, not a one-time check
Overlap between DSP and sponsored ads isn't a fixed number — it moves with audience strategy, seasonality, and how aggressively either channel is targeting warm shoppers at a given time. A reconciliation run once at the start of a quarter tells you almost nothing about the current month, particularly around a promotional event when both channels typically scale up spend against overlapping demand. Treating this as a recurring query, run on the same cadence as your standard reporting, is what makes the resulting number trustworthy rather than a snapshot that ages out quickly.
The method, step by step
First, define the purchase set you're measuring — typically a fixed period, like a calendar month, matched to your standard reporting cycle. Second, pull the pseudonymized shopper IDs behind DSP-attributed purchases and sponsored-ads-attributed purchases separately for that period. Third, join the two sets on shopper ID to identify the overlap — purchases where the same pseudonymized shopper appears in both channels' attributed sets. Fourth, apply a decision rule for the overlap: the simplest is to count each overlapping purchase once, credited to whichever channel's touch came first in the shopper's actual path (which requires the timestamp data, not just the shopper ID match). Fifth, report the deduplicated total alongside — not instead of — each channel's own individual number, so the read-out shows both the honest combined figure and each channel's standalone contribution.
A worked example of the deduplication
Say DSP reports 500 attributed purchases and Sponsored Products reports 800 attributed purchases in the same month — 1,300 combined if you simply add them. The AMC join finds 140 shoppers who appear in both attributed sets. Applying the first-touch decision rule, 90 of those 140 purchases get credited to DSP (the DSP touch came first in the path) and 50 get credited to Sponsored Products. The deduplicated combined total is 500 + 800 − 140 = 1,160 purchases — 140 fewer than the naive sum, which is exactly the amount of double-counted credit the two separate dashboards were quietly claiming twice.
What the overlap number itself tells you, beyond the correction
The size and direction of the overlap is planning information in its own right, not just a correction factor. A high overlap where DSP consistently precedes the Sponsored Products touch suggests DSP is functioning as intended — building awareness that search then closes, in which case cutting DSP spend on the strength of its own weaker standalone ROAS would likely damage sponsored ads performance too. A high overlap where the order is reversed, sponsored ads touch first and DSP second, suggests DSP retargeting audiences may be too narrowly built around people already deep in the funnel, doing less genuine incremental work than the spend assumes.
The common mistake, including ours
The mistake is running the reconciliation once, presenting the deduplicated number as if it's now permanently accurate, and not re-running it as the account's audience strategy or seasonality shifts. We built a reconciliation query for a client early in a relationship, reported a clean combined number, and didn't revisit it for two full quarters — by the time we re-ran it around a promotional event, the overlap had roughly doubled as both channels scaled retargeting into the same warm audience pool, and the standing combined-ROAS figure we'd been reporting had quietly drifted out of date without anyone flagging it.
A note on what the 140-purchase gap actually implies for ROAS
Return to the worked example: 140 purchases moved out of a naive combined count of 1,300 sales. If total spend across both channels was $18,000 and the naive combined revenue figure implied a healthy blended ROAS, removing those 140 duplicated purchases — worth real revenue that was being counted twice — lowers the honest combined ROAS by roughly the same proportion as the purchase-count correction, since each duplicated purchase carried its own dollar value into both channels' totals. The point isn't that the account performed worse; it's that the reported number was never as high as it looked, and a budget decision made against the inflated figure was working from the wrong baseline the whole time.
Setting this up so it doesn't go stale again
Build the reconciliation query once, but schedule it to re-run on the same cadence as your standard performance reporting — monthly at minimum, and around any planned promotional event specifically, since that's when overlap tends to move the most. Treat the deduplicated figure, not the naive sum, as the number that goes in front of a client or a budget committee, and note the reconciliation date next to it so anyone reading the report knows how current the correction is.
| Step | What it produces | Why it's needed |
|---|---|---|
| Pull attributed purchases per channel | Two separate shopper-ID sets | The raw material for the join |
| Join on pseudonymized shopper ID | The overlap set | Identifies double-counted purchases |
| Apply a credit decision rule | One credit per overlapping purchase | Removes the duplication |
| Report deduplicated total + individual channel figures | An honest combined read plus channel detail | Prevents both over- and under-crediting either channel |
Which one you should actually pick
Any brand with an analyst who can write AMC queries can build and maintain this reconciliation themselves — the method here is the whole recipe, and nothing about it requires proprietary tooling. reMKTR runs it as a standing, recurring process on managed DSP accounts rather than a one-time audit, because we've seen our own reconciliation go stale before and had to catch it after the fact rather than on schedule, as part of the same practice behind Full Circle's $500M+ in managed Amazon spend across 100+ brands.
Shortlist on the job, not the feature grid. Pull your search-term report for the last 90 days and total the spend against terms that produced no orders — 33.6% on the account above. Then ask each vendor on your list what they would do about it in week one, and see who answers with a process rather than a screenshot.
Common questions
How often should DSP and sponsored ads be reconciled in AMC?
At least monthly, matched to your standard reporting cadence, and specifically around any promotional event, since overlap tends to shift the most when both channels scale into the same demand.
What decision rule should I use for overlapping purchases?
A common, defensible approach is crediting whichever channel's touch came first in the shopper's actual path, using timestamp data from the join — though the specific rule matters less than applying one consistently rather than leaving overlap uncounted.
Does a high DSP-and-search overlap mean I'm wasting money?
Not necessarily — it depends on the order of touches. DSP consistently preceding search suggests the two are working together; search preceding DSP suggests DSP retargeting may be too narrow.
Can I run this reconciliation without an analyst on staff?
It requires someone who can write or adapt an AMC query — free to eligible advertisers, but not a point-and-click report. Many brands lean on an agency or partner specifically for this reason.
We show the method before the number.
Claim the free auditRead next
- Criteo Pricing: The Fee Stack Inside Your BudgetPricing · criteo pricing
- Acorn vs Flywheel vs reMKTR: Scale, Seniority, ProofHead to head · acorn vs
- Pacvue Pricing: No Public Number — What to AskPricing · pacvue pricing
- Skai vs Pacvue: Contracts, Not Feature GridsHead to head · skai vs pacvue