Human Approval for AMC Activation

Human approval for Amazon Marketing Cloud (AMC) activation belongs between sizing and the create call. The approver sees the measured seed against Amazon's floor, the exact SQL, the date window, the refresh cadence, and the destination advertiser. Only an approved request is submitted; an undersized or rejected audience stays a read-only analysis.

Run the read-only half of an AMC workflow hands-off and stop in one place. The Amazon Ads MCP runs the sizing reads, and its audience create operation is a write tool: write tools apply your workspace policy and may require explicit human approval before changes reach Amazon. The Amazon Marketing Cloud Skill writes the SQL, and Amazon Agent Atlas supplies the rules the approver checks. New to AMC? Start with the Amazon Marketing Cloud explainer.

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, your judgment running every time, and your call before anything changes. Here that means live sizing reads against your instance, a Skill that keeps your team's rules, and an approval policy on the one write that matters.

An AMC audience query returns nothing to review, so approval gates the Amazon Ads MCP create call

Amazon's AMC audience use cases settle where the gate goes: "Unlike AMC analytics queries, AMC audience queries do not return visible results that you can download. Instead, the audience defined by the query is pushed directly to Amazon DSP, or Sponsored Products, Sponsored Brands, and Sponsored Display." Amazon DSP is Amazon's demand-side platform. A rule-based audience query selects a set of user_id values. After submission, the next thing you can inspect is the audience in the ad console.

Audience queries also run on their own tables, the ones with the _for_audiences suffix:

• conversions_for_audiences, the audience copy of conversions
• dsp_impressions_for_audiences and sponsored_ads_traffic_for_audiences
• amazon_attributed_events_by_traffic_time_for_audiences
• conversions_all_for_audiences, a paid-feature table that Amazon makes available at no cost through December 31, 2026, in the regions that offer AMC paid features

That suffix in a FROM clause is a machine-checkable signal that a query is an activation, not an analysis. The Skill holds audience SQL to those variants, and Amazon rejects a query that skips them with the statusReason "Invalid tables in the SQL query: Use audience-specific tables in the query."

Through the Amazon Ads MCP, the write is AMCRuleAudience_createQueryBasedAudience (POST /amc/audiences/query); lookalikes use AMCRuleAudience_createLookalikeAudience (POST /amc/audiences/lookalike). Both are write tools, so your workspace policy decides whether they wait for a person. This guide is the case for making them wait.

Atlas supplies the approval numbers: 2,000 records for a rule-based audience, a 500 to 500,000 seed for a lookalike

Two thresholds decide approvability, and they never blend:

• Rule-based audiences. Amazon's AMC rule-based audience creation guide: "AMC rule-based audiences require a minimum audience size of 2,000 records; target 2,500 records or more to prevent failure."
• Lookalike seeds. The same guide sets "a minimum of 500 and a maximum of 500,000." Introduction to AMC lookalike audiences, Amazon's lookalike use case, adds that refresh "will fail if the size falls below 500 or goes above 500k" and recommends 1,000 to 450,000.

A correct approval card names the one threshold that applies and puts the measured number beside it.

Measurement runs automatically. Amazon's docs note that user_id can never be returned in an analytics query, so size is a COUNT of user_id over the same constraints. Sizing is a read, and read tools are safe for normal agent use, so it runs without waiting on anyone.

A purchaser seed from the audience table, the same query shape the cart-abandoner workflow assembles upstream:

SELECT
  user_id
FROM
  conversions_for_audiences
WHERE
  event_subtype = 'order'

This seed has no GROUP BY, so it returns one row per order event. Amazon's companion pattern, SELECT COUNT(user_id) AS user_count FROM (seed query) GROUP BY 1, assumes one row per person; for this seed, count DISTINCT user_id and hold that number against 2,000, or 2,500 with margin.

Run that count as an ordinary analytics query, not in the audience editor. The _for_audiences tables are available only to audience queries, so swap conversions_for_audiences for its analytics table, conversions, keep the same event_subtype = 'order' filter, and count DISTINCT user_id.

On a lookalike, the same count places the seed inside the 500 to 500,000 band, and the required lookalikeAudienceExpectedReach sets the expansion. The use case lists tiers from roughly 300K to 1M members (most similar) up to 900K to 10M (most broad), region-dependent and subject to change, and recommends starting with balanced.

The approver reads the request the Amazon Ads MCP will send: audienceName, advertiserId, query, window and refreshRateDays

In front of the human sits the create request itself, not a summary. Amazon's rule-based audience creation guide defines the fields:

• audienceName: required, shown in Amazon DSP or the sponsored ads account; Amazon recommends a unique name each time.
• advertiserId: the Amazon DSP account or sponsored ads account the audience activates in, listed on the AMC Instance Info page.
• query: the seed SQL, flattened into one string.
• timeWindowStart, timeWindowEnd and timeWindowRelative: the date range, and whether it rolls forward on each refresh.
• refreshRateDays: how often AMC re-runs the query and overwrites the audience.

Shipped text is not drafted text. Amazon's high-value lookalike query tells you to "Remove all comment lines from the query before pushing to audience creation," and the SQL ships flattened into JSON. So the approver reads the query string, not the editor draft. Before anything runs, the Skill also shows the ads account name, profile name and AMC instance name side by side, because they can differ for multi-brand sellers.

{
  "audienceName": "AMC_Purchasers_Weekly_2026Q3",
  "audienceDescription": "Purchasers, June 2026 order window",
  "advertiserId": "1234567890123",
  "query": "SELECT user_id FROM conversions_for_audiences WHERE event_subtype = 'order'",
  "timeWindowStart": "2026-06-01T00:00:00Z",
  "timeWindowEnd": "2026-07-01T00:00:00Z",
  "timeWindowRelative": "FALSE",
  "refreshRateDays": 7
}

Three fields deserve more attention than the SQL. advertiserId is the destination: the account the audience lands in, confirmed, not assumed. refreshRateDays makes activation recurring: AMC re-runs the query on that cadence and completely overwrites the audience. Valid values are 0 to 21 for rule-based audiences (7 to 21 for lookalikes), and 0 deactivates the audience after 30 days.

timeWindowRelative decides what each refresh sees. With FALSE, as here, the window never moves, so every weekly refresh re-runs June's purchasers. With TRUE, the window shifts forward by refreshRateDays on each run. The approver is approving that behavior, not a one-off result.

The Amazon Ads MCP watches the handoff: SUCCEEDED in AMC is not Active in DSP, so allow up to 48 hours

The clock after the approved create call belongs to Amazon. The response carries an audienceExecutionId, and the Amazon Ads MCP reads its status with AMCRuleAudience_getQueryBasedAudienceByAudienceExecutionId: PENDING, RUNNING, SUCCEEDED (submitted to the advertiser account), or FAILED with a statusReason. The AMC console shows the same stages as Pending, Completed and Failed.

Completed is not usable. Manage your Amazon Marketing Cloud audiences says a Completed audience "may not yet be available for use in Amazon DSP or sponsored ads. It may take up to 48 hours for the audience to be available for use." Find your Amazon Marketing Cloud audience adds that a DSP audience in Processing "may take up to 48 hours to become Active." So 48 hours is the wait to allow before calling it a failure.

Amazon also gives the join between the two systems:

1. Read the audience with GET /amc/audiences/query/{audienceExecutionId} to get its DspCanonicalId.
2. Pass that ID to POST /audiences/list (AudiencesDiscovery_listAudiences in the Amazon Ads MCP) to filter by audienceId.
3. In the DSP console, filter Custom-built, then AMC. Amazon prepends "AMC" to the audience name there.

What happens next: watch each refresh against refreshRateDays

Approval covers the create call once; refreshes then run on Amazon's side. Amazon's rule-based audience guide says the cadence can change without anyone touching it:

• An audience not associated to a line item moves to a two-day refresh within 14 days, seven days within 30, and stops refreshing within 100.
• An audience with a static time window moves to a seven-day refresh after 30 days.
• A query that runs longer than four hours moves to a two-day refresh.

Changing the query, window or destination later is AMCRuleAudience_updateQueryBasedAudienceByAudienceExecutionId, another write, so the same approval policy applies. The Amazon Selling Partner MCP joins when audience logic depends on catalog facts, like which ASINs a promotion actually covers, and the Amazon Agent Data layer keeps your Amazon data in a query-ready lake in your own storage. That is the whole pattern: reads run free, the one write waits on your approval policy, and the approver reads the exact request that ships.

Next: turning gated analyses like this one into repeatable AMC agent workflows, where the approval step is part of the Skill rather than a manual afterthought.

{"audienceName":"AMC_Purchasers_Weekly_2026Q3","audienceDescription":"Purchasers, June 2026 order window","advertiserId":"1234567890123","query":"SELECT user_id FROM conversions_for_audiences WHERE event_subtype = 'order'","timeWindowStart":"2026-06-01T00:00:00Z","timeWindowEnd":"2026-07-01T00:00:00Z","timeWindowRelative":"FALSE","refreshRateDays":7}