Amazon Marketing Cloud (AMC), Explained

Amazon Marketing Cloud (AMC) is a clean-room environment where advertisers can query pseudonymized, event-level signals across Amazon DSP, Sponsored Ads, and (where connected) their own first-party data using SQL. Unlike Seller Central or the Ads console, which show you pre-aggregated performance metrics, AMC lets you work against the underlying event trail: impressions, clicks, conversions, and audience overlaps, without exposing individually identifiable customer data.

Below: what AMC unlocks, how it is set up, what the data looks like, the privacy rules that quietly change your results, and how we run it in production.

What AMC unlocks that standard reporting can't

Cross-channel attribution: seeing how Sponsored Products, Sponsored Display, and DSP campaigns interact along the same customer path
Audience overlap analysis: understanding how many customers were reached by multiple campaign types before converting
Path-to-conversion modeling: looking beyond last-touch, standard reporting's biggest blind spot
Custom audience building: based on precise combinations of ad exposure and purchase behavior
Frequency and reach analysis: at a level of granularity Amazon's dashboards simply don't expose

The catch: AMC is a query engine, not a dashboard

AMC doesn't hand you insights. It hands you a SQL interface to large, well-governed datasets. Getting value out of it requires writing (and maintaining) SQL against Amazon's specific schema, scheduling queries within API limits, and piping results into a BI layer your team can actually read. Without that engineering layer, AMC access sits unused, which is exactly what happens at most agencies that provision it and never operationalize it.

This is the gap we closed for Tinuiti: integrating AMC alongside their existing multi-marketplace ETL pipeline so that audience insight from AMC feeds directly into the same BI framework used for day-to-day reporting, instead of living in a separate, rarely-opened tool.

How AMC is set up

Instances are per advertiser and per region

An AMC instance is provisioned for a specific advertiser (or an agency acting for that advertiser) in a specific Amazon Ads region: North America, Europe, or Far East. Each instance only sees the Sponsored Ads and DSP activity for the accounts linked to it in that region.

Data does not cross regions. A brand selling in the US, UK, and Japan will typically have three separate instances, and a query in the EU instance knows nothing about US shoppers. If you want a global view, you run the same query in each instance and combine the aggregated outputs afterwards, in your own warehouse. For a UK agency with European and US clients, this matters on day one: every workflow, schedule, and dashboard needs a region dimension.

Console vs API

There are two ways in:

The AMC console in the Amazon Ads UI. Good for exploring the schema, testing a query, and running Amazon's instructional query templates. Fine for analysts, not for anything recurring.
The AMC API, part of the Amazon Ads API. This is what production pipelines use. The core concepts are workflows (a saved, named SQL query, optionally with parameters) and executions (a single run of a workflow over a specific time window). You can create and update workflows, trigger executions on demand or on a schedule, poll their status, and retrieve the results.

What you get back is the aggregated output of your query, not raw event data. Historically, results are delivered as files to an Amazon S3 bucket you own and connect to the instance; depending on API version, results may also be available via a download link. The delivery options have evolved over time, so check Amazon's current AMC API documentation before designing around one.

The practical consequence: AMC is a remote compute environment you send SQL to. Your warehouse never holds AMC event data, only the result sets your queries produce.

What the data looks like

AMC exposes a set of tables, each describing one kind of event. The ones most teams start with:

dsp_impressions: one row per DSP impression event, with campaign, line item, creative, device, and supply details
sponsored_ads_traffic: impressions and clicks from Sponsored Products, Sponsored Brands, and Sponsored Display, with campaign, ad product type, and (for search) targeting and search term fields
amazon_attributed_events_by_conversion_time: conversions attributed to your ads, dated by when the conversion happened
amazon_attributed_events_by_traffic_time: the same attributed conversions, dated by when the ad impression or click happened
conversions: conversion events (such as purchases, detail page views, and add-to-carts) regardless of whether an ad gets credit, useful for building your own attribution logic

The two attributed-events tables answer different questions. "What did we sell this week because of ads?" uses conversion time. "What did last week's campaigns eventually drive?" uses traffic time. Mixing them up is one of the most common sources of numbers that don't reconcile.

Event-level rows are keyed by a pseudonymous user_id, which lets you join a shopper's ad exposures to their conversions inside the clean room. You can never select that identifier out. Only aggregated outputs leave AMC, and they have to pass Amazon's privacy checks first.

Amazon adds tables and columns over time, and some datasets are paid add-ons, so treat the schema browser in your instance as the source of truth.

Privacy rules that break queries

AMC's privacy controls are the main reason a query that "looks right" returns surprising results. Three matter most.

Aggregation thresholds

Every output row must represent a minimum number of distinct users. Rows below the threshold are filtered out of the result (Amazon documents the current threshold and filtering behavior, so check it rather than hard-coding a number from a blog post). The important part is that this happens silently: you don't get an error, you get fewer rows.

This means a missing campaign in your output does not mean zero activity. It may mean too few users. Narrow cuts such as campaign by day by device by audience segment are the usual culprits. The fix is usually to widen a dimension (weekly instead of daily, campaign group instead of campaign) or lengthen the time window.

Attribution data keeps updating

Attributed conversions can continue to arrive for some days after the ad event, because a purchase that happens next week can still be credited to today's click. A result for a recent window is therefore provisional. If you run rolling look-back windows (say, the last 14 or 28 days), re-run them on a schedule and overwrite earlier results rather than appending once and treating the numbers as final.

Data latency

AMC data typically lands with a lag of around a day, sometimes more. A daily workflow that queries "yesterday" first thing in the morning can return thin or partial results. We schedule executions with a buffer and check Amazon's current docs for latency guidance in each region.

There are also query-level restrictions: you cannot output user_id or other identifiers, some functions are not supported, and the date range normally comes from the execution's time window rather than a WHERE clause on dates.

A worked example: Sponsored Ads and DSP reach overlap

A question we answer for almost every brand running both channels: how many shoppers were reached by Sponsored Ads only, DSP only, or both, and how does the purchase rate differ between those groups?

-- Reach overlap between Sponsored Ads and DSP, with purchase rate per group.
-- The date range is set by the execution's time window, not in the SQL.
-- Column names follow the AMC schema; confirm them in your instance's schema browser.

WITH sa_users AS (
  -- Every user who saw at least one Sponsored Ads impression in the window
  SELECT user_id
  FROM sponsored_ads_traffic
  WHERE impressions > 0
    AND user_id IS NOT NULL
  GROUP BY user_id
),

dsp_users AS (
  -- Every user who saw at least one DSP impression in the window
  SELECT user_id
  FROM dsp_impressions
  WHERE user_id IS NOT NULL
  GROUP BY user_id
),

reached AS (
  -- Label each user by which channel(s) reached them
  SELECT
    COALESCE(s.user_id, d.user_id) AS user_id,
    CASE
      WHEN s.user_id IS NOT NULL AND d.user_id IS NOT NULL THEN 'both'
      WHEN s.user_id IS NOT NULL THEN 'sponsored_ads_only'
      ELSE 'dsp_only'
    END AS exposure_group
  FROM sa_users s
  FULL OUTER JOIN dsp_users d
    ON s.user_id = d.user_id
),

purchasers AS (
  -- Attributed purchases per user, tied back to when the ad traffic happened.
  -- This is a "what did each reached group go on to do" question, so traffic time
  -- is the right table: the cohort is defined by exposure, not by purchase date.
  SELECT
    user_id,
    SUM(purchases) AS purchases
  FROM amazon_attributed_events_by_traffic_time
  WHERE user_id IS NOT NULL
  GROUP BY user_id
)

-- Final output: aggregated by exposure group only. No user_id leaves the clean room.
SELECT
  r.exposure_group,
  COUNT(DISTINCT r.user_id) AS users_reached,
  COUNT(DISTINCT CASE WHEN p.purchases > 0 THEN r.user_id END) AS users_purchased,
  SUM(COALESCE(p.purchases, 0)) AS attributed_purchases
FROM reached r
LEFT JOIN purchasers p
  ON r.user_id = p.user_id
GROUP BY r.exposure_group

A few notes on reading the output:

With only three groups, this query usually clears the aggregation threshold. Add a campaign or daily dimension and some rows may disappear. That is the threshold, not a bug.
users_purchased / users_reached gives a purchase rate per group. The "both" group almost always converts best, but it is also self-selected (shoppers who see both are often further down the funnel), so treat the gap as directional, not causal.
Attributed purchases here come from Amazon's attribution model. For your own model, swap in the conversions table and define the rules yourself.

Landing the results in your warehouse

Once results arrive in your S3 bucket, a loader moves them into the warehouse (BigQuery Data Transfer Service, Snowpipe, or an orchestrated job). We add metadata at load time (brand, region, workflow, execution ID, time window) because the result file alone doesn't tell you which run it came from. A dbt staging model then cleans it up:

-- models/staging/amc/stg_amc__exposure_overlap.sql
-- One row per brand, region, execution window, and exposure group.

with source as (

    select * from {{ source('amc_exports', 'exposure_overlap') }}

),

renamed as (

    select
        brand_id,
        amc_region,                                   -- 'NA', 'EU', or 'FE'
        execution_id,
        cast(time_window_start as date)               as window_start,
        cast(time_window_end as date)                 as window_end,
        exposure_group,
        cast(users_reached as {{ dbt.type_int() }})   as users_reached,
        cast(users_purchased as {{ dbt.type_int() }}) as users_purchased,
        cast(attributed_purchases as {{ dbt.type_int() }}) as attributed_purchases,
        _loaded_at
    from source

)

select * from renamed

dbt.type_int() keeps the model portable between BigQuery and Snowflake. Downstream, an incremental model keeps only the latest execution for each brand, region, and window, so re-runs of a rolling look-back replace provisional numbers instead of double-counting them.

How we run AMC in production

The SQL is the easy part. The operational layer is what makes AMC trustworthy enough to put in front of a client every week.

Scheduled workflows per brand and region. Each brand gets the same library of workflows (overlap, path to conversion, new-to-brand by campaign, frequency) deployed to each of its instances through the API. Workflow SQL lives in version control, not in the console.
Results land in the client's own warehouse. AMC outputs sit next to Amazon Ads API reporting and SP-API sales and inventory data, in a warehouse the client owns. That lets dbt models join AMC audience insight to spend, ACOS, and total sales by brand, region, and week.
Freshness checks. dbt source freshness tests flag any brand and region whose latest AMC result is older than expected, and an execution status check catches runs that failed or timed out on Amazon's side.
Telling suppressed rows from real zeros. This is the check most pipelines miss. We record every execution's status and row count, and compare the returned dimension values (campaigns, exposure groups) against what we expected from the Ads API. If an execution succeeded but a campaign is missing, it is flagged as "below threshold," not reported as zero. A real zero only shows up as an explicit row that passed the threshold. Dashboards label the two differently, and an execution that succeeds but returns no rows at all raises an alert.
Rolling re-runs. Recent windows are re-executed on a schedule until attribution has had time to settle, and the warehouse keeps the latest version.

Common mistakes

Querying too-narrow audiences. Slicing by campaign, day, and device at once pushes most rows under the aggregation threshold. Start broad and add dimensions one at a time.
Comparing AMC numbers to console numbers directly. The Ads console and AMC can use different attribution windows, date logic (conversion time vs traffic time), and deduplication rules. Reconcile definitions before you reconcile numbers.
Ignoring the region split. Summing US and EU results without a region dimension, or assuming shoppers can be deduplicated across instances, produces totals that look precise and aren't.
Treating recent results as final. Attribution keeps updating for days. Freeze numbers only after the look-back has settled.
Running everything from the console. Queries saved in the UI drift, get edited without review, and can't be scheduled reliably. Use the API and version control.

Who actually needs AMC

AMC earns its engineering cost once you're running DSP alongside Sponsored Ads at meaningful scale, or managing enough client accounts that manual cross-channel analysis has become a bottleneck. If you're primarily running Sponsored Products on a handful of ASINs, the standard Ads API and a clean reporting pipeline will get you further, faster, than an AMC investment.

How to evaluate whether you're ready

Before investing in AMC integration, check three things: do you already have reliable API-based pipelines for your existing Amazon data (if reporting is still manual, fix that first); do you have a BI layer that non-technical stakeholders actually use; and do you have a specific cross-channel question AMC would answer that your current tools can't. If all three are true, AMC is a genuine unlock. If not, it becomes an expensive dataset nobody queries. Our Amazon Marketing Cloud services page describes how we set it up.

Frequently asked questions

Is Amazon Marketing Cloud only available to agencies?

AMC is available to advertisers who meet Amazon's eligibility requirements, including agencies and brand advertisers running Sponsored Ads and/or DSP. Eligibility and account setup go through Amazon Ads directly.

Do I need a data team to use AMC?

Practically, yes. AMC is queried in SQL and requires scheduled extraction, transformation, and a reporting layer to be useful day-to-day. Most teams either build this internally or bring in a data engineering partner to build and maintain the pipeline.

Does AMC replace standard Amazon Ads reporting?

No. AMC complements standard reporting rather than replacing it. Day-to-day metrics like ACOS and spend still come from the Ads API; AMC adds the cross-channel and audience-level view that standard reporting can't provide.

Amazon Marketing Cloud (AMC), Explained: What It Is and Who Actually Needs It