Validate AMC SQL in the Sandbox First

Validate Amazon Marketing Cloud (AMC) SQL with a three-gate Skill: check the query against current AMC guidance, run the same SQL on sandbox synthetic signals, then confirm it on a short advertiser-instance window. The Amazon Ads MCP supplies the authorized AMC context and execution tools; Amazon Agent Atlas grounds the checks in Amazon's current sandbox rules. A sandbox pass removes structural uncertainty. It does not predict your brand's results or production-scale runtime.

The operator question was specific: “Can we test an AMC query before it runs against production and we wait an hour to learn it was wrong?” I wanted the agent to catch a missing column, bad grouping choice, or invalid join before the expensive run, without turning synthetic output into a media recommendation.

ChatGPT, Claude, Perplexity, Microsoft Copilot, and whatever comes next can explain SQL and measurement patterns to any advertiser, including your competitors. That shared intelligence is the starting line, not the advantage. Kuudo turns it into an AMC operating edge with your account as it is right now, your judgment running every time, and your call before anything changes. The Amazon Ads MCP reads and tests against your authorized instance, Skills preserve the rules your team expects, Amazon Agent Atlas supplies Amazon-specific guidance, and approval controls keep activation and other consequential changes with you. The result is private, owned, and specific to your business.

A sandbox pass proves structure, not the business result

The Skill starts with the exact SQL intended for production. It does not rewrite a simplified “test query” and hope the two versions behave alike. Atlas retrieved both Introduction to AMC Sandbox and Working with AMC sandbox, which document that the sandbox uses synthetic signals while providing the same AMC functionality and table structure needed for query iteration.

This query keeps the grouping from the reconstructed Create and execute an ad hoc workflow source, then fixes its cost-unit boundary before using the result for spend reporting. It establishes one row per advertiser and campaign from dsp_impressions:

SELECT
  advertiser,
  campaign,
  SUM(total_cost / 100000.0) AS spend,
  SUM(impressions) AS impressions,
  COUNT(DISTINCT user_id) AS reach
FROM
  dsp_impressions
GROUP BY
  advertiser,
  campaign

total_cost is stored in 1/100,000 currency units, so the query converts it to currency before labeling the result as spend. The sandbox can accept a query with the raw sum; execution success alone would not catch that unit error.

The sandbox run answers structural questions: Does the SQL compile? Do the table and columns exist? Does the grouping produce the intended grain? Do the joins and aggregations return the expected shape? If one of those fails, the Skill returns the error with the failed gate instead of spending the production run on a preventable mistake.

Aggregation controls must match the question being tested

The sandbox offers two distinct views of synthetic data. With aggregation controls on, the result behaves like advertiser-instance reporting: aggregated and anonymous. With controls off, the sandbox can expose event-level synthetic rows so I can inspect how fields and tables relate. Amazon says that event-level view is not available in advertiser instances.

I keep controls on for the production-like validation pass. I turn them off only to investigate record shape or use table preview. The sandbox query editor's preview can inspect up to 100 rows and automatically runs that preview with aggregation controls off. Those rows explain the schema; they are not the report I plan to ship.

The Skill run record makes the mode explicit:

skill: amc-sql-sandbox-validation
query: campaign-reach-and-spend.sql
sandbox:
  synthetic_data: required
  aggregation_controls: on
checks:
  - query_compiles
  - output_grain_is_advertiser_campaign
  - expected_metrics_are_present
production_confirmation:
  initial_window: "1 day"
  on_empty_or_suppressed: "widen to 7 days or reduce output granularity"
  reuse_exact_query: true

For API-driven sandbox executions, Amazon's documented control is requireSyntheticData: true. The related disableAggregationControls setting determines whether the synthetic run keeps normal aggregation protections or exposes event-level records. The Skill owns that distinction so the operator does not accidentally compare two different output modes.

Synthetic signals create a hard validation boundary

Sandbox signals are programmatically generated to mimic the structure, statistical properties, and logical cross-table relationships of AMC signals. They are not tied to a real advertiser campaign, customer ID, or ASIN. Amazon explicitly says not to use sandbox results to inform media strategy or implementation.

That boundary rules out four conclusions:

Amazon also documents cases the sandbox may not reproduce well: filters for specific campaign or ASIN identifiers, extremely granular output, varied distributions or outliers, and compute failures caused by a particular time window. A successful sandbox result is evidence about query structure, never evidence about campaign performance.

A short advertiser run closes the remaining gap

After the sandbox passes, the Amazon Ads MCP submits the unchanged query to the advertiser instance for the smallest useful window, starting with one day. That first production run has a narrow job: confirm real identifiers resolve, validate the output grain on real signals, and establish that the workload completes.

An empty one-day result is not automatically a failure. AMC removes output that does not clear its aggregation thresholds, so a low-volume advertiser or granular campaign grouping can produce no usable rows even when the identifiers and SQL are valid. When threshold suppression is plausible, the Skill marks the result inconclusive, widens the window to seven days, broadens a restrictive filter, or groups less granularly, then retries. Invalid identifiers and execution errors fail the gate; a threshold-limited result changes the test window.

This is where sandbox validation and AMC query-performance review meet. If the query is structurally valid but the short run is still slow, the next action is to filter earlier, reduce intermediate rows, inspect join grain, or test a smaller scope. The agent no longer wastes that investigation on a syntax error the sandbox could have caught.

The run record keeps the query text, sandbox aggregation mode, structural checks, short production window, execution identifiers, and result shape together. That evidence makes “validated” a reproducible state instead of a comment in Slack.

What happens next

Once the short advertiser run returns a conclusive result, I save the validation as a recurring Skill and attach its evidence to the Amazon Agent Data layer. The Amazon Ads MCP handles AMC execution, Atlas grounds the checks, and Skills preserve the gate order. If an ads workflow needs catalog or ASIN context, the Selling Partner MCP can supply that upstream without changing what the sandbox is allowed to prove.

The useful pattern is simple: use synthetic data to remove structural doubt, then spend the first production run testing reality.

Next: turn the validated AMC query into an agent Skill with repeatable execution and run evidence.