FAQs

​

Why do my conversion numbers keep changing after a campaign ends?

Amazon DSP restates conversion data for a period after the activity happens, so a value that looked final can still move on a later sync. Two behaviors drive this. The first is ASIN restatement. If ASINs are added to or removed from a campaign after it starts, Amazon recalculates conversion attribution using the current ASIN set and applies that change retroactively. Restatements can appear in reports for up to 28 days, so older periods may shift from one refresh to the next. The second is Amazon’s own post-refresh adjustments. Invalid-traffic removal can lower counts for up to 72 hours, order cancellations and payment declines are reflected within 72 hours, and reach and frequency figures can be recomputed for up to 96 hours. These are source-side corrections, not a connector error. The full list lives in the Amazon DSP data reference.

​

Why don’t my conversion numbers match a shorter attribution window?

Every Amazon DSP conversion metric uses a fixed 14-day attribution window and carries a 14d suffix. Amazon DSP’s reporting API does not support shorter or longer windows for these metrics, so the window cannot be changed in the widget. This matters most when comparing Amazon DSP against a platform that defaults to a different window. For example, a Meta metric on a 7-day click window counts a narrower set of conversions than an Amazon DSP metric on 14 days, so the two totals will differ even when both are correct. Any gap that traces back to this mismatch is expected. For the full conversion metric list, see the Amazon DSP data reference.

​

Why is the most recent day of data incomplete?

Amazon DSP reports are served cache-only. Dashboard values are composed from the last cached daily snapshot rather than pulled live, so the most recent few hours of activity are not yet reflected. Newly recorded events are not immediate; they appear on the next sync. A partial figure for today or the last few hours is normal and fills in as later snapshots land. For the sync schedule, see Data refresh strategy in the data reference.

​

Why does reach look too high over a long date range?

Reach is a uniqueness metric: it counts distinct users, so the same person seen on two days should be counted once. Because reports are composed from cached daily snapshots, uniqueness cannot always be de-duplicated across days, and reach can be overvalued for any date range longer than a single day. For an accurate reach figure, view it one day at a time rather than summed across a wide range. This behavior applies to any cache-only connector, not only Amazon DSP.

​

Why are ROAS and CTR calculated instead of pulled from Amazon?

Amazon DSP exposes spend and sales but not a native ROAS field, so ROAS — including its new-to-brand and combined variants — is computed downstream from those inputs. CTR is computed the same way, from clicks divided by impressions. Native CTR and ROAS fields, along with advertiserId, advertiserName, date, entityId, intervalEnd, and intervalStart, are left out of the request because including them triggers DSP API errors. The resulting values are correct; they are simply derived rather than reported directly. Which metrics come straight from the API and which are computed is marked in the Amazon DSP data reference.

​

What is the difference between Amazon DSP and Amazon ADSP?

They are two separate data sources with two separate data paths. Amazon DSP reads programmatic performance from Amazon’s DSP Reports v3 API, using the standard advertiser, order, line item, and creative structure. Amazon ADSP reads report data directly from the ADSP reporting UI, and the report type is chosen at connection time. Because the sources pull from different places, their metrics will not always line up exactly, and the two are best used alongside each other rather than treated as interchangeable. To report on the API-based source, connect Amazon DSP; for the reporting-UI source, see Amazon ADSP.

​

Common issues

​

Related