Find Your Optimal DSP Frequency Cap in AMC

Your Amazon demand-side platform (DSP) frequency cap is the last bucket where cumulative return still grows faster than cumulative cost, not the bucket with the best purchase rate. Amazon's Optimal Frequency Analysis playbook finds it in Amazon Marketing Cloud (AMC) by bucketing users by daily impressions. Its worked example lands on a daily cap of 4.

The agent runs that method in your Amazon Marketing Cloud (AMC) instance through the Amazon Ads MCP, joins amazon_attributed_events_by_traffic_time conversions to the impression buckets, and checks each step against Amazon's own guidance in Amazon Agent Atlas. The Amazon Marketing Cloud Skill carries the AMC SQL rules. You get one number and the table behind it.

The question usually arrives in one line:

"What's our optimal DSP frequency cap, and at what impression count are we paying for ad fatigue instead of conversions?"

It is easy to answer wrong, because the rate column is the first thing anyone plots. So the instruction to the agent is plain: skip the rate column, run the cumulative cost-and-return method, and show where it crosses.

ChatGPT, Claude, Perplexity, Microsoft Copilot, and whatever comes next know nothing about your business out of the box, and your competitors use them too. Kuudo gives those same tools your edge:

• Your account, as it is right now. The Amazon Ads MCP runs the query in your authorized AMC instance.
• Your judgment, running every time. Skills preserve the rules your team expects, and Atlas supplies Amazon-specific guidance.
• Your call, before anything changes. Approval controls keep activation and other consequential changes with you.

The Amazon Ads MCP buckets every user by daily impression count, not by one average

The raw shape every later step reads from is a per-bucket table, not a single average frequency. The Amazon Ads MCP runs the bucketing query in AMC, and the agent checks it against the Amazon DSP and sponsored ads impression frequency and conversions query that Atlas retrieves. That query groups users into frequency_01 through frequency_25+, where 25+ means 25 or more exposures, and reports users, impressions and purchases per bucket.

The query below follows the same pattern for DSP alone, at the day grain Amazon's playbook uses, because the cap you set is a daily one. Each row counts one user on one day. Conversions come from amazon_attributed_events_by_traffic_time, filtered to the same campaigns so sponsored ads conversions do not land in DSP buckets.

Three details come from Amazon's AMC documentation. total_cost is in millicents, so the query divides by 100,000. AMC does not support ORDER BY in a query, so you sort the downloaded output. The date range is set on the run, not in the SQL. The block is unvalidated, so run it in an AMC instance with DSP data before you trust it.

-- UPDATE: replace with your Amazon DSP campaign IDs
WITH campaign_ids (campaign_id) AS (
  VALUES
    (111111111111)
),
impressions AS (
  SELECT user_id,
         impression_date           AS event_date,
         SUM(impressions)          AS impressions,
         SUM(total_cost) / 100000  AS cost  -- total_cost is in millicents
  FROM dsp_impressions
  WHERE campaign_id IN (SELECT campaign_id FROM campaign_ids)
    AND user_id IS NOT NULL
  GROUP BY 1, 2
),
conversions AS (
  SELECT user_id,
         traffic_event_date       AS event_date,
         SUM(purchases)           AS purchases,
         SUM(total_product_sales) AS product_sales
  FROM amazon_attributed_events_by_traffic_time
  WHERE campaign_id IN (SELECT campaign_id FROM campaign_ids)
  GROUP BY 1, 2
),
by_user_day AS (
  SELECT i.user_id,
         i.impressions,
         i.cost,
         LEAST(i.impressions, 25)     AS frequency,
         COALESCE(c.purchases, 0)     AS purchases,
         COALESCE(c.product_sales, 0) AS product_sales
  FROM impressions i
  LEFT JOIN conversions c
    ON c.user_id = i.user_id
   AND c.event_date = i.event_date
)
SELECT CONCAT(FORMAT('frequency_%02d', frequency),
              IF(frequency = 25, '+', '')) AS frequency_bucket,
       COUNT(user_id)     AS user_days_in_bucket,
       SUM(impressions)   AS impressions_in_bucket,
       SUM(cost)          AS cost,
       SUM(purchases)     AS purchases,
       SUM(product_sales) AS product_sales
FROM by_user_day
GROUP BY 1

Purchase rate by bucket can't set the cap, because it leaves out cost

Purchase rate rises across the first buckets in Amazon's frequency query example: 0.48% at one impression, 1.10% at two, 3.86% at three. Other Amazon examples show the rate flattening after seven exposures, or spiking at three and then falling. None of those shapes says what the added impressions cost, so the rate column alone cannot tell you where to stop.

The agent flags that before it names a cap, rather than chasing the best-looking number. Atlas also carries Amazon's warning from the same query: the optimal frequency it finds for your chosen KPI may not be optimal across all of your advertising channels.

The agent sets the cap at the last bucket where Percent Change is still above zero

The agent runs Optimal Frequency Analysis in Amazon Marketing Cloud the way Amazon's playbook lays it out, and the result is the analysis report you get. Per bucket it computes:

• Cumulative cost and cumulative return: each bucket's total plus every bucket before it. Return is the KPI you choose, such as purchases or sales.
• Cumulative cost % and cumulative return %: each cumulative total divided by the total across all buckets.
• Percent Difference: cumulative return % minus cumulative cost %.
• Percent Change: this bucket's Percent Difference minus the prior bucket's.

The cap is the last bucket where Percent Change is above zero. Past it, the added cost grows faster than the added return. Here is the playbook's worked example, measured daily over 90 days with conversions as the return:

Bucket 5's -0.29% is the first negative, so the playbook sets a daily frequency cap of 4. A second example in the playbook shows what a loose cap costs. Optimizing one line item on total sales over a month, the model recommends a cap of 5, where cumulative return on ad spend (ROAS) is about 1.17. A cap of 9 drops it to 0.95, where spend exceeds sales.

The playbook also fits a curve and takes derivatives, but for a different job: finding a minimum frequency for under-served audiences and the apex of the curve. The cap itself comes from the Percent Change zero-crossing.

Atlas grounds the warning that your high-frequency tail is too thin to trust

High-frequency buckets thin out fast. In the example in Amazon's Reach and impression frequency query, around 90% of users saw the ad three or fewer times; in the frequency and conversions example, each bucket after nine holds under 1% of users. AMC also drops rows below its minimum distinct-user count by default. Read the cap off where the data is dense, not off a noisy tail.

Atlas carries those caveats from Amazon's queries, and the agent checks your run against the playbook's prerequisites:

• An AMC instance with at least 7 days of backfilled data.
• At least 4 active campaigns.
• A wait of about two weeks after the campaign ends, so the 14-day attribution window can close.

Amazon also notes that optimal frequency is not one size fits all. It depends on the campaign goal (brand awareness versus conversion), campaign length, audience size, whether it is a new product launch, and the type of product.

What happens next: set the cap in Amazon DSP and re-measure monthly

The artifact is a decision: one cap, with its time unit. From there:

• Set it in Amazon DSP. Put it on the campaign or the ad group (formerly the line item) as a maximum number of impressions over a number of days or hours. Frequency groups share one cap across campaigns.
• Apply it with approval. The Amazon Ads MCP includes the DSP campaign and ad group update operations, so the agent can prepare the change. Depending on your workspace policy, it may require approval before it goes live.
• Re-measure monthly. Amazon's playbook recommends it, and the Amazon Ads MCP can schedule the AMC workflow so each run lands a fresh table for review. The Amazon Marketing Cloud Skill keeps the SQL rules the same on every run.
• Or take Amazon's no-SQL route. The point-and-click Optimal Frequency solution in AMC recommends a daily cap range and can apply it across campaigns. The SQL path shows every step of the math and takes any KPI or breakout you choose.

The AMC run itself stays inside AMC. For the questions around it, the Amazon Agent Data layer, built on Amazon Agent Flow, lands your Amazon Ads and Selling Partner data in a lake you own. An agent can then set DSP spend beside the sales and inventory the Amazon Selling Partner MCP reads.

A frequency cap is one number, but it only means anything when it sits on the cost side of the math instead of the rate side. Set it there and you stop paying for impressions past the point where added cost outgrows added return.

Next in the series: where that capped DSP impression actually sits in the full conversion path, mapped end to end in the path-to-conversion Sankey.