Find Your Optimal DSP Frequency Cap in AMC

Your optimal Amazon demand-side platform (DSP) frequency cap is not the bucket with the highest purchase rate. That rate climbs forever (0.48% at one impression, 1.10% at two, 3.86% at three, 5.10% at four), so it always says never cap. The cap is the frequency bucket where cumulative return % stops outrunning cumulative cost %. The Amazon Marketing Cloud (AMC) Optimal Frequency Analysis method finds it, the agent runs it on your amazon_attributed_events_by_traffic_time conversions through the Amazon Ads MCP, and hands you a single number to set in DSP, grounded by Amazon Agent Atlas.

That sequence came out of one Slack question: "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 ask and easy to answer wrong. I trusted the best-converting bucket until the cost column flipped it. So I handed it to our agent with one instruction: don't read the cap off the rate column, run the cumulative cost-and-return method and show me where it crosses.

A plain ChatGPT or Claude chat hits the same three walls on this job. It has no access to your data, so it can't read your DSP impression logs or your attributed conversions, and has no per-user frequency distribution to bucket. It has no way to take action, so it can't run the AMC query and can't push a cap to your DSP line item or campaign; the most it does is hand you a number to type in by hand. And it runs on generic knowledge, not Amazon's, so it doesn't know the cumulative cost-and-return method or that AMC's aggregation thresholds quietly suppress your sparse high-frequency tail. The platform pieces get past each wall: the Amazon Ads MCP is your impression-and-conversion data plus the query runner, Amazon Agent Atlas is the Optimal Frequency Analysis rule book, Skills are the recurring re-check, and the Amazon Agent Data layer unifies it all into one grounded surface.

Optimal frequency analysis starts by bucketing every user by impression count, not by reading 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 and the agent grades the columns against the rules Atlas retrieves. Frequencies group into buckets frequency_01 through frequency_25+, where 25+ means exposed 25 or more times. The output schema is the AMC convention verbatim: frequency_bucket, users_in_bucket, impressions_in_bucket, purchases, and purchase rate. Conversions attach through amazon_attributed_events_by_traffic_time, the corpus-backed source for attributed purchases and product sales. This step is the "Measuring Optimal Impression Frequency for Amazon DSP Campaigns" playbook joined to the bucketing schema, with the reach distribution from "Calculating Reach and Impression Frequency in AMC."

The data pull below is an illustrative scaffold, not a query retrieved from Atlas. The corpus guarantees the output schema and the method, not these exact table and column names, so it carries the skip marker and ships unverified by design (the canonical runnable query is the linked Amazon instructional query).

WITH impressions AS (
  SELECT user_id,
         SUM(impressions) AS impressions,
         SUM(total_cost)  AS cost
  FROM dsp_impressions_by_user_segments
  GROUP BY 1
),
conversions AS (
  SELECT user_id,
         SUM(purchases)           AS purchases,
         SUM(total_product_sales) AS product_sales
  FROM amazon_attributed_events_by_traffic_time
  GROUP BY 1
),
by_user 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 USING (user_id)
)
SELECT CONCAT('frequency_',
              LPAD(CAST(frequency AS VARCHAR), 2, '0'),
              IF(frequency = 25, '+', '')) AS frequency_bucket,
       COUNT(user_id)     AS users_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
GROUP BY 1
ORDER BY 1

The highest purchase-rate bucket is the wrong cap, because it always tells you to never cap

Purchase rate rises monotonically with frequency: 0.48% at one impression, 1.10% at two, 3.86% at three, 5.10% at four across the first four buckets. Cap at the highest-rate bucket and you would cap at the top, which is the same as never capping at all. Atlas surfaces the "Measuring Optimal Impression Frequency for Amazon DSP Campaigns" result table that shows the climb, and the playbook's own warning that optimal frequency on Amazon may not be optimal across all advertising channels. The agent flags the trap unprompted rather than chasing the best-looking number.

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

Set the cap at the last frequency bucket where Percent Change (cumulative return % minus cumulative cost %, differenced bucket-over-bucket) is still above zero. Past that bucket, each added impression costs more than it returns. This is the "Optimal Frequency Analysis in Amazon Marketing Cloud" method, and it is the analysis report the agent produces. Per bucket it computes cumulative cost, cumulative return, cumulative cost %, cumulative return %, Percent Difference (cumulative return % minus cumulative cost %), and Percent Change (this bucket's Percent Difference minus the prior bucket's). The cap is the last bucket where Percent Change is above zero. You can gloss it as the inflection point where the curve of added value goes flat, but the mechanical rule is the zero-crossing, not a fitted curve.

The post-processing table is the artifact. Here is the playbook's worked example, with the cap read off where Percent Change first goes negative:

Bucket 5's -0.29% is the first negative, so the cap is frequency 4. The ROAS (return on ad spend) sanity check confirms it: at this cap cumulative ROAS is about $1.17, and a looser cap of 9 dropped cumulative ROAS to $0.95, where overall spend exceeded sales.

Your high-frequency tail is too thin to trust

Roughly 90% of users are exposed three times or fewer, so the high-frequency buckets thin out fast and fall below AMC's aggregation thresholds. Read the cap off where the data is dense, not off a noisy tail. This is where the "Calculating Reach and Impression Frequency in AMC" distribution and the prerequisites from "Optimal Frequency Analysis in Amazon Marketing Cloud" land. The prerequisites are an AMC instance, at least 7 days of backfilled data, and 4 or more active campaigns, plus the AMC concept of data aggregation thresholds. Atlas carries both, and the agent surfaces them unprompted along with the caveat that optimal frequency is not one size fits all: it depends on the goal (awareness versus conversion), campaign length, audience size, and whether the campaign is a new launch or steady state.

What happens next

The artifact is a decision: one cap number. You set it in Amazon DSP at the line-item or campaign level, the lever the playbook names as the actionable output. Then schedule the analysis as a recurring Skill so the cap re-checks itself as spend shifts and campaigns evolve, rather than going stale after one run. Amazon's point-and-click Optimal Frequency solution is a fine quick read, but the AMC SQL path wins on campaign-level control and custom KPIs (key performance indicators). The whole thing rides the Amazon Agent Data layer / Agent Flow that unifies the Amazon Ads MCP and the Amazon Selling Partner MCP under one grounded surface, so the conversions you join here come from the same place the rest of your Amazon work reads from.

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 outruns 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.