Kuudo — Run real Amazon work from any AI client

Launch a DSP Campaign Without Half-Built Entities

2026-08-20T00:00:00Z

Launching a DSP (demand-side platform) Performance+ or Brand+ campaign end to end is one ordered write sequence: every write is read back before the next step depends on it, every entity is created paused, and activation runs parent-first. Our create-DSP-campaign Skill runs that sequence through the Amazon Ads MCP, grounded by Amazon Agent Atlas where a retrieved rule decides what a step is even allowed to send, and it confirms real delivery in Amazon Marketing Cloud's DSP traffic tables rather than trusting a create response.

The ask arrived as a Slack message on a Thursday: "Can you spin up a Performance+ campaign for the Q4 ASINs? Display and streaming TV, five thousand dollars, starts Monday." Straightforward request. The last time someone ran it by hand we ended up with a campaign that existed, ad groups that did not, and an activation call returning NOT_FOUND on an ad group the API had confirmed creating seconds earlier. Half-built and live is worse than not built at all, because the spend starts before anyone notices the gap.

Why not just ask ChatGPT or Claude to do it? A plain chat hits the same three walls on any Amazon job. It has no access to your data, so it cannot resolve your DSP advertiser ID or ask Amazon which tactics your campaign is actually eligible for. It has no way to take action, so it cannot create a campaign, create an ad group, or flip anything to ENABLED; the most it can do is hand you JSON to paste into an API client yourself. And it runs on generic knowledge, not Amazon's, so it does not know that the inventory type you set on the campaign is spelled differently one level down. What you get is disconnected, generic, manual work that ships silent mistakes. The Amazon Ads MCP supplies your account plus the tools to act on it, Skills supply the ordered workflow, and Atlas supplies the rule book.

Create every entity paused and read each write back before anything depends on it

Nothing in this workflow is born live. The campaign is created with state: "PAUSED", every ad group is created paused, and activation is a deliberate final step. That ordering is what makes a failure halfway through recoverable instead of expensive.

The budget lives on the flight, not the campaign. There is no campaign-level budget field, so the single budget, start date, and end date the operator gave us map to one flight inside the campaign:

{
  "Amazon-Ads-AccountId": "<dspAdvertiserId>",
  "campaigns": [
    {
      "adProduct": "AMAZON_DSP",
      "name": "DSP|PB|Campaign 2026-08-20_14-02-11",
      "countries": ["US"],
      "state": "PAUSED",
      "flights": [
        {
          "startDateTime": "2026-08-24T00:00:00Z",
          "endDateTime": "2027-08-24T00:00:00Z",
          "budget": {
            "budgetType": "MONETARY",
            "budgetValue": {
              "monetaryBudgetValue": {
                "monetaryBudget": { "value": "5000" }
              }
            }
          }
        }
      ],
      "optimizations": {
        "bidSettings": { "bidStrategy": "SPEND_BUDGET_IN_FULL" },
        "goalSettings": { "kpi": "ROAS" },
        "primaryInventoryTypes": ["DISPLAY", "VIDEO_STV"]
      }
    }
  ]
}

Every datetime carries the Z suffix because the API rejects naive datetimes outright.

Then the part that turns this from racy into deterministic: the Skill does not move on. It waits 100 milliseconds, queries the campaign it just created, and retries up to three times at one-second intervals if the record is not visible yet. The Amazon Ads API v1 makes no read-after-write guarantee, so a create can return successfully and the very next call can fail to find what it created. Worst case this adds about 3.1 seconds per step, which is a fair trade against a half-built campaign.

In plain ChatGPT or Claude

No access to your data. ChatGPT cannot query your account to find the DSP advertiser ID that every later call depends on. It will confidently leave you a <dspAdvertiserId> placeholder, and you get to go find the real value yourself.
No way to take action. Claude cannot create the campaign or read it back afterwards. If you paste its payload into an API client by hand, you also inherit the verification step, which means you are the one retrying on an eventually consistent API at the exact moment you thought you were done.
Generic knowledge, not Amazon's. Ask where the budget goes and you will likely be told to put it on the campaign. There is no campaign-level budget field, so Amazon rejects that shape and you debug a payload that was wrong before you sent it.

Zero eligible tactics is a goal-KPI mismatch, not an outage

Once the campaign exists, ASIN conversion tracking gets attached: between 1 and 2,000 products per call, with a campaign ceiling of 500,000 products. Each entry carries the product ID, a domain derived as AMAZON_ plus the country code, and a product association of FEATURED.

That step has to land before the next one is meaningful, and it gets its own verification read for a specific reason. Eligible tactics are computed asynchronously, and the recomputation has its own propagation lag on top of the products landing. So the Skill verifies the products are present, then re-queries the campaign for eligibleAutomatedTargetingTactics, and retries three times at one-second intervals if the list comes back empty.

When the list is still empty after retries, the cause is almost never an outage. It is that the campaign's goal KPI cannot produce the tactic you asked for:

Tactic	Compatible KPIs	Goal
CUSTOMER_ACQUISITION (P+)	ROAS	Conversions
REMARKETING (P+)	ROAS	Conversions
RETENTION (P+)	ROAS	Conversions
MAXIMIZE_PERFORMANCE (P+)	COST_PER_DETAIL_PAGE_VIEW, DETAIL_PAGE_VIEW_RATE	Conversions
PROSPECTING (B+)	REACH, FREQUENCY_AVERAGE, COST_PER_VIDEO_COMPLETION, VIDEO_COMPLETION_RATE	Awareness

ROAS there is return on ad spend, and the KPI is set back at campaign creation, which is why this failure surfaces two steps after the decision that caused it. Ask for Brand+ prospecting on a campaign built with a ROAS goal and the eligible list is empty, correctly, forever.

The ad group renames the inventory type the campaign just used

This is the single most common rejection in the whole workflow, and it is pure API naming inconsistency rather than anything conceptual. The same inventory type has one spelling at the campaign level and another at the ad-group level:

Intent	Campaign field	Ad group field
Display	DISPLAY	DISPLAY
Streaming TV	VIDEO_STV	STREAMING_TV
Online video	VIDEO_OLV	ONLINE_VIDEO
Live events	LIVE_EVENTS	LIVE_EVENTS
Audio	AUDIO	AUDIO

The eligible-tactics response hands back campaign-level names, so the value you receive is not the value you send one call later. The Skill translates on the way through, which is exactly the kind of mechanical rule that should live in a workflow rather than in someone's memory.

The second trap is the field allowlist. A Performance+ or Brand+ tactic ad group accepts six fields and nothing else:

{
  "Amazon-Ads-AccountId": "<dspAdvertiserId>",
  "adGroups": [
    {
      "adProduct": "AMAZON_DSP",
      "campaignId": "<campaignId>",
      "name": "DSP|PB|STREAMING_TV|CUSTOMER_ACQUISITION 2026-08-20_14-02-11",
      "state": "PAUSED",
      "inventoryType": "STREAMING_TV",
      "targetingSettings": {
        "automatedTargetingTactic": "CUSTOMER_ACQUISITION"
      }
    }
  ]
}

Bid, budgets, pacing, optimization, start and end times, creative rotation, viewability: all of them are auto-managed for tactic ad groups, and all of them are rejected if you send them. When this returns INVALID_ARGUMENT, the fix is to strip fields, not to correct values. That distinction saves a long debugging session, because the error text reads like a validation failure on the values you did send.

Activate parent-first, or the ad groups fail against a campaign Amazon cannot see

Activation is two moves in a fixed order: the campaign flips to ENABLED first, then each ad group flips to ENABLED. Never the reverse, and never in parallel.

If the campaign fails to activate, the Skill stops and does not touch the ad groups at all. Activating children under a parent that is still paused produces either an outright failure or, worse, a confusing half-state where some entities are live and the thing that governs them is not. Reporting what did succeed is more useful than pushing on and leaving someone to reconstruct the order afterwards.

This is also where the verification reads from every earlier step pay off. Activation immediately follows creation, and an update against a record the API cannot see yet is precisely how NOT_FOUND appears on an entity you watched get created.

Confirm delivery in the DSP tables, not in the create response

A successful activation call means the entities are enabled. It does not mean a single impression has served. Those are different claims, and only one of them is what the operator actually asked for.

Amazon Marketing Cloud carries three DSP traffic tables that answer the delivery question: dsp_impressions, dsp_views, and dsp_clicks. They cover all Amazon DSP campaigns across ad product types including display, online video, streaming TV, and audio. dsp_clicks is a subset of dsp_impressions that captures the impressions that were clicked, so a campaign with rows in impressions and none in clicks is delivering and not being clicked, which is a very different problem from not delivering.

The dimension that makes this readable per tactic is line_item, which holds the name of the DSP line item responsible for the event, in the shape 'Widgets - DISPLAY - O&O - RETARGETING'. Amazon's own example encodes the inventory type and the tactic directly in that name, which is the same grain the Skill created against: one entity per inventory type and tactic pair. Read delivery at that grain and a tactic that never served shows up immediately instead of hiding inside a campaign total. Check how your own line item names resolve the first time you run it, because the create surface and the reporting surface are different systems and nothing guarantees the strings match. Attributed conversions are a separate question again, and come from amazon_attributed_events rather than the traffic tables.

One caveat worth knowing before you panic at an empty result. The DSP traffic tables contain inputs only from the DSP advertising accounts that have been added to that Marketing Cloud instance. A campaign can be delivering perfectly and still return nothing if its advertiser was never added.

What happens next

The launch is the easy half. What makes it durable is that the whole sequence is a Skill rather than a runbook, so it re-runs the same way for the next campaign, and the delivery check re-runs on a schedule instead of when someone remembers. The Amazon Agent Data layer is what turns that check into something standing: the DSP tables land next to the rest of your Amazon data, alongside the Selling Partner MCP pulls behind your catalog and order history, so a per-tactic delivery question is a query rather than a project.

The decision rule we run on is simple. Give a tactic a defined window after activation, then check line_item delivery. A tactic with no impressions in that window is not a slow start, it is a signal to look at eligibility and inventory rather than to wait longer. A tactic delivering impressions with no clicks is a creative problem, not a targeting one, and those two findings route to different people.

Once the campaign has enough delivery to compare against everything else running, the next question is usually how much of it is incremental rather than overlapping what your sponsored ads already reached.

Next: the four-way sponsored ads and DSP overlap audit, which measures exactly that.

The Data-Mode Router That Stops Bad ACoS Math

2026-08-07T00:00:00Z

The nonsense ACoS numbers show up because your SQP export has no cost or revenue columns in it, and Amazon's own export doesn't flag that gap for you, nothing in the raw Ads or Selling Partner APIs tags a dataset as ads-backed or organic. Any report that hands you ACoS anyway skipped a check our data-mode-router Skill runs before every metric: a reusable, structured process, grounded by Amazon Agent Atlas's Keyword Analysis Decision Framework, that inspects the columns actually present in a dataset before it lets ACoS, ROAS (return on ad spend), or any spend-based number get computed. I asked our agent why a batch of n-gram reports kept returning ACoS on exports that never carried a spend column, and the answer was structural, not a bug. The Skill tags every dataset ads, organic, or mixed from its column set and hard-blocks ACoS/ROAS outside ads-backed data. Search Query Performance exports, pulled through the Selling Partner MCP, are organic by construction. There's no spend column in there to blend.

Why not just paste that export into ChatGPT or Claude and ask for ACoS? A plain chat hits the same three walls on any Amazon job. It has no access to your data, so it only sees the columns you pasted and can't check whether total_median_click_price is real spend or a market proxy. It has no way to take action, so the best it can do is hedge in prose instead of blocking the computation outright. And it runs on generic knowledge, not Amazon's, so it has no idea ACoS in organic mode is a codified Amazon violation. What you get is disconnected, generic, manual work that ships silent mistakes. Amazon Ads MCP and the Selling Partner MCP give an agent your data and the tools to act, Atlas supplies the rule book, Skills packages the workflow.

The router tags every dataset ads, organic, or mixed before a metric runs

Before our agent computes anything, the data-mode-router Skill runs its Quick Router logic to look at which columns a dataset actually has. This step doesn't exist in the raw Amazon data, it's the Skill applying Atlas's codified rules as a structured process, the same way every time. Ad signals are cost or spend, campaign_id, ad_group_id, keyword, match type, placement, the columns that exist because the Amazon Ads MCP mirrors those fields straight out of your live account, not because someone typed labels into a spreadsheet. Organic signals are search_query, total_impressions, asin_impression_share, and the rest of the Search Query Performance schema. If a dataset has ad signals and no organic ones, it's tagged ads. If it has organic signals and no ad ones, like every SQP export, it's tagged organic. Both together, it's mixed.

That tag isn't a note in a log somewhere, it's the first field on every record the Skill emits. Here's what an ads-mode row looks like coming out of the n-gram rollup:

{
  "data_mode": "ads",
  "ngram": "wireless headset",
  "n": 2,
  "imp": 12450,
  "clk": 386,
  "cost": 782.14,
  "orders": 41,
  "revenue": 4312.0,
  "metrics": {
    "ctr": 0.031,
    "cvr": 0.1061,
    "cpc": 2.027,
    "roas": 5.514,
    "acos": 0.181
  }
}

Notice data_mode comes before the metrics that depend on it, not after. This is also the point where the router's job ends and a different rulebook picks up. Once a keyword resolves to ads, whether to actually change a bid on it is a separate question, governed by a different Quick Router keyed on bidding_state, not data_mode, over in the Sponsored Ads Bidding Configuration Decision Framework. The data_mode router decides what a signal even means. That framework decides whether to act on it.

ACoS in organic mode isn't a style nitpick, it's priority #1 forbidden

Our data-mode-router Skill doesn't treat "don't compute ACoS on organic data" as a soft preference, it enforces it as code, every run. It's rule one of seven in the decision-precedence ladder the Skill applies, grounded by Atlas, ranked above thin-data holds, safety negatives, pull-back actions, scale moves, and mining or hygiene work. Invalid computations get dropped and repaired before any other business rule even gets evaluated. Nothing outranks it, and nothing in Amazon's own reporting enforces this ranking for you.

The Skill's config defaults reinforce the same rule structurally, not just procedurally: target_acos, target_roas, and break_even_acos only exist under the ads branch of the targets config. There's no organic branch for an ACoS target to live in, because organic data was never going to have spend to target against. Those same three constants (0.25, 4.0, 0.30 in our defaults) are actually anchored at the ad-group level by the Sponsored Ads Bidding Configuration Decision Framework mentioned above, the data-mode-router Skill just reads them, it doesn't own them.

precedence:
  1: invalid_computation   # drop/repair, e.g. ACoS computed in organic mode
  2: hold_thin_data
  3: safety_negative
  4: pull_back
  5: scale_unlock
  6: mining_hygiene
  7: creative_ops
targets:
  ads:
    target_acos: 0.25
    target_roas: 4.0
    break_even_acos: 0.30
  # organic has no target_acos / target_roas key at all

Mixed data doesn't get blended into one number, it gets split into two

Some exports carry both column families at once, a keyword report joined against a campaign report, say. When that happens, the Skill's mixed-dataset guardrail doesn't average the two into one blended figure. It computes ads metrics only where ads-backed cost and revenue actually exist, applies organic rules only to signals backed by SQP, and emits two separate records for the same keyword, each carrying its own data_mode tag, with no cross-mixing of numerators and denominators between them.

For "wireless headset," that looks like this:

[
  {
    "data_mode": "ads",
    "ngram": "wireless headset",
    "n": 2,
    "imp": 12450,
    "clk": 386,
    "cost": 782.14,
    "orders": 41,
    "revenue": 4312.0,
    "metrics": { "ctr": 0.031, "cvr": 0.1061, "cpc": 2.027, "roas": 5.514, "acos": 0.181 }
  },
  {
    "data_mode": "organic",
    "ngram": "wireless headset",
    "search_query": "wireless headset",
    "total_impressions": 58210,
    "total_clicks": 1904,
    "conversion_performance_index": 96,
    "share_funnel_gaps": { "impression_to_click_gap_pp": -0.4, "click_to_purchase_gap_pp": 0.6 }
  }
]

Two records, two tags, nothing shared between their numerators and denominators. The alternative, one blended row with an ACoS computed against a mix of real spend and organic volume, is exactly the invalid computation rule one exists to catch.

Organic mode routes to Conversion Performance Index, not ACoS

Blocking ACoS on organic data is only half the rule, the Skill also has to route to something valid, and for organic that's Conversion Performance Index and the impression-to-click-to-purchase share funnel. Neither is a field Amazon's Search Query Performance report gives you directly, the Skill calculates both from the shares Amazon does report. CPI is (your_purchase_rate / market_purchase_rate) x 100, banded under 80 as underperforming, 80 to 120 as competitive, and above 120 as outperforming. Alongside it, impression_to_click_gap_pp and click_to_purchase_gap_pp show exactly where your ASIN is losing share against the market baseline for that query.

Below the CPI sufficiency floor (asin_clicks >= 20 and total_clicks >= 100), the Skill holds the decision instead of guessing on thin data. The ASIN-level diagnostic layer downstream adds its own floor (total_impressions >= 200) before it turns a share gap into a strong claim, and cooldowns run 7 to 14 days per query and ASIN so the same finding doesn't refire every day. Here's a full routed decision for one query, including the guardrail check that blocked ACoS on the way in:

{
  "report_id": "sqp-ngram-2026-08-07",
  "routing": {
    "columns_detected": ["search_query", "total_impressions", "total_clicks",
      "asin_impression_share", "asin_click_share", "asin_purchase_share",
      "total_median_click_price"],
    "ads_signals_present": false,
    "organic_signals_present": true,
    "resolved_data_mode": "organic"
  },
  "guardrail_checks": [
    {
      "rule": "invalid_computation",
      "precedence_rank": 1,
      "trigger": "ACoS/ROAS requested but data_mode=organic (no cost/spend columns)",
      "result": "blocked",
      "action": "drop_and_repair",
      "repair": "substitute Conversion Performance Index + share funnel gaps"
    }
  ],
  "decisions": [
    {
      "data_mode": "organic",
      "search_query": "dog bed large",
      "asin": "B00XYZ...",
      "market": { "total_impressions": 123456, "total_clicks": 3456, "purchase_rate": 0.018 },
      "asin_metrics": { "impression_share": 0.024, "click_share": 0.031, "purchase_share": 0.020 },
      "conversion_performance_index": 64.5,
      "share_funnel_gaps": { "impression_to_click_gap_pp": 0.7, "click_to_purchase_gap_pp": -1.1 },
      "flags": { "thin_data": false },
      "recommendations": ["pdp_update"]
    }
  ]
}

A CPI of 64.5 lands below 80, underperforming the market, which is exactly why recommendations queues pdp_update rather than a bid change. Behind that field sits the ASIN-level diagnostic layer, running its own IF-THEN rules on top of the share funnel: high query volume with low impression share routes to seo_update plus pdp_update, purchase share trailing click share alongside slow shipping routes to shipping_speed_fix. ACoS was never going to point you at any of that.

What happens next

When I run this against a fresh batch of reports, our agent doesn't just resolve data_mode, fire the guardrail check, and hand back a JSON blob to stop there. It pushes the routed decision into Amazon Agent Flow, the data layer that holds routed decisions alongside the raw SP-API (Selling Partner API) and Ads API pulls they came from, so next week's report starts from the same schema instead of guessing again. The recommendation it queued, pdp_update, seo_update, shipping_speed_fix, becomes a scheduled run of the same Skill that reruns on the 7-to-14-day cooldown instead of a one-off answer you have to remember to ask for again.

If the resolved mode had come back ads instead, the same decision hands off to a different ladder entirely, applied by a different Skill: the bid-thrash precedence covered in the bidding rulebook guide, which decides whether to actually move a bid once the signal underneath it is already confirmed valid. The data-mode-router Skill decides what a number means. The bidding rulebook's Skill decides what to do about it once it does.

That's the pattern underneath the whole rulebook: validate the signal before you ever act on it, structured Skill logic doing work Amazon's raw reports never do on their own, and never let the two ladders answer each other's questions.

Next in the series: how the ASIN-level diagnostic decision object turns a Conversion Performance Index gap into a queued PDP or SEO fix.

Auditing FBA Reimbursements: What Amazon Owes You

2026-08-07T00:00:00Z

Grounded by Amazon Agent Atlas, the fba-reimbursement-audit Skill is what actually answers "how much in FBA (Fulfillment by Amazon) loss and damage reimbursements has Amazon already paid us, and how much are we missing," because Amazon's own Inventory Defect and Reimbursement portal can't: it lists individual defect events across its Eligible, In Progress, and Resolved tabs, but it never classifies an event into a claim type, checks it against that type's own window, or applies the correct valuation rule. I went looking for this number after our reconciliation spreadsheet fell three months behind the portal. Once I asked our agent to pull every eligible event through Selling Partner MCP, classify it, and check it against Amazon's actual policy, the picture changed: real money sitting unclaimed, and real deadlines closing on it.

Before building anything, I asked ChatGPT and Claude the same question. Both hit the same three walls: no access to your data (they've never seen our Inventory Defect and Reimbursement portal or Ledger report), no way to take action (they can't file a claim or submit a sourcing cost), and generic knowledge, not Amazon's specific rules (they default to textbook reimbursement logic, not FBA policy). The answer stayed a guess. MCP supplies the data and the tools to act, Atlas supplies the cited rule book, the Skill runs the workflow safely.

A loss or damage event isn't one claim, it's three claim types with three different windows

Every lost or damaged unit Amazon owes us for falls into one of three claim types, and each type carries its own deadline, not a shared one. Shipment to Amazon claims (units lost or damaged in transit to a fulfillment center or third-party facility) have to be filed no later than nine months after the verified delivery date. Fulfillment Center Operations claims (units lost or damaged inside Amazon's own operations) have to be filed no later than sixty days after the item was reported lost or damaged in the Inventory Defect and Reimbursement portal or the Inventory Ledger report. Customer Return claims are the one most sellers get wrong: file no sooner than sixty days and no later than 120 days after the refund or replacement, a window with a floor as well as a ceiling.

Classifying comes first. The Skill sorts every raw defect and return event by type, then computes each one's window status, open, closing soon, or expired, as a flagged field in the audit report. That's the step the portal skips: it'll show an event happened, but it won't say which of the three clocks is running on it, let alone how many days are left.

{
  "event_id": "EVT-00113",
  "classified_claim_type": "fulfillment_center_operations",
  "reported_date": "2026-06-12",
  "window": { "end": "2026-08-11", "status": "closing_soon", "days_remaining": 4 }
}

Eligibility isn't a spectrum, it's seven gates that all have to hold

Amazon doesn't reimburse partial eligibility. A unit has to be FBA-registered at the time of loss, compliant with FBA restrictions, shipped in the exact quantities on the shipping plan, part of a shipment that wasn't canceled or deleted, not pending or actioned for disposal, not customer-damaged or defective, and tied to an account that stays in normal status all the way through the claim and any appeal. Seven gates, and every single one has to be true. Fail one and the claim is void, no matter what the item was worth.

The Skill checks all seven gates automatically before an event counts toward the "recoverable" total, splitting the result into eligible-and-unclaimed versus ineligible, and naming the specific gate that failed on each ineligible event instead of just marking it "no." That distinction matters when we're deciding whether to spend appeal time on a claim that was never going to qualify.

Valuation depends on when the loss happened, not what the item is worth

Pre-order events pay differently than post-order ones, and that split runs through every lost unit on the sheet. Shipment-to-Amazon losses, removals, and fulfillment center operations events pay our sourcing cost: what we paid to source the unit, not what we'd have sold it for. Customer return events pay the refund or replacement amount minus applicable fees instead. Either way, $5,000 per unit is the ceiling: Amazon caps a single unit's reimbursement at that amount regardless of which of the two rules set the value. Most sellers, including me before I looked closely, mentally price every lost unit at retail. The policy doesn't work that way, and the gap between the two numbers is where the missed money hides.

Inside the Skill, the valuation engine applies the correct rule per event based on its classified claim type, and for every pre-order event it checks whether we've actually submitted our own sourcing cost or whether Amazon is still defaulting to its own estimate. The audit report shows both numbers side by side, Amazon's likely valuation against our sourcing-cost-corrected valuation, with the $5,000 cap applied wherever it binds.

{
  "artifact_type": "audit_report",
  "skill": "fba-reimbursement-audit",
  "grounded_by": "amazon-agent-atlas",
  "summary": {
    "events_audited": 214,
    "reimbursed_total_usd": 8420.15,
    "eligible_unclaimed_total_usd": 1180.40,
    "at_risk_window_closing_usd": 340.00,
    "disputable_valuation_total_usd": 265.75
  },
  "events": [
    {
      "event_id": "EVT-00113",
      "classified_claim_type": "fulfillment_center_operations",
      "order_relationship": "pre_order",
      "valuation": {
        "rule_applied": "sourcing_cost",
        "sourcing_cost_submitted": false,
        "amazon_estimate_usd": 14.20,
        "unit_cap_usd": 5000
      },
      "status": "eligible_not_filed",
      "flags": ["window_closes_in_4_days", "sourcing_cost_not_submitted"]
    },
    {
      "event_id": "EVT-00087",
      "classified_claim_type": "customer_return",
      "order_relationship": "post_order",
      "valuation": { "rule_applied": "refund_minus_fees", "refund_amount_usd": 42.00, "fees_deducted_usd": 6.30 },
      "reimbursement_actual": { "issued": true, "amount_usd": 30.00, "variance_vs_expected_usd": -5.70 },
      "status": "disputable",
      "flags": ["eligible_for_valuation_dispute"]
    }
  ]
}

Reimbursement isn't a one-shot event, it's a loop most sellers never run

Getting paid once isn't the end of it. There's a recovery loop layered on top of the three windows and seven gates: submitting our own sourcing cost instead of accepting Amazon's estimate, respecting the thirty-day cooldown before resubmitting without new information, disputing a valuation within sixty days of an issued reimbursement, and handling the customer-return special case correctly. If a customer is refunded but never returns the item to a fulfillment center within sixty days, Amazon typically charges the customer and reimburses us. If the item does come back within sixty days and it's sellable, it goes back into inventory and we get no reimbursement. If it comes back unsellable and Amazon caused the damage, we get reimbursed and the item isn't restocked.

Tracking doesn't stop at filing. The Skill follows every event's reimbursement status across its full lifecycle, not just at the moment a claim gets filed, flagging "sourcing cost not yet submitted," "eligible for valuation dispute, window closes in nine days," and "resubmission blocked until August 20th, no new information supplied," so the backlog of things we could still do doesn't quietly age out.

What happens next

Once the audit report is built, it doesn't sit still. We feed it into Amazon Agent Flow, the same data layer that holds Amazon Ads MCP and Selling Partner MCP pulls side by side, so recovered reimbursement dollars sit next to the ad spend they help offset. The Skill schedules the same pass weekly and hands off anything newly flagged: a window closing inside seven days, a sourcing cost still unsubmitted, a dispute that just opened, so it shows up as a task instead of a line buried in a spreadsheet.

Recovery is only half the ledger. The other half, what we pay out rather than what Amazon owes back, is covered in the FBA inventory health guide: storage fees, capacity limits, aged-inventory surcharges. Running both audits is how we see the full ledger instead of half of it.

Same pattern every time: Amazon publishes the rule, leaves the classifying and window-checking to the seller, and pays out only what gets claimed correctly and on time.

Next in the series: what happens when Amazon denies a valid claim outright, and the appeal window most sellers let expire.

The ARA Report and Metric Glossary for Vendors

2026-08-07T00:00:00Z

The ARA report router Skill, grounded by Amazon Agent Atlas, is what actually answers which ARA report answers a given question, and what the metric inside it actually measures. Amazon's Vendor Central UI doesn't do that: it hands you a dashboard tab. Raw SP-API (Selling Partner API) reports don't do it either: they hand you a payload full of fields, not an interpretation of which field you needed or what its number means. I run into this constantly. Someone on my team asks why sell-through dropped, or what "Conversion" means in the export we're staring at, and the honest answer depends on which report, which account view, and which section of Amazon's own help docs you're reading, not on which tab happened to be open when you logged in.

Why not just ask ChatGPT or Claude the same question? A plain chat hits the same three walls on any Amazon job. It has no access to your data, so neither knows if your login has Sourcing or Manufacturing view, or whether you're Brand Registry enrolled, and can't name your dashboard. It has no way to take action, so neither can call SP-API to verify a report type actually exists. And it runs on generic knowledge, not Amazon's, so the answer is uncited and primed to ship a silent mistake. What you get is disconnected, generic, manual work. MCP is your data and the tools to act, Atlas is the cited rule book, the Skill is the safe workflow.

Every ARA dashboard has a mirrored SP-API report type, so naming the dashboard is only half the job

Sales maps to GET_VENDOR_SALES_REPORT. Inventory maps to GET_VENDOR_INVENTORY_REPORT. Forecasting maps to GET_VENDOR_FORECASTING_REPORT. Traffic maps to GET_VENDOR_TRAFFIC_REPORT. Net PPM maps to GET_VENDOR_NET_PURE_PRODUCT_MARGIN_REPORT. Knowing the dashboard name gets you nowhere near an API call, and knowing a report type string with no dashboard context doesn't tell you which metric definition governs it. The ARA report router Skill resolves both in a single lookup, calling through Selling Partner MCP to fetch the report once it knows which one you actually need.

When I asked our agent why sell-through dropped on a set of ASINs, the Skill didn't guess. It resolved the question to the Inventory dashboard, the GET_VENDOR_INVENTORY_REPORT report type, and the sellThroughRate field inside it, then pulled the report through the same call path. It's also the reason the Skill catches a retirement most operators don't think to check: the Sales and Inventory EDI transactions (X12 852, EDIFACT SLSRPT) and the Forecast EDI transaction (X12 830, EDIFACT DELFOR) were retired after June 30, 2022, so API is now required to pull them. Traffic and Net PPM never had an EDI form at all; they've been API-only from day one. If the question resolves to Net PPM specifically, that's where the margin-leakage guide picks up. This guide is upstream of it: once the router names the dashboard and the report type, that guide is where you go hunting for the actual leak.

{
  "operator_question": "Which report do I pull to find products dragging my margin?",
  "resolution": {
    "dashboard": "Net PPM",
    "sp_api_report_type": "GET_VENDOR_NET_PURE_PRODUCT_MARGIN_REPORT",
    "view_required": "manufacturing",
    "metric": {
      "name": "Net pure product margin (Net PPM)",
      "definitions": [
        { "formula": "(shipped revenue - shipped PCOGS + CCOGS - sales discounts) / shipped revenue", "cited_section": "Net PPM dashboard" }
      ],
      "conflicting_definition": false
    }
  },
  "caveat_flags": ["excludes_warehouse_deals", "manufacturer_only_dashboard"]
}

ARA and ABA are different products gated by different rules, so "I can't find my dashboard" means two different problems

Every vendor gets ARA. No Brand Registry requirement, no enrollment gate, it's part of the vendor relationship. ABA, Amazon Brand Analytics, is a different product entirely: it requires Brand Registry enrollment and being the brand-selling party on the ASINs in question. Before the Skill routes an operator's question to a dashboard, it classifies the question against those access rules first, so it doesn't send you looking for a dashboard your account structurally cannot have.

Beyond the access gate, the two products measure different things entirely. ABA's Search feature covers search popularity, click share, and conversion share for a search term. Its market basket analysis shows co-purchased products. Its repeat purchase behavior tracks order counts and unique customers over time. None of that lives in ARA, which is built around sales and operational dashboards, not search or purchase-pattern analytics. Conflating the two doesn't just point you at the wrong tab, it points you at a feature set that doesn't exist in the product you're looking at.

Amazon's own ARA docs define "Conversion" two different ways on the same overview page

This is the one that made me stop trusting my own memory of ARA definitions. The Traffic dashboard section of Amazon's ARA overview defines Conversion as ordered revenue divided by glance views. The General dashboard information section, on the same overview page, defines Conversion as ordered units divided by glance views. Not a typo in one section and a fix in the other, both are live, current documentation. Amazon's own help content disagrees with itself two sections apart, and neither section says so.

Rather than pick a side, the Skill attaches both formulas to the resolution whenever it resolves a question to Conversion, citing each one's exact source section and flagging the metric as having a conflicting definition instead of silently returning one number as "the" answer. That flag matters more than it sounds: if your internal reporting was built against one formula and a teammate pulled a number using the other, you'd see two different Conversion rates and no obvious reason why, unless something told you to check.

ROOS and Rep OOS get the same treatment, for a related reason: they sound interchangeable and aren't. ROOS, procurable product out-of-stock, considers procurable ASINs, a broader cohort than Rep OOS's replenishable-ASINs-only scope. Because the ROOS cohort is larger, ROOS usually reads as a lower percentage than Rep OOS on the same account, which is exactly the kind of thing that looks like an error until you know it's a definitional difference. Sourceable Product OOS is a third, related but distinct glossary entry, not a synonym for either: OOS glance views on sourceable ASINs divided by total glance views, also Manufacturing view only. The Skill keeps all three as separate glossary entries so it never treats one as a stand-in for another. Sell Through Rate gets its own definition too: shipped units minus customer returns, divided by on-hand units plus received units, a formula with no ambiguity but plenty of adjacent metrics it gets confused with.

{
  "operator_question": "What does Conversion mean in my ARA dashboard, and which report is it in?",
  "resolution": {
    "dashboard": "Traffic",
    "sp_api_report_type": "GET_VENDOR_TRAFFIC_REPORT",
    "view_required": "manufacturing",
    "metric": {
      "name": "Conversion",
      "definitions": [
        { "formula": "ordered revenue / glance views", "cited_section": "Traffic dashboard" },
        { "formula": "ordered units / glance views", "cited_section": "General dashboard information" }
      ],
      "conflicting_definition": true,
      "resolution_note": "Amazon's ARA overview defines Conversion two different ways in two sections of the same page. Both sections are current, confirm which formula your internal reporting matches before comparing numbers across teams."
    }
  },
  "caveat_flags": ["manufacturer_only_dashboard", "conflicting_definition"]
}

Four recurring distortions make an ARA number look complete when it isn't

Warehouse Deals sales are excluded from the Sales and Net PPM dashboards, so if your internal reporting reconciles against ARA and includes Warehouse Deals in its own totals, the two will never match, by design, not by error. Sourcing view versus Manufacturing view changes which ASINs and even which metrics appear at all: Traffic, Net PPM, Forecasting, Sourceable Product OOS, and ROOS are Manufacturing-view-only, so a Sourcing-view login won't show them regardless of what the operator asked for. Customer returns and cancellations get booked against the original date of the sale, not the date the return happened, which means a return processed this month can quietly revise a number from three months ago. And ASIN mapping issues, once corrected, can take up to fourteen days to actually show up in the dashboards, so a "fixed" product can look missing for two more weeks.

Net PPM itself is (shipped revenue minus shipped PCOGS plus CCOGS minus sales discounts) divided by shipped revenue, and the Warehouse Deals exclusion applies to it the same way it applies to Sales. The decision_plan the Skill produces carries these as caveat flags attached to the resolution itself, not buried in a footnote: excludes_warehouse_deals: true on Sales and Net PPM, view_required: manufacturing on Traffic, Net PPM, Forecasting, Sourceable OOS, and ROOS. The flag travels with the number, so whoever reads the resolution sees the caveat before they build a decision on the metric, not after.

What happens next

A decision_plan isn't a one-off answer, it's structured output the Skill can hand off downstream. Once the Skill has resolved a question to a dashboard, a report type, and a set of caveat flags, that resolution feeds into Amazon Agent Flow, the same data layer that holds Amazon Ads MCP and Selling Partner MCP pulls side by side, so a routed ARA answer sits next to the ad-spend numbers it eventually gets compared against. The Skill can schedule the same lookup as a recurring check instead of a one-time query, useful for anything with a mapping delay attached, since a "missing" ASIN today might just need another look in two weeks. For questions that resolve to Net PPM, the handoff goes straight to the margin-leakage guide, because routing tells you where to look and that guide is where you actually go digging for the leak itself.

The pattern underneath all four sections is the same: get the question routed to a cited, current answer before you build anything on top of it, not after you've already shipped a number that was wrong in a way nobody flagged.

Next in the series: ARA vs. ABA, which dashboard actually answers which question.

Listing Suppression Diagnosis: Stranded or Buyable

2026-07-30T00:00:00Z

Create this workflow as a reusable Skill called silent-asin-diagnosis. It reads live BUYABLE and DISCOVERABLE status through the Selling Partner MCP, uses Amazon Agent Atlas to interpret the exact suppression or stranded-inventory rule, and returns the reason-specific fix plus its deadline before anyone edits the listing. I start there when a top ASIN suddenly has no orders or impressions. Search suppression, a non-buyable offer, a block, a deletion, and stranded Fulfillment by Amazon (FBA) stock can look identical from the sales graph, but each demands a different repair.

A plain ChatGPT or Claude conversation hits three walls: no access to your data, including the live SKU, ListingsItemStatus, FBA units, listing issues, or current report; no way to take action, such as requesting evidence or applying an approved fix; and generic knowledge, not Amazon's exact reason fields and deadlines. You must paste disconnected snapshots, expose account data, and carry out every step yourself. Connected AI clients get past those walls through the MCP's reads and actions, Atlas-grounded rules, reusable Skills, and the Amazon Agent Data layer that records the decision.

Live state	Diagnosis	Next evidence
`BUYABLE` + `DISCOVERABLE`	Listing is live	Diagnose traffic and demand
`BUYABLE`, not `DISCOVERABLE`	Search suppressed	Pull reason and issues
Not `BUYABLE`; FBA units	Possible stranded stock	Confirm no active offer
Not `BUYABLE`; no stranded units	Offer-side failure	Check quantity, window, restrictions

`BUYABLE` and `DISCOVERABLE` separate suppression from stranding

When a listing is search suppressed, Amazon removes discoverability but can leave the offer buyable; stranded inventory is FBA stock in a fulfillment center that does not have an active offer. That distinction is the first branch, not a semantic detail.

The Skill reads ListingsItemStatus, whose relevant values are BUYABLE, DISCOVERABLE, and DELETED. BUYABLE without DISCOVERABLE points to search suppression. An absent BUYABLE status establishes that the offer is not buyable, but it does not establish stranding until the agent also finds FBA units and no active offer. If both status flags are healthy, I move the investigation away from catalog repair.

The suppression reason chooses the repair

GET_MERCHANTS_LISTINGS_FYP_REPORT contains only suppressed listings, the reason for each suppression, and instructions for removing it. It can be requested for a current investigation or scheduled for continuous monitoring.

I use the report to identify the affected SKU, then add its live listing issues to the evidence. The Suppressed Listings Management playbook routes the result through Fix Your Products: image failures go to image requirements, missing attributes expose the absent value, and newly required compliance attributes get patched directly. Rewriting unrelated copy or adding stock does not repair those causes.

The bulk report is not real-time proof. Later report calls can be 1 to 6 hours old, and the stock-data freshness commitment is three hours, so the Skill pairs that evidence with the live listing read before proposing a patch.

The stranded reason chooses relist, restore, or removal

Stranded reason determines whether the operator should relist the SKU, restore an offer, correct price or condition, fix the fulfillment channel, or remove the units. The Fix stranded inventory page is the most accurate source when Manage Inventory and stranded status disagree. Until the active offer returns, those FBA units cannot sell and continue to accumulate storage fees.

The Resolve stranded inventory issues playbook reads Stranded reason and the accompanying Additional information or Recommendations. Common evidence includes a missing listing, a missing price or condition, or a merchant-fulfilled listing attached to FBA units. For a catalog-wide repair, the same playbook uses the Bulk Fix Stranded Inventory workflow.

The clock matters. If the seller does not create a listing or order removal within 30 days of Amazon's notice, Amazon designates the inventory unsellable and it must be removed. The deadline begins with Amazon's notice, not with the day I diagnose it.

A repair is complete only when status returns

A submitted change is not a completed repair. Suppression closes when discoverability returns; stranded stock closes when buyability and an active offer return.

The Skill watches LISTINGS_ITEM_STATUS_CHANGE, schedules GET_MERCHANTS_LISTINGS_FYP_REPORT, and re-reads the affected SKU after Amazon's processing window. It records the branch, approved action, evidence, and stranded deadline in the run log. If BUYABLE and DISCOVERABLE are both healthy but demand is still absent, the workflow hands the ASIN to the Amazon Ads MCP instead of misclassifying a traffic problem as a listing problem.

What happens next

I route the completed diagnosis to one owner. Product-data issues go to the team approving an image, attribute, or compliance patch. Offer and FBA issues go to the inventory team with the reason-specific action packet. A healthy listing with no demand moves to the advertising team with its catalog state already cleared.

That handoff can run as one recurring Skill through Amazon Agent Flow, so each new silent-ASIN alert arrives with its evidence and owner instead of becoming another unclassified ticket.

The pattern is status, reason, scoped action, and verified return. That keeps a silent ASIN from turning into an expensive guess.

Next, use the listing audit-to-patch guide to turn a verified attribute issue into the smallest safe catalog change.

The Agent Bidding Rulebook That Prevents Bid Thrash

2026-07-26T00:00:00Z

A bidding rulebook stops thrashing when a bid can only move after three independent gates agree: the n-gram clears data sufficiency, its ACoS sits outside a deadband around target, and the resulting change fits inside a hard daily clamp. That is the whole answer. I handed the question to our agent, which runs it as a Skill over the Amazon Ads MCP, grounded by Amazon Agent Atlas in two corpus playbooks: the Keyword Analysis Decision Framework (N-Grams) and the Sponsored Ads Bidding Configuration Decision Framework. The question that sent me looking came from our PPC lead, in Slack, on a Tuesday: every tool she had used either overcorrected or undercorrected, and she wanted to know what a sane rulebook actually looks like underneath.

Ask a plain ChatGPT or Claude chat and you hit three walls on any Amazon job. It has no access to your data: it cannot read your search-term report, your ad group configuration, or your trailing 30-day spend, so you paste a CSV that is stale the moment you paste it. It has no way to take action: it cannot change a bid, set a placement multiplier, or add a negative, so the most you get is text you retype into Campaign Manager by hand. And it runs on generic public knowledge, not Amazon's: it will produce thresholds that sound right and are not. The result is disconnected, generic, manual work that ships silent mistakes into a live account. The Amazon Ads MCP supplies your data and the tools to act on it, Atlas supplies the private rule book, and the Skill supplies the bounded workflow that keeps the two honest.

Thin data gets a hold, not a bid change

Most thrash is not a bad threshold, it is a threshold applied to a sample too small to mean anything. The rulebook gates on sufficiency before any rule is allowed to evaluate. For 1-grams that means IMP_g >= 50 and either CLK_g >= 10 or ORD_g >= 2. Longer n-grams need proportionally more: 2-grams require IMP_g >= 100, 3-grams IMP_g >= 150, with the same click-or-order condition.

There is a second gate one level up, at the ad group. The starvation guard in the Sponsored Ads Bidding Configuration Decision Framework holds everything when CLK_l30d < 50 and ORD_l30d < 5. The prescribed action is hold_thin_data with no destructive change, and the advice is to consolidate or extend the observation window rather than act early. An agent that respects both gates spends most of its first run reporting that it is not going to do anything yet.

Scale and pull-back fire at fixed distances from target

This is the part that actually prevents thrash. The scale rule and the pull-back rule do not trigger at target ACoS, they trigger at fixed distances on either side of it, leaving a gap where nothing happens at all.

A scale decision needs ORD_g >= 10 and ACOS_g <= 0.9 x TARGET_ACOS, and produces increase_bid at +5 to 10% on keywords containing that n-gram. A pull-back needs ORD_g >= 10 and ACOS_g > 1.1 x TARGET_ACOS, and produces decrease_bid at -10%, plus a 10% reduction to the Top-of-Search multiplier if one is in use. Both re-evaluate in 5 days.

Between 0.9x and 1.1x of target, no bid rule fires. That deadband is the single most load-bearing number in the rulebook. A bidder without one sits exactly at target and oscillates forever, correcting every run in whichever direction last week's noise pointed.

Condition	Action	Re-eval
`ORD_g >= 10`, `ACOS_g <= 0.9x target`	`increase_bid` +5 to 10%	5 days
`ORD_g >= 10`, `ACOS_g > 1.1x target`	`decrease_bid` -10%	5 days
ACoS inside the deadband	none	next run
`ROAS_g >= target`, impressions bottom quartile	`increase_bid` +5 to 8%, TOS +10%	5 days

Every lever is clamped before it ships

Gates decide whether a rule fires. Clamps decide how far it can go when it does. The global controls are short enough to memorize: a daily bid change clamp of plus or minus 20%, a Top-of-Search placement cap of 1.50, and a standard review window of 5 days for Ads and 7 to 14 days for Organic and Ops work.

The clamp matters most in the case where the rulebook is most confident. An n-gram at half of target ACoS with 200 orders is a genuinely strong signal, and the temptation is to move the bid a long way at once. The clamp refuses. Twenty percent per day, then look again in five days. Every decision record the agent emits carries its own max_change_pct and cooldown_days, the latter defaulting to 5 to 14 depending on the action type, so the bounds travel with the decision rather than living in a settings page nobody re-reads.

{
  "decision_category": "scale_winner",
  "action_id": "increase_bid",
  "action_scope": ["ADS"],
  "selector": { "ngram": "stainless steel", "n": 2, "match_type": "phrase" },
  "magnitude_pct": 8,
  "max_change_pct": 20,
  "cooldown_days": 5,
  "confidence": "high",
  "reason": "ORD_g=31, ACOS_g=0.19 <= 0.9 x TARGET_ACOS(0.25); sufficiency met",
  "badges": { "data_sufficient": true, "cooldown_ok": true, "thin_data_reason": null }
}

Precedence decides which rule wins

Real accounts produce conflicts. A keyword can look wasteful on one metric and efficient on another, and two rules will match the same entity in the same run. Rather than letting whichever rule evaluated last take the entity, the framework fixes an order: invalid computations first, then thin data, then safety negatives, then pull back, then scale, then mining and hygiene, and creative or ops work last.

The tiebreak is explicit and conservative. When a rule suggests both scale and pull-back, prefer pull-back, unless credible intervals support scaling with high confidence. That is where the reliability layer earns its place: the recommended signals are Bayesian credible intervals at 95%, Beta for CTR and CVR, Gamma for spend and revenue ratios, alongside recency weighting with a 14-day half-life and peer medians computed with trimming. The interval, not the point estimate, is what lets a scale decision beat a pull-back decision.

What happens next

The output is a decision plan, not an applied change. Each record names the entity, the bounded action, the clamp, the cooldown, and the reason it fired, which makes it reviewable before anything reaches the account. That review step is the same pattern as a human approval gate on Amazon Marketing Cloud activation: the agent assembles the artifact, a person signs it, the platform ships it.

Once a plan is approved, the review windows do the pacing. Ads actions re-evaluate in 5 days, Organic and Ops in 7 to 14, and each record's cooldown_days prevents the next run from touching an entity still inside its window. Wired as a recurring Skill over the Amazon Agent Data layer, the agent reads a fresh rollup, skips everything on cooldown, and emits a much shorter plan the second week. A rulebook that is working produces fewer decisions over time, not more. The Selling Partner MCP covers the catalog side of the same account when a decision turns out to be a listing problem rather than a bidding one.

The pattern is worth stating plainly: bounded actions with explicit gates beat continuous optimization because they are auditable, and an agent that can explain why it did nothing is more trustworthy than one that always has a change to make.

Next: the data-mode router, and why computing ACoS on organic search-query data is the fastest way to poison a rulebook.

Recover Featured Offer Eligibility Without Guessing

2026-07-25T00:00:00Z

The fastest way to recover a missing Featured Offer is to identify the failed gate first: account eligibility, price health, or competition among eligible offers. The agent reads the live Fulfillment by Amazon (FBA) inventory offer for the Amazon Standard Identification Number (ASIN) through the Amazon Selling Partner MCP, applies a reusable Skill, and uses Amazon Agent Atlas to ground the diagnosis in Amazon's Featured Offer rules. The same evidence can flow through Amazon Agent Flow and the Amazon Agent Data layer when the recovery check spans selling and advertising signals.

That distinction matters because “we lost the Buy Box” describes two different situations. An offer can be ineligible before Amazon ranks it, or it can be eligible and still lose the placement to another offer. Amazon also announced a gradual July 2026 rollout removing the seller-eligibility step, so a historical rule cannot be treated as universal across every store yet. If the offer's demand context matters, the Amazon Ads MCP can add campaign-side evidence without turning a plain chat into a live data connection.

Why not ask ChatGPT or Claude? A disconnected chat has no access to your data, no way to take action, and generic knowledge, not Amazon's. It cannot read the live offer, inspect a PRICING_HEALTH notification, or verify which eligibility rollout applies to your store. The human can paste facts into a chat, but the result is still manual and easy to misclassify. The workflow below keeps the MCP, Skill, Atlas, and your approval step connected.

Eligibility is a gate, not proof of placement

The first check is whether Amazon currently allows the offer to compete. The Atlas-grounded Featured Offer Eligibility playbook says a Professional selling account and performance-based requirements have historically been part of that gate, while Amazon's July 2026 announcement says the seller-eligibility step is being removed gradually. The agent should therefore read the current account state and store rollout status instead of returning a fixed yes/no from old rules.

{
  "asin": "B0EXAMPLE12",
  "account_type": "Professional",
  "store": "US",
  "eligibility_gate": "verify_current_policy",
  "performance_evidence": {
    "status": "read_live_account_metrics",
    "source": "Seller Central account health"
  },
  "rollout_note": "Eligibility rules are changing during the July 2026 rollout"
}

`PRICING_HEALTH` isolates a price-driven ineligibility

When the agent receives PRICING_HEALTH, the immediate question is not “did a competitor undercut me?” Amazon says the notification means the offer is ineligible at its current price, independent of competitor changes. Compare the offer's total price, including shipping, with the Competitive External Price and the referencePrices values such as averageSellingPrice, msrpPrice, and competitivePriceThreshold.

{
  "status": "price_ineligible",
  "notification": "PRICING_HEALTH",
  "total_price": 32.98,
  "competitive_external_price": 29.99,
  "reference_prices": {
    "averageSellingPrice": 30.49,
    "msrpPrice": 34.99,
    "competitivePriceThreshold": 29.99
  },
  "recommended_action": "review price and shipping; approval required"
}

Eligible offers still compete on price, shipping, and experience

Passing the gate does not win the placement. The Atlas playbooks describe the next stage as a competition among eligible offers; Amazon evaluates competitive price and compelling shipping options, and the detail page can show one New and one Used Featured Offer where applicable. The Get to Know the Product Detail Page playbook is the reference for how those offers appear and compete. The recovery artifact should label this state eligible_not_featured, not eligibility_failure.

# Skill: featured-offer-recovery
read:
  - offer: live price, shipping, condition, fulfillment
  - account: current eligibility and performance state
  - notifications: PRICING_HEALTH, ANY_OFFER_CHANGED
compare:
  - total_price_plus_shipping
  - competitive_external_price
  - reference_prices
  - delivery_and_availability
classify:
  - account_gate
  - price_ineligible
  - eligible_not_featured
  - insufficient_evidence

The Skill turns the evidence into a small decision plan. It names the failed gate, cites the notification or account evidence, proposes the narrowest next step, and keeps approval on any price or fulfillment change. If evidence is incomplete, it returns insufficient_evidence instead of guessing. For related operational context, compare the same evidence-first pattern in the FBA inventory health guide and use Agent Crawl only when the workflow explicitly needs current external-market evidence.

{
  "asin": "B0EXAMPLE12",
  "status": "price_ineligible",
  "evidence": [
    "PRICING_HEALTH",
    "total price $32.98 > competitive threshold $29.99"
  ],
  "recommended_action": "review price and shipping options",
  "requires_approval": true,
  "monitor": ["PRICING_HEALTH", "ANY_OFFER_CHANGED"]
}

What happens next

Once the artifact identifies the gate, the team can approve one narrow change, continue monitoring, or route an account issue to Seller Central support. The Skill rechecks PRICING_HEALTH and ANY_OFFER_CHANGED after the decision so a recovered offer is measured instead of assumed.

Featured Offer recovery is a diagnosis problem before it is a pricing problem: verify the gate, read the evidence, then approve the smallest action that addresses it.

Next in the series: diagnosing a listing that is suppressed or stranded before its inventory keeps accruing storage cost.

FBA Inventory Health After the 2024 Fee Change

2026-07-24T00:00:00Z

The post-2024 Fulfillment by Amazon (FBA) inventory playbook is not “stop watching capacity.” It is to separate three signals before the next fee cycle: cubic-foot capacity usage, monthly storage cost, and units approaching the aged-inventory threshold. An agent can run that review through the Amazon Selling Partner MCP as a reusable Skill, grounded by Amazon Agent Atlas so the policy window and report fields are not guessed.

Amazon ended FBA inventory storage overage fees effective July 1, 2024 in the United States, Europe, United Kingdom, and Canada stores. That change does not remove monthly inventory storage fees or the aged inventory surcharge. The operator question is therefore narrower and more useful: which inventory is consuming capacity, which inventory is accumulating storage cost, and which inventory is close to the next age threshold? The same review can join Amazon Standard Identification Number (ASIN) inventory context to the campaign and demand signals available through the Amazon Ads MCP.

Why not just ask ChatGPT or Claude? A disconnected chat has no access to your data, no way to take action, and generic knowledge, not Amazon's. It cannot see your current FBA inventory, retrieve the reports, or apply the store-specific rules that determine which fee is relevant. The workflow below keeps those boundaries explicit: read live data, ground the interpretation, then decide what action deserves approval.

Separate the fee policy from the inventory decision

The first move is a policy check, not a removal recommendation. The FBA Inventory Storage Overage Fees playbook says the overage fee stopped being charged in the named stores on July 1, 2024. The same source still describes monthly storage fees and an aged inventory surcharge as separate charges. Atlas returns that distinction with the retrieval context, so the agent does not collapse “overage fee removed” into “storage is free.”

The output should be a short policy record: store scope, effective date, fee families still in play, and the source playbooks used. That record becomes the explanation for every downstream recommendation.

Measure capacity in cubic feet, not units

Capacity is a volume problem. The report exposes capacity_usage_volume, capacity_limit, overage_volume, and volume_unit; the unit is cubic feet. A unit count can rise while volume stays flat, or a small number of bulky units can create the larger constraint. The agent should read the Capacity Monitor or Inventory Performance view, then reconcile the report fields before ranking action.

inventory_health_snapshot:
  storage_type: oversize
  capacity_usage_volume: 600
  capacity_limit: 500
  overage_volume: 100
  volume_unit: cubic feet
  decision: investigate slow-moving bulky inventory

The useful artifact is not a generic “reduce stock” list. It is a ranked queue by storage type, cubic-foot contribution, velocity, and removal or replenishment option. Keep volume_unit attached to every number so a later operator does not mistake volume for units.

Review monthly storage separately

Monthly storage fees remain a distinct operating signal after the overage-fee change. Review the Monthly Storage Fee report by ASIN, then identify the SKUs whose storage cost is persistent without a matching sell-through or replenishment need. Atlas retrieval also surfaces storage-utilization surcharge and AWD waiver context, so the agent can mark a fee as a policy exception rather than treating every charge as a capacity breach.

This is where the operator separates diagnosis from action. A high monthly storage charge may justify a sell-through, liquidation, return, or replenishment change, but the action belongs after the evidence review. The Skill should present the report rows, the decision rule, and the expected trade-off together.

Catch aged inventory before the fifteenth-day snapshot

The aged inventory surcharge applies to units stored 181 days or longer and is assessed using an inventory snapshot on the fifteenth day of each month. The FBA Inventory tool can show inventory that is already subject or will become subject within 60 days. The review should therefore sort by days-to-threshold, cubic-foot exposure, and available action window.

next_snapshot: 2026-08-15
asin: B0EXAMPLE12
age_days: 176
days_to_181_day_threshold: 5
per_unit_volume: 0.102 cubic feet
recommended_review: removal, sell-through, or return economics

The Aged Inventory Surcharge report is the evidence layer after the decision. It provides itemized SKU quantities, per-unit volume, surcharge tier, and amount charged. Keep the pre-snapshot queue and the post-charge report together so the team can compare the avoided cost with the action it chose. For a related report-driven workflow, see FBA order and report review.

What happens next

Run the review on a schedule: policy check first, capacity volume second, monthly storage third, and aged-inventory countdown last. The agent should return a compact report with source playbooks, report fields, affected ASINs, and proposed actions. A human then approves removals, returns, liquidation, or replenishment changes through the Selling Partner MCP. The Amazon Agent Data layer keeps the policy context attached to the decision, and the Amazon Agent Flow can carry the approved workflow forward.

If your FBA review still asks only whether the overage fee exists, it is looking at one policy line instead of inventory health. Separate volume, storage, and age, then decide with the evidence in front of you.

Next in the series: turning the same age and volume queue into a controlled removal recommendation without losing the audit trail.

Find ASIN Margin Leakage with Net PPM

2026-07-20T00:00:00Z

Run an Amazon Standard Identification Number (ASIN)-level Net PPM comparison, rank each negative rate contribution, then decompose the largest drags into shipped COGS/PCOGS, CCOGS, and sales-discount pressure where the connected report exposes those fields. The ranking is Kuudo-derived, not an Amazon metric. Amazon's dashboard identifies products driving profitability up or down after costs, funding, and discounts.

That answers my question: "Our Vendor Central revenue looks fine but margin is sliding. Which ASINs are actually dragging down our pure product margin?" Revenue cannot show which equation term changed. The report must answer materiality first, then cause where the component fields support it.

Question	Test	Report output
Biggest drag?	Rate-leakage proxy	Ranked ASINs
Cost pressure?	PCOGS/revenue up	Cost flag
Funding pressure?	CCOGS/revenue down	Funding flag
Discount pressure?	Discounts/revenue up	Discount flag

The rate-leakage proxy and driver tests are Kuudo-derived from the sourced equation. Amazon does not name these fields.

A plain ChatGPT and Claude chat hits three walls: No access to your data, No way to take action, and Generic knowledge, not Amazon's. Selling Partner MCP supplies vendor-account context, a Skill produces the repeatable report and review queue, and Amazon Agent Atlas supplies the metric definitions, access rules, exclusions, and timing caveats. Without those pieces, the work stays disconnected, generic, and manual, which ships silent mistakes.

The Net PPM dashboard identifies products driving profitability up or down

The Net PPM dashboard identifies products that raise or lower profitability. It lives in Amazon Retail Analytics, which Amazon's reports index separates from Brand Analytics. An ABA customer or search dashboard is not the source.

The retrieved Amazon Retail Analytics and Reports Overview defines Net PPM around cost of goods, vendor funding, and sales discounts. That keeps the Skill focused on profitability instead of treating revenue as a margin answer.

Run field	Bound value
Skill	`vendor-net-ppm-margin-leakage`
Input	Account and two periods
Scope	Selected ASIN set
Connector	Selling Partner MCP
Grounding	Atlas `amazon_vendors`
Output	`analysis_report`

Report header	Recorded value
Report	ASIN Net PPM analysis
Vendor scope	Connected account or group
Marketplace	Connected marketplace
View	Manufacturing
Current period	Selected closed period
Comparison period	Selected comparable period
Data as of	Close and refresh status
Warehouse Deals	Excluded
Material move	`{{material_ratio_move_pp}}` pp
Residual tolerance	`{{residual_tolerance_pp}}` pp

The report renders its executive answer instead of hiding it in a notebook:

Executive result	Bound result
ASINs reviewed	`{{asins_reviewed}}`
Negative PPM changes	`{{negative_change_count}}`
Top-five leakage share	`{{top_five_leakage_share}}`
Largest flagged driver	`{{largest_driver}}`
Boundary warnings	`{{boundary_warnings}}`

Only the connected run populates those values. When a component field is unavailable, the executive answer keeps the ASIN ranking and marks the driver analysis incomplete.

Net PPM separates revenue, PCOGS, CCOGS, and sales-discount pressure

Net PPM separates four signed components, so each available ratio's direction supports a first-pass driver flag. The normalized equation is:

Net PPM =
  (shipped revenue
   - shipped COGS [PCOGS]
   + CCOGS
   - sales discounts)
  / shipped revenue

The Amazon Retail Analytics Metric Glossary defines Shipped COGS as Amazon's item procurement price, also called Product Cost of Goods Sold (PCOGS). Contra-COGS (CCOGS) is vendor funding collected for agreements tied to purchases, customer sales, or marketing.

CCOGS includes Vendor Allowance, Quick Pay Discounts, and Discretionary COOP, but excludes display-ads Contra-COGS. One glossary rendering says "shipped CCOGS" in the subtraction term. The report normalizes it to shipped COGS/PCOGS because CCOGS is separately defined as the added funding term.

Type	Report field	Meaning
Observed	Shipped revenue	Shipment-item price
Observed	Shipped COGS/PCOGS	Amazon procurement cost
Observed	CCOGS	Collected vendor funding
Observed	Sales discounts	Discount formula term
Derived	PCOGS ratio	PCOGS divided by revenue
Derived	CCOGS ratio	CCOGS divided by revenue
Derived	Discount ratio	Discounts divided by revenue

The run records a material-move threshold and a residual tolerance. Those are operator inputs, not Amazon thresholds.

Driver flag	Derived rule	Interpretation
PCOGS pressure	Cost magnitude clears threshold	Procurement cost drag
Funding pressure	Funding magnitude clears threshold	Less vendor funding
Discount pressure	Discount magnitude clears threshold	More sales discount
Mixed	Two magnitudes clear threshold	Shared cause
Unclassified	No clear or complete cause	Check scope or rounding

Each component effect is signed: a negative value reduces Net PPM. Its pressure magnitude is max(-component_effect_pp, 0). A single-driver label requires exactly one pressure magnitude greater than or equal to {{material_ratio_move_pp}} percentage points, and that magnitude must be the largest. Mixed requires two or more pressure magnitudes to clear the same threshold. Unclassified covers a missing component, no magnitude that clears the threshold, or an absolute residual greater than {{residual_tolerance_pp}} percentage points. The output records both inputs beside every label so another run can reproduce the classification.

A rate-leakage proxy ranks material ASIN deterioration before investigation

Holding current revenue constant and multiplying it by a negative Net PPM rate change prioritizes ASINs with material sales and worsening margin. A large swing on a tiny ASIN cannot automatically outrank a larger drag.

Kuudo-derived calculations, not Amazon metrics

net_ppm_delta_pp
  = current_net_ppm_pct - prior_net_ppm_pct

current_margin_dollars_proxy
  = current_shipped_revenue * current_net_ppm_pct / 100

rate_leakage_dollars_proxy
  = current_shipped_revenue
    * max(prior_net_ppm_pct - current_net_ppm_pct, 0)
    / 100

pcogs_ratio_delta_pp
  = current_pcogs_ratio_pct - prior_pcogs_ratio_pct

ccogs_ratio_delta_pp
  = current_ccogs_ratio_pct - prior_ccogs_ratio_pct

discount_ratio_delta_pp
  = current_discount_ratio_pct - prior_discount_ratio_pct

pcogs_effect_pp
  = -pcogs_ratio_delta_pp

ccogs_effect_pp
  = ccogs_ratio_delta_pp

discount_effect_pp
  = -discount_ratio_delta_pp

component_pressure_magnitude_pp
  = max(-component_effect_pp, 0)

explained_delta_pp
  = pcogs_effect_pp + ccogs_effect_pp + discount_effect_pp

residual_delta_pp
  = net_ppm_delta_pp - explained_delta_pp

Holding revenue constant isolates rate deterioration from volume. The dollar fields are prioritization proxies, not booked loss, reimbursement value, or Amazon-calculated fields. Rounding and unavailable components can prevent reconciliation.

The report sorts rate_leakage_dollars_proxy descending and fills five rows from the connected periods. The bindings contain no sample ASINs or percentages.

Rank	ASIN	Current revenue	Prior revenue	Prior PPM	Current PPM	Delta	Leakage
1	`{{rank_1_asin}}`	`{{rank_1_revenue}}`	`{{rank_1_prior_revenue}}`	`{{rank_1_prior_ppm}}`	`{{rank_1_current_ppm}}`	`{{rank_1_delta_pp}}`	`{{rank_1_leakage}}`
2	`{{rank_2_asin}}`	`{{rank_2_revenue}}`	`{{rank_2_prior_revenue}}`	`{{rank_2_prior_ppm}}`	`{{rank_2_current_ppm}}`	`{{rank_2_delta_pp}}`	`{{rank_2_leakage}}`
3	`{{rank_3_asin}}`	`{{rank_3_revenue}}`	`{{rank_3_prior_revenue}}`	`{{rank_3_prior_ppm}}`	`{{rank_3_current_ppm}}`	`{{rank_3_delta_pp}}`	`{{rank_3_leakage}}`
4	`{{rank_4_asin}}`	`{{rank_4_revenue}}`	`{{rank_4_prior_revenue}}`	`{{rank_4_prior_ppm}}`	`{{rank_4_current_ppm}}`	`{{rank_4_delta_pp}}`	`{{rank_4_leakage}}`
5	`{{rank_5_asin}}`	`{{rank_5_revenue}}`	`{{rank_5_prior_revenue}}`	`{{rank_5_prior_ppm}}`	`{{rank_5_current_ppm}}`	`{{rank_5_delta_pp}}`	`{{rank_5_leakage}}`

I would not hand operations a rank-only table. The same rows continue into the causal review and ownership queue:

ASIN	Cost effect	Funding effect	Discount effect	Residual	Driver
`{{rank_1_asin}}`	`{{rank_1_pcogs_effect}}`	`{{rank_1_ccogs_effect}}`	`{{rank_1_discount_effect}}`	`{{rank_1_residual}}`	`{{rank_1_driver}}`
`{{rank_2_asin}}`	`{{rank_2_pcogs_effect}}`	`{{rank_2_ccogs_effect}}`	`{{rank_2_discount_effect}}`	`{{rank_2_residual}}`	`{{rank_2_driver}}`
`{{rank_3_asin}}`	`{{rank_3_pcogs_effect}}`	`{{rank_3_ccogs_effect}}`	`{{rank_3_discount_effect}}`	`{{rank_3_residual}}`	`{{rank_3_driver}}`
`{{rank_4_asin}}`	`{{rank_4_pcogs_effect}}`	`{{rank_4_ccogs_effect}}`	`{{rank_4_discount_effect}}`	`{{rank_4_residual}}`	`{{rank_4_driver}}`
`{{rank_5_asin}}`	`{{rank_5_pcogs_effect}}`	`{{rank_5_ccogs_effect}}`	`{{rank_5_discount_effect}}`	`{{rank_5_residual}}`	`{{rank_5_driver}}`

ASIN	Investigation note	Owner	Evidence request
`{{rank_1_asin}}`	`{{rank_1_note}}`	`{{rank_1_owner}}`	`{{rank_1_evidence}}`
`{{rank_2_asin}}`	`{{rank_2_note}}`	`{{rank_2_owner}}`	`{{rank_2_evidence}}`
`{{rank_3_asin}}`	`{{rank_3_note}}`	`{{rank_3_owner}}`	`{{rank_3_evidence}}`
`{{rank_4_asin}}`	`{{rank_4_note}}`	`{{rank_4_owner}}`	`{{rank_4_evidence}}`
`{{rank_5_asin}}`	`{{rank_5_note}}`	`{{rank_5_owner}}`	`{{rank_5_evidence}}`

If components are unavailable, the rank still ships, the driver reads Unclassified, and the queue requests the missing evidence rather than fabricating a cause.

Manufacturing-view access and Warehouse Deals exclusions define the report boundary

ARA access does not guarantee Net PPM access. All vendors have Sourcing views; manufacturers also receive a Manufacturing view for ASINs they manufacture. Amazon displays Traffic, Net PPM, and Forecasting only to manufacturers. If an eligible manufacturer cannot see Net PPM, contact retail partners or open a Contact Us case.

Amazon's wording says Brand Analytics, including ARA, excludes Warehouse Deals because vendors do not collect the proceeds. Retail-partner tools may include those sales, so a vendor-facing and internal number can legitimately differ.

Boundary check	Report status	Next step
View	Manufacturing required	Check entitlement
Period	Closed and populated	Rerun after refresh
Data as of	Status recorded	Avoid instant-data claim
Warehouse Deals	Excluded consistently	Reconcile internal scope
Metric labels	PCOGS differs from CCOGS	Re-map before ranking
Derived fields	Explicitly labeled	Keep separate from Amazon

Amazon aims to update weekly reports within 72 hours, but reports can take up to a week after period close. The report records its period and as-of status instead of calling the data instantaneous.

The provenance footer records exact evidence instead of counts:

Evidence type	Identifier
Source ref	`3dff9404cf730721`
Source ref	`42c4d79b31a1eefd`
Source ref	`285ce9ce068d666c`
Content hash	`f334dd577810b7ca`
Content hash	`647fba2b2a4cc729`
Content hash	`927f70d802757798`
Content hash	`2d8af27996d3f246`
Content hash	`8e9bd73e5f629c0a`
Content hash	`33460c203219fb4b`
Content hash	`5dde3db908638908`

It also records Atlas collection amazon_vendors, corpus version 794a9c3de8380dfa, connected periods, run timestamp, and the exact titles Amazon Retail Analytics and Reports Overview, Amazon Retail Analytics Metric Glossary, and Vendor Reports and Analytics Overview. Derived prioritization fields remain labeled as non-native Amazon metrics.

What happens next

Turn the ranked report into an investigation queue, not an automatic commercial decision. Review the top ASINs and, where PCOGS, CCOGS, and sales-discount fields are exposed, confirm the largest component effect. When they are not, preserve the rank, mark the driver unclassified, and request the missing evidence. Then assign an owner. Run the workflow on closed, comparable periods and preserve the as-of status.

If Warehouse Deals or an internal retail-partner scope explains a mismatch, flag the row for reconciliation instead of rewriting the vendor-facing metric. Amazon did not supply remediation thresholds or an automatic action policy in the retrieved material, so the operator reviews the evidence before changing terms or escalating.

The Amazon Agent Data layer combines Amazon Ads MCP, Selling Partner MCP, Amazon Agent Atlas, and Skills so the report can be grounded, rerun, reviewed, and handed to an operator as one workflow.

Revenue can stay stable while ASIN economics deteriorate; a sourced Net PPM decomposition turns that ambiguity into a ranked investigation queue.

Next, use the same evidence-first pattern when disputing PO on-time accuracy chargebacks.

Brand Registry: Fix 'Trademark Already Enrolled'

2026-07-16T00:00:00Z

The "trademark is already enrolled" error is a role-request problem, not an enrollment problem: someone already holds the Administrator role for your brand, and the fix is getting added as an additional user, not filing again from scratch. Our agent produced that answer, and the resolution plan behind it, by running a Skill on the Selling Partner MCP, grounded in the Brand Registry rules Amazon Agent Atlas retrieves.

That plan exists because of a message from our brand manager: "We're trying to enroll our brand in Amazon Brand Registry and getting the 'trademark is already enrolled' error. What do we do?" Nobody on the team had enrolled anything; the person who set the brand up left last year. So I asked the agent before anyone opened a support case blind.

Why not just paste the error into ChatGPT or Claude? A plain chat hits three walls on any Amazon job. No access to your data: it can't see who holds the brand or where your application stands. No way to take action: it can't file anything on Amazon; you drive every screen. Generic knowledge, not Amazon's: it answers from public training data, not Amazon's current role rules. That's disconnected, generic, manual work that ships silent mistakes. The MCP reads the live state, the Skill runs the decision tree, and Atlas supplies the rule book.

"Trademark is already enrolled" means an Administrator already exists, and the fix is becoming an additional user

The first thing the Skill pulled was the rule the error actually points at. Atlas retrieves it from the Brand Registry FAQ playbook in the amazon_sellers corpus: if a trademark is already enrolled in Brand Registry, you contact the brand's Administrator and request to be added as an additional user. An Administrator always exists: the Brand Registry Protection Roles playbook says the user who enrolls a brand is automatically assigned the Administrator and Rights Owner roles, and only Administrators can assign roles to others. Three protection roles exist in total, Administrator, Rights Owner, and Registered Agent, and the last two are mutually exclusive. Amazon's own routing for this message is its Brand Registry Access: Troubleshooting Guide; the fix mechanics live in the FAQ and role playbooks the agent retrieved. The diagnosis: not a trademark dispute, not a second enrollment. A role request, aimed at whoever enrolled first.

In plain ChatGPT or Claude

No access to your data. ChatGPT can't see whether your trademark number is already enrolled in Brand Registry or under whose account; you only discover the conflict when the enrollment flow throws the error. The MCP-connected agent reads the live state before you burn an application.
Generic knowledge, not Amazon's. Ask Claude about the error and it reaches for trademark-office advice: dispute the mark, call your attorney. The grounded answer is a role request to the existing Administrator, a rule that lives in Amazon's documentation, not public training data.
And your data is now exposed. To get even the wrong answer, you pasted your trademark number and account details into a chat history you don't control. The MCP reads them over an authorized connection, and they stay inside your account.

Branch one is the shortcut: if you know the identity of a current Administrator, reach out to them directly and request an invitation to the brand. On their side the flow is Invite a user to your brand, then Send invitation, and you have to accept the invitation before anything changes. We had no name to call, which is the branch the Brand Registry FAQ covers next: if you're unsure who to contact, or the current Administrator is inactive, you can continue to apply for Brand Registry with the same trademark. If you're an eligible user, the application gives you a step to share your contact information with the Administrator. Approval is discretionary by design: an active Administrator will use that information to add your Brand Registry account to the brand, if they choose to do so. The Brand Registry Protection Roles playbook shows where the request lands: in the Administrator's User Permissions tool under Access requests, where they approve or decline each request at their discretion.

The Skill assembled all of it into the decision plan, every branch traced to a retrieved rule:

decision_plan:
  trigger:
    error_message: "Trademark is already enrolled"
    surface: "Brand Registry enrollment flow"
  facts_to_gather:
    - administrator_known: "Do you know the identity of a current Administrator?"
    - administrator_active: "Is that Administrator active and reachable?"
    - other_brand_enrolled: "Do you have another brand enrolled in Brand Registry?"
  branches:
    - id: administrator-known-active
      condition: "You know a current Administrator and they are active"
      action: "Reach out directly and request an invitation as an additional user"
      admin_side: "Invite a user to your brand > Send invitation; you accept it"
      outcome: "Added to the brand with the assigned protection role"
    - id: administrator-unknown
      condition: "Unsure who the Administrator is, or cannot reach them"
      action: "Continue to apply with the same trademark"
      during_flow: "Share your contact information (step shown to eligible users)"
      admin_side: "Request lands in User Permissions > Access requests"
      decision_rule: "Approved or declined at their discretion (if they choose to do so)"
      outcome_if_approved: "Your Brand Registry account is added to the brand"
      outcome_if_no_response: "Fall through to administrator-inactive"
    - id: administrator-inactive
      condition: "No active Administrator (inactive, or left the company)"
      paths:
        - id: appeal-form
          entry: "Same flow: a warning links to the Share Contact Information form"
          action: "Click 'use this form'; the bottom link opens Appeal Submission"
          gate: "Appeal Submission link is visible only to eligible users"
          outcome: "Success adds you with Administrator and Rights Owner roles"
        - id: brand-registry-support
          gate: "One other enrolled brand plus Brand Registry site access"
          action: "Open a case; select 'Update brand ownership' as the topic"
          outcome: "Request reviewed; response follows"
  while_waiting:
    review_sla: "Average 10 business days; identity checks can extend it"
    deadlines:
      - "Complete the application within three days or it shows Expired"
      - "Reply to the case within 10 days with the verification code and case ID"
    watch: "Brand applications page for status changes"
    statuses: [Approved, Rejected, Pending submission, Expired, Ineligible,
      Pending review, Withdrawn, Removed from Brand Registry]
    if_rejected: "Rejected can't be edited: click Copy, correct, resubmit"

An inactive Administrator opens two escalation paths: the "use this form" appeal and an "Update brand ownership" support case

If the Administrator is inactive, the FAQ's instruction is literal: click use this form to submit your request form. The label undersells what's behind it. You re-enter the already-registered trademark number during the application, a warning appears offering a link to a form for sharing your contact information, and that link opens the Share Contact Information form. At the bottom of that form sits one more link, available only to eligible users, leading to an Appeal Submission form. Neither playbook defines who counts as eligible, so if you've hunted for the appeal form and never found it, that gate is why. When an appeal succeeds, you're added to the brand with the Administrator and Rights Owner roles, which makes you the brand's new front door.

There's a parallel escalation path with its own gate. If you have at least one other brand already enrolled in Brand Registry and you can access the Brand Registry site, you can submit the request through Brand Registry Support and select Update brand ownership as the topic. Amazon asks that you identify the nature of the error before contacting support, and that's exactly the triage the plan encodes: it checks the gates and routes you to the path your account qualifies for, instead of letting you file a case that bounces.

Once you reapply, the clock is Amazon's: 10 business days of review, a 3-day completion deadline, a 10-day reply window

Reapplying starts a review that takes an average of 10 business days, and Amazon may need additional information to verify your identity, which can extend the review period. Two more deadlines ride along, both pulled from the Brand Registry Application Process playbook and both easy to miss. An application that isn't completed within three days flips to Expired. And when Amazon sends a verification code, you reply to the case within 10 days with the code and the case ID. Those are two different tens: ten business days is how long Amazon takes on average; ten days is how long you get to reply.

Every application surfaces on the Brand applications page with one of eight statuses: Approved, Rejected, Pending submission, Expired, Ineligible, Pending review, Withdrawn, or Removed from Brand Registry. A rejected application can't be edited. You locate it on the Brand applications page, click Copy, correct the details, and resubmit. Before that resubmission, the Skill runs the decline-reason pre-checks from the Manage Brand Registry Application Issues playbook: expired trademarks aren't eligible, supplemental trademarks aren't accepted (the Principal Register is required), and Amazon currently accepts only text-based marks or image-based marks with words, letters, or numbers.

What happens next

The plan isn't a document the agent hands over and forgets; it's a watch list. The agent monitors the Brand applications page through the Selling Partner MCP and reports status changes instead of letting the team infer them from silence. It flags the three-day completion deadline the moment an application sits in Pending submission, and it counts down the 10-day verification-code window against the case ID so the reply goes out with days to spare. If the outreach branch stalls with no Administrator response, the plan falls through to the appeal branch instead of waiting for someone to remember.

The complete workflow runs through the Amazon Agent Data layer: the Selling Partner MCP supplies the live Brand Registry and application state, Amazon Ads MCP covers the advertising side of the same account when it's needed, and Atlas grounds every branch of the plan. Scheduled as a recurring Skill, the same triage re-runs until the application lands on Approved, and every Amazon-facing step, the outreach message, the appeal submission, waits for a person to say yes, the gate pattern from human approval for agent activation. That's the whole pattern: read the live state first, walk Amazon's real decision tree, and put the deadlines on a clock the agent owns instead of a person's memory.

Next in the series: letting the agent fix a failing listing without editing it blind, the same read-first, approve-before-ship discipline pointed at your live catalog.

Dispute a PO On-Time Accuracy Chargeback

2026-07-13T00:00:00Z

Dispute a PO on-time accuracy chargeback with evidence that directly contradicts Amazon's recorded data, and file it through Operational Performance within 30 days of the notification. The strongest submission is not a long explanation. It names the wrong field, supplies the matching PO or carrier record, and asks Amazon to reverse the specific chargeback.

Situation	Evidence	Route	Deadline
Wrong CRDD or PRO	Appointment or PRO record	Dispute by data	30 days
External event	Event evidence	External exception	30 days
Duplicate amount	Chargeback IDs	Raise dispute	30 days
First refusal	New contrary evidence	Second dispute	30 days

That is the answer to the message that landed in our queue: "Vendor Central just hit us with a PO on-time accuracy chargeback we believe is wrong. How do we dispute it before the 30-day window closes?" I gave the chargeback record and PO context to our agent through the Selling Partner MCP, with Amazon Agent Atlas grounding the dispute rules.

A plain ChatGPT or Claude chat hits three walls. It has no access to your data, so it cannot compare the chargeback with the PO, appointment, or dispute history. It has no way to take action, so a person still has to find the record and submit the response. It has generic knowledge, not Amazon's, so it can confuse this Vendor Central operational chargeback with a consumer payment dispute. The result is disconnected, generic, manual work that ships silent mistakes.

The first dispute is a 30-day evidence deadline, not a support case

Amazon's How to Dispute a Chargeback in Vendor Operational Performance says the initial dispute is due within 30 days of the notification date. If Amazon rejects it, the second dispute is due within 30 days of the first refusal notification. Those are separate clocks, so the agent records both dates instead of treating the first deadline as the whole lifecycle.

Start in Reports > Operational Performance, open the full chargeback list, locate the chargeback ID, and confirm that Dispute this chargeback is available. The same help content limits a chargeback to two disputes. After two rejections, it is no longer eligible, and a Contact Us case cannot substitute for those two dashboard submissions.

The practical rule is simple: preserve the first attempt. Submit the cleanest contrary record you have, keep the dispute ID and attachments together, and reserve the second attempt for new evidence or a precise correction to Amazon's refusal reason.

The evidence must contradict the exact PO on-time data point

Amazon's Vendor Central Chargebacks Support and Policies says PO on-time accuracy covers confirmed products that miss the PO window, including items placed on backorder. The indexed policy measures the prepaid case against the carrier requested delivery date (CRDD). A statement that the shipment was "on time" is weak; an appointment record showing the CRDD inside the delivery window directly contests Amazon's recorded value.

Smart Aggregation gives the agent four routes, and choosing the wrong one can end the review before the evidence is considered.

Problem	Correct route	Core input
Wrong Amazon field	Dispute by data	PRO or contrary value
Severe external event	External exception	Event evidence
Other non-data concern	Non-data problem	Issue explanation
Not in Smart Aggregation	Legacy dispute	Chargeback record

The Vendor Central Chargebacks - Smart Aggregation Dashboard says Dispute by data can validate a core attribute such as a PRO and return a near-real-time indication of whether the evidence is sufficient. External-events exceptions are for circumstances such as severe weather; an unrelated accuracy complaint submitted there is automatically denied. Smart Aggregation is also limited to supported vendors and chargeback types, so the agent falls back to the legacy dashboard when the record is not present.

A useful dispute letter names one error and one contrary record

The agent produced the following dispute letter after matching the chargeback ID, PO, defect field, and attachment names. Keep the merge fields intact until the corresponding record has been verified. Do not submit a field whose evidence you cannot attach.

Subject: PO on-time accuracy dispute for chargeback {{CHARGEBACK_ID}}

We dispute PO on-time accuracy chargeback {{CHARGEBACK_ID}} for
PO {{PO_NUMBER}}, notified on {{NOTIFICATION_DATE}}, in the amount of
{{DISPUTED_AMOUNT}}.

Amazon's chargeback record shows:
- Defect type: {{DEFECT_TYPE}}
- Recorded value: {{AMAZON_RECORDED_VALUE}}

Our source record shows:
- Correct value: {{VENDOR_SOURCE_VALUE}}
- Source: {{SOURCE_SYSTEM_OR_DOCUMENT}}
- Record date: {{SOURCE_RECORD_DATE}}

The attached {{ATTACHMENT_NAME}} ties the PO and shipment to the correct
{{CONTESTED_FIELD}}. It contradicts the value shown in the chargeback record.

Please review the attached evidence and reverse chargeback
{{CHARGEBACK_ID}}. If another field is controlling the decision, please name
that field and its recorded value in the resolution.

For a duplicate, replace the source-record paragraph with both chargeback IDs and state which amount is duplicated. Amazon's Smart Aggregation guidance explicitly says to raise a dispute when duplicate chargebacks appear so the duplicate can be reversed. For a second dispute, lead with the first dispute ID and Amazon's refusal reason, then identify the new evidence that answers that reason.

The letter stays short because the evidence carries the claim. Every sentence either identifies the disputed record, links the contrary evidence to it, or requests a correction.

Smart Aggregation separates previews, confirmed charges, and reversals

The Vendor Central Chargebacks - Smart Aggregation Dashboard surfaces unconfirmed chargebacks in the Processing tab every seven days. Those rows are projections, not invoices. Once confirmed, a chargeback moves to Confirmed. Starting April 30, 2024, Amazon's indexed guidance gives 30 days' notice before invoicing PO on-time accuracy chargebacks.

That preview creates useful working time. The agent can open an evidence task while the item is still processing, pull the PO and carrier references, and flag a likely duplicate before the confirmed amount reaches the dispute queue. Smart Aggregation groups chargebacks at the most granular available attribute, shows the final confirmed amount, and removes duplicates from that view. If a duplicate still appears, the guidance says to dispute it.

The status is part of the workflow. Under review means wait for the dispute team. Reversed means the payment returns in the next payment cycle. Waived means Amazon did not charge it. Charged means the amount was enforced and remains eligible for the dispute process if the button is available.

What happens next

Turn the dispute into a reviewed recurring Skill, not an auto-submit rule. On each seven-day Processing refresh, the Skill identifies new PO on-time records, collects the controlling PO and carrier fields through the Selling Partner MCP, checks the deadline and prior-attempt count, then prepares the letter and attachments for human approval.

The complete workflow runs through the Amazon Agent Data layer: the Selling Partner MCP supplies live PO and catalog context, Amazon Ads MCP supplies the advertising side of the same business when needed, Atlas grounds the chargeback rules, and Skills preserve the evidence and approval trail. The final submission remains a deliberate operator action.

The letter is the last step; the winning work is matching one chargeback data point to one contrary record before the clock expires.

Next, see why MCP workflows need run logs when a reversal, refusal, or second dispute depends on what the agent did the first time.

Measure Off-Amazon Conversions in AMC

2026-07-11T00:00:00Z

Yes, Amazon Marketing Cloud (AMC) can measure DTC web, app, store, and offline conversions once Events Manager receives them through Amazon Ad Tag (AAT), Conversions API (CAPI), or a Mobile Measurement Partner (MMP), the event is defined in the Amazon demand-side platform (DSP), and it is associated with a DSP order. The practical difference from Amazon conversions is the setup and taxonomy: off-Amazon subtypes arrive as numeric codes, purchase sales and non-purchase value mean different things, and the complete history starts on October 20, 2023. I handed the question to our agent through the Amazon Ads MCP, grounded by Amazon Agent Atlas, and asked it to prove each gate before running AMC SQL.

Question	Answer
Can AMC read DTC events?	Yes, through Events Manager
Required ingestion	AAT, CAPI, or MMP
Required DSP setup	Define event; link DSP order
Purchase revenue	`off_amazon_product_sales`
Non-purchase value	`off_amazon_conversion_value`
Total product sales	`combined_sales`
Complete history	`10/20/2023` onward

That answers the Slack question: "We're running DSP ads to our DTC site. Can we measure those conversions inside AMC the same way we measure Amazon conversions?" A plain ChatGPT or Claude chat hits three walls. It has no access to your data, so it cannot inspect the advertiser's Events Manager or AMC instance. It has no way to take action, so a human must copy, validate, and run its SQL. It has generic knowledge, not Amazon's, so it can miss the DSP-order gate, numeric subtype map, or coverage date. That becomes disconnected, generic, manual work that ships silent mistakes. The MCP supplies account access, Atlas supplies Amazon's current rules, and Skills make the checks repeatable.

Events Manager data reaches AMC only after the event is linked to a DSP order

Sending an event to Amazon DSP is necessary but not sufficient. The Introduction to Events Manager instructional query names three prerequisites: set up AAT, CAPI, or MMP; define the event in Amazon DSP; and associate that event with an Amazon DSP order. If the order association is missing, the data does not flow into AMC. The empty result can look like zero customer activity even though the failure is configuration.

The agent therefore runs a preflight before SQL. It checks the ingestion source, event definition, order association, AMC instance, and requested start date, then returns a pass or a named setup failure. That sequence also keeps the claim precise: Events Manager covers off-Amazon web, offline, and app events used for attribution, reporting, optimization, and targeting, but the event must pass the DSP setup gate first.

All Events Manager signals are available in AMC whether ad-exposed or not, and the playbook says the paid conversions_all subscription is not required to query non-ad-exposed Events Manager signals. That makes non-ad-exposed analysis possible without making it causal proof. It is a comparison and audience-discovery input, not evidence that advertising created an outcome in a user who was never exposed.

Purchase sales and non-purchase conversion value are different measurements

off_amazon_product_sales is monetary sales from off-Amazon purchases. off_amazon_conversion_value is an advertiser-defined, unitless value for non-purchase events such as a page view, app install, lead, or form submission. Do not add the second field to revenue or use it in return on ad spend (ROAS) unless the advertiser has explicitly documented a monetary scoring convention outside the schema.

Events Manager also represents off-Amazon conversion_event_subtype values as numeric codes. The retrieved mapping is:

Event	Code	Monetary
Subscribe	`5`	No
Application	`7`	No
Sign-up	`21`	No
App first start	`37`	No
Add to cart	`53`	No
Off-Amazon purchase	`54`	Yes
Other	`133`	No
Page view	`134`	No
Search	`135`	No
Contact	`136`	No
Checkout	`140`	No
Lead	`141`	No

The event formerly labeled Product purchased is now Off-Amazon purchase. The Skill keeps the mapping versioned and leaves an unknown code visible instead of coercing it to a familiar label. That is safer than silently converting an unrecognized future subtype into revenue.

The canonical Total Impact query joins campaign delivery to conversion outcomes

Amazon's canonical Total Impact Analysis query from Introduction to Events Manager joins campaign cost, impressions, and unique reach from dsp_impressions to Amazon and off-Amazon outcomes from amazon_attributed_events_by_traffic_time. It keeps purchase sales, non-purchase value, combined sales, and conversion counts separate, then calculates Amazon and off-Amazon ROAS from the corresponding monetary sales fields. Set the workflow's date range in the AMC query editor to October 20, 2023 or later before running it.

-- Instructional Query: How to query Events Manager Signals - Total Impact Analysis --
-- AD PRODUCTS: Amazon DSP
/*
 ------- Customization Instructions -------
 1) Set the "Date range" in the Query Editor to define the time range.
 1a) It is recommended to query events after 10/20/2023, as events before this date may be missing dimensions and metrics.
 */
-- Gather campaign cost and impression data
WITH traffic AS (
  SELECT
    campaign_id_string,
    campaign,
    SUM(impressions) AS impressions,
    SUM(total_cost / 100000) AS total_cost,
    COUNT(DISTINCT user_id) AS unique_reach
  FROM
    dsp_impressions
  WHERE
    user_id IS NOT NULL
  GROUP BY
    1,
    2
),
-- Gather Amazon and off-Amazon (Events Manager events) conversion data
conversions AS (
  SELECT
    campaign_id_string,
    conversion_event_source_name,
    conversion_event_name,
    conversion_event_category,
    CASE
      conversion_event_subtype
      WHEN 53 THEN 'Add to shopping cart'
      WHEN 7 THEN 'Application'
      WHEN 140 THEN 'Checkout'
      WHEN 136 THEN 'Contact'
      WHEN 141 THEN 'Lead'
      WHEN 54 THEN 'Off-Amazon purchase'
      WHEN 133 THEN 'Other'
      WHEN 134 THEN 'Page View'
      WHEN 135 THEN 'Search'
      WHEN 21 THEN 'Sign-up'
      WHEN 5 THEN 'Subscribe'
      ELSE conversion_event_subtype
    END amazon_conversion_event,
    SUM(off_amazon_conversion_value) AS off_amazon_conversion_value,
    SUM(off_amazon_product_sales) AS off_amazon_product_sales,
    SUM(conversions) AS conversions,
    SUM(total_product_sales) AS total_product_sales,
    SUM(total_purchases) AS total_purchases,
    SUM(combined_sales) AS combined_sales
  FROM
    amazon_attributed_events_by_traffic_time
  GROUP BY
    1,
    2,
    3,
    4,
    5
) -- Join cost and impressions with conversions
SELECT
  t.campaign,
  c.conversion_event_category,
  c.conversion_event_source_name,
  c.conversion_event_name,
  c.amazon_conversion_event,
  SUM(t.impressions) AS impressions,
  SUM(t.total_cost) AS total_cost,
  SUM(t.unique_reach) AS unique_reach,
  SUM(COALESCE(c.off_amazon_conversion_value, 0)) AS off_amazon_conversion_value,
  SUM(COALESCE(c.off_amazon_product_sales, 0)) AS off_amazon_product_sales,
  SUM(COALESCE(c.conversions, 0)) AS conversions,
  SUM(COALESCE(c.total_product_sales, 0)) AS total_product_sales,
  SUM(COALESCE(c.total_purchases, 0)) AS total_purchases,
  SUM(COALESCE(c.combined_sales, 0)) AS combined_sales,
  CASE
    WHEN SUM(t.total_cost) > 0 THEN SUM(COALESCE(c.total_product_sales, 0)) / SUM(t.total_cost)
    ELSE 0
  END AS amazon_roas,
  CASE
    WHEN SUM(t.total_cost) > 0 THEN SUM(COALESCE(c.off_amazon_product_sales, 0)) / SUM(t.total_cost)
    ELSE 0
  END AS off_amazon_roas
FROM
  traffic t
  LEFT JOIN conversions c ON t.campaign_id_string = c.campaign_id_string
GROUP BY
  1,
  2,
  3,
  4,
  5

The query stays faithful to the retrieved instructional query, including Amazon's total_cost / 100000 normalization and campaign-ID join. Inspect the returned source names and event definitions before operationalizing it; unknown subtype codes stay visible through the ELSE branch instead of being silently relabeled.

combined_sales is Amazon total_product_sales plus off_amazon_product_sales; it does not include the unitless value assigned to non-purchase conversions. The query reports Amazon and off-Amazon ROAS separately, so leads and page views never enter either monetary numerator. A combined-sales return can be derived downstream only after the output grain and cost allocation have been reviewed.

Events Manager history is complete only from October 20, 2023 onward

Treat October 20, 2023 as the completeness boundary for the named Events Manager dimensions and metrics in amazon_attributed_events_by_* and conversions* tables. Earlier periods can be missing those fields. A range before the boundary can also omit 30-day ad-unexposed events from conversions and conversions_with_relevance, so a lower historical count is not safely interpreted as lower customer activity.

The Off-Amazon Conversions Playbook carries the result beyond reporting into campaign measurement, segmentation, and separately reviewed audience creation. Examples include users who added to cart off Amazon but did not purchase, converters who were not ad-exposed, and non-ad-exposed purchasers of product A who may be candidates for product B. Those are useful hypotheses. They do not prove incrementality, and measurement SQL does not activate an audience by itself.

AMC only returns aggregated, pseudonymized outputs that meet its aggregation thresholds. The agent keeps the output at campaign and event grain, avoids SELECT *, rejects unsafe start dates, and reports suppressed or unknown results instead of turning them into zeros.

What happens next

After the preflight and subtype checks pass, schedule the total-impact analysis as a recurring Skill. Keep Amazon product sales, DTC purchase sales, and non-purchase conversion value in separate output columns; use combined_sales for the Amazon-plus-DTC product-sales view; and review any unknown subtype before the run reaches a dashboard or optimization rule.

The complete workflow runs through the Amazon Agent Data layer: the Amazon Ads MCP supplies live AMC access, the Selling Partner MCP adds catalog or retail context when the decision needs it, Skills make the checks recurring, and Amazon Agent Atlas grounds the taxonomy, date rule, and setup gates. If a segment is worth activating, hand it to a separate reviewed audience workflow rather than making activation an invisible side effect of measurement.

Events Manager turns DTC outcomes into dependable AMC measurement only when ingestion, DSP association, event taxonomy, and revenue semantics are all correct.

Next, place those captured outcomes inside the full AMC path across DSP and sponsored ads.

Rebuild Your Listing Images From Your Own Photos

2026-06-25T00:00:00Z

Rebuilding a thin listing gallery is one conversation: the Amazon Agent Iris Skill seeds new images from your own product photos, fills factual details from the listing's own catalog data, grades every image against Amazon's rules through Amazon Agent Atlas, and waits for you to approve before it publishes a single one through the Selling Partner MCP. One photo in, a full compliant set out, nothing live until you say yes.

That sequence exists because of a Slack message I get some version of every month: "Can the agent use our existing product photos as seeds to make better listing images that still pass Amazon's image rules, and let me approve before anything publishes?" The pain underneath is the long tail. Most catalogs stay underbuilt because fixing every laggard meant a photographer, a studio, a designer, and a round of manual uploads, and that was never worth it for a SKU doing twelve units a month. Good imagery used to mean picking two of fast, cheap, and safe. So I handed a thin water-bottle listing to our agent with one rule: seed from our real photos, check before you publish, and stop at my approval.

Why not just do this in ChatGPT or Claude? A generic chat hits the same three walls on any Amazon job. It has no access to your data, so it cannot read your live listing or your existing photos and works only from what you paste in. It has no way to take action, so it cannot check an image against Amazon's policy, publish it, or confirm it landed; the most it can do is hand you a file to upload by hand in Seller Central, where images can take up to 24 hours to appear and uploading does not guarantee display. And it runs on generic knowledge, not Amazon's, public training data rather than Amazon's current, in-depth image rules (white background, the zoom threshold, per-category main-image rules, suppression triggers). What you get is disconnected, generic, manual work that ships silent mistakes, and a non-compliant image can suppress the listing from search until you fix it. Each section below clears one of those walls with the Selling Partner MCP (your data, plus the tools to act and publish), Atlas (the private Amazon image rule book), and the Amazon Agent Iris Skill (the seed, check, approve, publish loop).

Seeding from your own product photos turns a photographer-studio-designer-upload chain into one conversation

The benefit first: you get studio-quality images without a studio, and the time and cost of that whole chain collapse into a single run. The Amazon Agent Iris Skill on the Selling Partner MCP reads the listing and its existing images, then generates new images seeded from the seller's own product photos, so the real product identity, logos, and printed text stay intact rather than becoming generic stock. It fills factual details, like size-guide measurements, from the listing's own catalog data, so the specs are exact and not invented. The whole loop runs in one conversation with no manual Seller Central uploads.

Here is what it looked like. The water-bottle listing started with one image and ended with four candidates in a single run: a sharpened white-background main shot, a true lifestyle scene of the bottle in use, a precise size guide whose measurements came straight from the listing's own data, and a detail shot the validator bounced for falling under the zoom threshold. That gate is the point, and the surviving set still cleared the four-image target shape, which is not arbitrary. It follows the recommended set in Amazon's image guidance: one image of the product on a white background, one in an environment, and one with product information such as dimensions. The Skill seeded all of it from photos we already owned.

In plain ChatGPT or Claude

No access to your data. ChatGPT cannot see your listing or your existing photos, so it cannot seed from your real product. You would have to describe it or paste images, and it invents a generic-looking product that is not quite yours. The Skill reads your real photos through the MCP and seeds from them.
No way to take action. Even if Claude drafts an image, it cannot get it onto Amazon. You export it and upload it by hand in Seller Central, where it can take up to 24 hours to appear and may not display at all. The Skill publishes through the MCP and confirms it.
And your data is now exposed. To get this far you pasted product photos and account context into a chat history you do not control. The Skill never copies your data into a prompt; the MCP reads it over an authorized connection and it stays in your account.

When cost-per-image and effort-per-listing crater, the math flips: every listing gets brought up to standard, not just the heroes

The benefit here is catalog-wide quality that was never economically possible before. Because the loop is a reusable Skill, the same seed, check, approve, publish run scales across the catalog. The long tail of thin and single-image listings was never worth a studio shoot, so it stayed underbuilt and under-converting. When the per-listing cost collapses, the recovered conversion from that long tail becomes reachable, and the recommended set (white-background main, an environment image, a product-information image, ideally six or more images per the Product Image Requirements for Amazon Listings guidance) is now within reach for a SKU doing twelve units a month, not just the flagship.

The standard each listing is brought up to is Amazon's, not a house style. I run it as a recurring Skill across the catalog, often kicked off when the audit-to-patch workflow flags an image laggard, so a thin gallery gets re-merchandised the same week it is found instead of next quarter.

In plain ChatGPT or Claude

No way to take action. A chat cannot run the same fix across 400 ASINs (Amazon Standard Identification Numbers). You would repeat the paste, export, upload dance by hand for each one, which is exactly why the long tail never gets fixed. The Skill re-runs the loop unattended up to the approval gate.
Generic knowledge, not Amazon's. Ask a chat to batch-improve listings and it gives the same generic advice for every product type, missing that a Fashion main image follows different rules from a shoe or a kids' item. The Skill grades each against the per-category rule (next section).
No access to your data. A chat cannot tell which of your listings are actually underbuilt, because it cannot see your catalog. The MCP reads which listings are thin and worth upgrading.

Every generated image is graded against Amazon's image rules before it can publish, and a human approves the final set

This is the part that makes the speed safe: nothing publishes that breaks Amazon's rules or that you did not approve. The Skill checks each generated image against Amazon's image policy before anything publishes, a policy validator that returns a per-image verdict, grounded by Atlas against the Product Image Requirements for Amazon Listings, Suppressed Listings Management, and the per-category style guides such as the Fashion Category Style Guide (the listing_categories_style_guide set). That verdict set is the audit report the Skill produces:

{
  "asin": "B0EXAMPLE34",
  "sku": "BOTTLE-32OZ",
  "seeded_from": "existing main product photo + 1 detail photo",
  "starting_images": 1,
  "proposed_images": [
    {
      "slot": "main",
      "kind": "white-background product shot",
      "verdict": "pass",
      "checks": ["pure white background (255,255,255)", "product ~85% of frame", "no text/logos", ">1,000 px longest side"],
      "grounded_in": "Product Image Requirements for Amazon Listings"
    },
    {
      "slot": "secondary-1",
      "kind": "lifestyle / environment scene",
      "verdict": "pass",
      "checks": ["represents real product", "no added accessories not included"],
      "grounded_in": "Product Image Requirements for Amazon Listings"
    },
    {
      "slot": "secondary-2",
      "kind": "size guide (measurements from catalog data)",
      "verdict": "needs changes",
      "fix": "specs pulled from listing's own catalog data; confirm dimensions before approve",
      "grounded_in": "Product Image Requirements for Amazon Listings (product-information image)"
    },
    {
      "slot": "secondary-3",
      "kind": "detail / texture shot",
      "verdict": "reject",
      "fix": "longest side under 1,000 px; regenerate at higher resolution for zoom",
      "grounded_in": "Product Image Requirements for Amazon Listings (1,000 pixels)"
    }
  ],
  "suppression_risk_if_published_uncorrected": true,
  "awaiting": "human approval before publish"
}

Read the verdicts left to right. Pass means compliant and ready. Needs changes is a human judgment call, like confirming the size-guide dimensions the Skill pulled from the catalog. Reject plus fix is a hard rule failure with the exact remedy attached. The rules behind those verdicts are Amazon's, retrieved through Atlas, not paraphrased from training data. The main image must have a pure white background (RGB 255,255,255), the product must fill about 85 percent of the frame, and there can be no text, logos, or watermarks. Images over 1,000 pixels on the longest side enable the zoom Amazon prioritizes, with all images between 500 and 10,000 pixels. The image must accurately represent the product's real scale, quantity, and color. And the reason the check runs before publish rather than after: a non-compliant image will suppress the listing from search until compliant images are provided, the rule grounded in Suppressed Listings Management. Which rule applies to the main image depends on the category, so the validator grades a Fashion item against the Fashion Category Style Guide and a different product type against its own guide. The agent never makes the judgment call of whether an image truly represents the product; a human signs off, and only then does the Skill publish through the MCP and verify ingestion.

In plain ChatGPT or Claude

No way to take action. A chat cannot test an image against Amazon's validator, so nothing catches a bad image before it is live. You only learn it failed when the listing gets suppressed from search and stops converting. The Skill grades each image before publish and ships only what passed.
Generic knowledge, not Amazon's. Claude does not know the 1,000-pixel zoom threshold, the pure-white-background rule, or that a category like Fashion has its own main-image rules, so if you upload its output by hand, Amazon can reject or suppress it. The agent is grounded in Amazon's current image rules through Atlas.
Generic knowledge, not Amazon's. A chat will happily invent measurements for a size-guide image. The Skill pulls them from your listing's own catalog data, and a human approves that the image truly represents the product before it ships, the call a machine should not make alone.

What happens next

Once the verdicts are clean and the human approves the set, the Skill publishes the approved images through the Selling Partner MCP and then confirms ingestion. It verifies the images actually went live rather than assuming success, the opposite of the manual path where images can take up to 24 hours and may never display. Anything that cannot clear forks off: an image marked reject goes back through the seed-and-check loop at higher resolution, and an underlying suppression that no image can fix is the audit-to-patch concern. I run the whole thing as a recurring Skill across the catalog so newly thin or newly suppressed listings get re-merchandised, with the same approval gate in front of every run. Run this way, the loop is one lane of the Amazon Agent Data layer: the same Amazon Agent Flow fabric that wires the Selling Partner MCP, the Amazon Ads MCP, and Atlas into automation your team approves rather than babysits. This is the image side of the audit-to-patch workflow, which forks an image-suppression finding straight into this loop.

The pattern is the same one that makes any of this safe: seed from your own truth, check before publish, approve before live. That is not model cleverness. It is the product surface doing its job.

Next in the series: bringing a suppressed FBA (Fulfillment by Amazon) listing back into search when the problem is not the image but the inventory state behind it.

Amazon FBM Orders Reports: What to Request and Why

2026-06-22T00:00:00Z

Use Seller Central FBM Order Reports for fulfillment data, and use the Amazon Selling Partner API (SP-API) MCP to request SP-API All Orders reports when the job is tracking, support, reconciliation, or a finance period cut. Those are different files with different risk profiles, even though operators often call both "FBM orders."

Operator need	Request	Why
Fulfill seller-fulfilled packages	Seller Central `FBM Order Reports`	Includes buyer information needed to fulfill FBM orders.
Catch changed orders since the last sync	`GET_FLAT_FILE_ALL_ORDERS_DATA_BY_LAST_UPDATE_GENERAL`	Returns all Merchant Fulfilled Network (MFN) and Fulfillment by Amazon (FBA) orders updated in the period.
Cut orders by purchase period	`GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL`	Returns all MFN and FBA orders placed in the period.
Backfill older placed orders	`GET_FLAT_FILE_ARCHIVED_ORDERS_DATA_BY_ORDER_DATE`	Retrieves archived orders by order date.

The practical question came from an ops lead: "We need a daily FBM order file for the warehouse and a support file for changed orders. Can the agent just pull the FBM report through SP-API?" The answer is yes for the support file, not by that name for the warehouse file. Amazon Agent Atlas retrieved the Seller Central FBM Order Reports article and Amazon's SP-API order report type values reference, and the distinction matters: one is a fulfillment file with buyer data; the other is an order-tracking report family that Amazon explicitly says is not for driving seller fulfillment.

A plain ChatGPT or Claude client hits the same three walls on this job. It has no access to your data, so it cannot see your seller account, marketplaces, or last successful report window. It has no way to take action, so it cannot call createReport, poll getReport, or retrieve the report document. And it runs on generic knowledge, not Amazon's, so it easily collapses Seller Central FBM reports, restricted fulfillment reports, and SP-API All Orders tracking reports into one imaginary endpoint. The MCP brings account access and report tools; Atlas brings the exact Amazon rule corpus; Skills make the request, polling, download, and archival loop repeatable.

Start with the fulfillment question, not the API endpoint

Amazon's Seller Central FBM Order Reports article says the FBM order report is a tab-delimited text file for seller-fulfilled products sold during a selected period. It includes the buyer information needed to fulfill orders, but not confidential billing or credit-card information. It can be generated manually for the past 1, 2, 7, 15, or 30 days, and it can be scheduled. Because Seller Central does not generate those reports beyond 30 days, the operational pattern is simple: archive the daily file if it is your warehouse record.

The SP-API All Orders report family answers a different question. In Amazon's order report type values reference, Amazon describes the All Orders reports as order-tracking reports available in all regions and for all sellers. They return all orders regardless of fulfillment channel or shipment status, but they are intended for tracking, not fulfillment, because they do not include customer-identifying information and scheduling is not supported.

For a warehouse, that distinction is not academic. A warehouse dispatch queue needs shipment-ready buyer data. A support or operations queue often needs "what changed since yesterday" and can safely operate from order ID, SKU, status, channel, quantities, city/state/postal/country, and prices. The agent should branch on that intent before it asks the SP-API MCP for anything.

Request all-orders by last update when operations need changed orders

When support asks "what changed since the last sync," the MCP should request GET_FLAT_FILE_ALL_ORDERS_DATA_BY_LAST_UPDATE_GENERAL. Amazon's reference says this report contains all orders updated in the specified period, covers MFN and FBA, is available to sellers, and returns a tab-delimited flat file. It is a requested report, not a scheduled one, and the date range is limited to 30 days. For self-fulfilled pending orders, Amazon also notes that item price is not shown, so do not use this report as a pending-order revenue ledger.

This is the right operational feed for support queues, warehouse exception review, cancellations, shipment-status changes, and downstream systems that reconcile on last-updated-date. It also avoids a common off-by-one mistake: if a customer changes or cancels an older order today, an order-date report for today's placed orders will miss it, but a last-updated report will catch it.

{
  "mcp": "amazon-spapi",
  "tool": "reports.createReport",
  "arguments": {
    "reportType": "GET_FLAT_FILE_ALL_ORDERS_DATA_BY_LAST_UPDATE_GENERAL",
    "marketplaceIds": ["ATVPDKIKX0DER"],
    "dataStartTime": "2026-06-21T00:00:00Z",
    "dataEndTime": "2026-06-22T00:00:00Z"
  }
}

The agent should store the successful window boundary with the run log, then make the next request from the prior dataEndTime. That is a Skill responsibility, not something an operator should remember in a prompt.

Request all-orders by order date when finance needs a period cut

When finance or planning asks "what orders were placed in this period," request GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL. The same SP-API order type values reference says this report contains all orders placed in the specified period, with MFN and FBA rows in a tab-delimited file. Use it for daily sales cuts, month-to-date order extracts, reconciliation against BI tables, and date-based audits.

For FBM-only analysis, do not request a different report just because the business says "FBM." Request the All Orders period cut, then filter the rows where the fulfillment channel is merchant fulfilled. The report's value is that it holds both MFN and FBA orders, so the same extract can support FBM exception analysis and whole-account reporting.

{
  "mcp": "amazon-spapi",
  "tool": "reports.createReport",
  "arguments": {
    "reportType": "GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL",
    "marketplaceIds": ["ATVPDKIKX0DER"],
    "dataStartTime": "2026-06-01T00:00:00Z",
    "dataEndTime": "2026-06-22T00:00:00Z"
  }
}

If the request is a historical backfill by order date, Amazon's archived order report reference identifies GET_FLAT_FILE_ARCHIVED_ORDERS_DATA_BY_ORDER_DATE as the archived-orders report type. Keep that as a deliberate backfill path, not the default daily workflow.

Let the SP-API MCP handle polling, retrieval, and storage discipline

Atlas also pulled Amazon's Reports API tutorials for requesting a report, verifying report processing, and retrieving a report document. The sequence is mechanical, which is exactly why it belongs in a Skill.

Call createReport with reportType, marketplaceIds, and optional dataStartTime / dataEndTime.
Poll getReport with the returned reportId until processingStatus is DONE, CANCELLED, or FATAL.
If DONE includes reportDocumentId, call getReportDocument.
Download the returned pre-signed url before it expires, applying compressionAlgorithm if present.
Keep encryption at rest; Amazon's retrieve tutorial warns against storing unencrypted report content on disk, even temporarily.

{
  "mcp": "amazon-spapi",
  "tool": "reports.getReport",
  "arguments": {
    "reportId": "amzn1.spapi-report.example"
  }
}

{
  "mcp": "amazon-spapi",
  "tool": "reports.getReportDocument",
  "arguments": {
    "reportDocumentId": "amzn1.spdoc.example"
  }
}

The failure states matter. CANCELLED can mean Amazon found no eligible data. FATAL can still include a document that explains the failure. IN_QUEUE and IN_PROGRESS are not terminal, so the agent should keep polling instead of telling the operator the report is missing.

What happens next

In production, the Amazon Ads MCP, the Selling Partner MCP, Skills, and the Amazon Agent Data layer sit behind one agent surface, so a support request can pull the right SP-API order report, archive it, and hand downstream teams the same audited artifact. The same pattern powers the approval loop in Preview Listing Patches Before They Go Live: retrieve the governed source, perform the narrow action, write the run log, and keep the operator out of manual repeat work.

For this guide, the narrow action is report selection. A warehouse dispatch workflow needs the Seller Central FBM fulfillment file or a restricted fulfillment path. A support, finance, or reconciliation workflow should ask the SP-API MCP for the All Orders report type that matches the date logic.

Next in the series: using SP-API order status changes to decide when an agent should notify support, warehouse operations, or finance without turning every report row into an alert.

Find Your Optimal DSP Frequency Cap in AMC

2026-06-13T00:00:00Z

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:

frequency_bucket	conversions	cumul. conversions	cost	cumul. cost	cumul. return %	cumul. cost %	Pct Difference	Pct Change
1	9,203	9,203	$7,801	$7,801	19%	9%	9.90%	n/a
2	6,532	15,735	$7,933	$15,734	32%	18%	14.18%	4.28%
3	5,024	20,759	$7,492	$23,226	43%	27%	15.87%	1.69%
4	4,157	24,916	$7,060	$30,286	51%	35%	16.28%	0.41% (last >0)
5	3,569	28,485	$6,621	$36,907	58%	42%	15.99%	-0.29% (crosses)

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.

Map AMC Paths Across DSP and Sponsored Ads

2026-06-09T00:00:00Z

Ask the agent in your AI client to map the customer journey, and the Amazon Ads MCP runs the path-to-conversion workflow live in your Amazon Marketing Cloud (AMC) instance: it joins dsp_impressions, sponsored_ads_traffic, and amazon_attributed_events_by_traffic_time on user_id, groups campaigns the way the current "Path to Conversion by Campaign Groups" pattern prescribes, and returns a Sankey-ready source-to-destination dataset. Amazon Agent Atlas keeps it honest by surfacing that pattern from the Customer Journey Analytics Playbook instead of letting the agent guess. The answer exists because our media lead asked in Slack: "What's the actual journey our customers take across demand-side platform (DSP), Sponsored Products, Sponsored Brands, and Sponsored Display before they convert?" Everyone had an opinion about which campaign deserved credit. Nobody had the path.

A plain ChatGPT or Claude chat hits the same three walls here. No access to your data: the journey lives in pseudonymized, instance-scoped AMC tables. No way to take action: a chat cannot submit an AMC workflow or re-pull it when attribution closes. Generic knowledge, not Amazon's: it does not know which journey query is current. That adds up to disconnected, generic, manual work that ships silent mistakes. The MCP brings your data plus the tools to act, Atlas the private rule book, Skills the repeatable run.

The whole journey lives in exactly three AMC tables, joined on user_id

The Customer Journey Analytics Playbook's "Tables used" list has exactly three entries: dsp_impressions, sponsored_ads_traffic, and amazon_attributed_events_by_traffic_time. Not one table per ad product. sponsored_ads_traffic carries the traffic events, impressions and clicks, for Sponsored Products, Sponsored Brands, Sponsored Display, and Sponsored Television in one table; you split it by ad_product_type ('sponsored_products', 'sponsored_brands', 'sponsored_display'). The third table holds the conversion events: purchases, new_to_brand_purchases, detail page views.

The join rule comes straight from Amazon's guidance: join on user_id when you are interested in understanding user behavior. Every branch of the query filters user_id IS NOT NULL so the paths stay user-level.

In plain ChatGPT or Claude

Generic knowledge, not Amazon's. Ask ChatGPT for the journey SQL and it invents per-product tables, an sp_impressions here, an sb_traffic there, that do not exist in AMC. All sponsored ads traffic lives in one table split by ad_product_type; the agent reads the real schema through the MCP before writing a line.
No access to your data. Even with correct table names, the joined journey only exists inside your AMC instance after the query runs there. You cannot paste user_id-level impression rows into a chat, so the chat never sees a single path.
Generic knowledge fails again on the third table. The classic miss is joining the two traffic tables and stopping. Without amazon_attributed_events_by_traffic_time there is no conversion endpoint, only exposure. Atlas surfaces the exact three-table list, so the query lands complete.

Group your campaigns, or aggregation thresholds swallow most of the path as NULL rows

The old "Path to Conversion by Campaign" instructional query (IQ) is retired. Amazon's notice reads: "As of August 31, 2022, an improved version of this IQ has been made available in AMC. We recommend advertisers to use the new version: Path to Conversion by Campaign Groups." The improvements are operator-facing: grouping reduces the likelihood of violating aggregation thresholds so "users will see a smaller number of NULL rows," campaign and Amazon Standard Identification Number (ASIN) filters exist, and Sponsored Display conversions are included.

The grouping mechanism is a small VALUES mapping: list each campaign with its group, then COALESCE everything ungrouped into 'DSP-Others', 'SP-Others', 'SD-Others', or 'SB-Others' so no row falls below the thresholds. (The playbook also ships a campaign-category variant that maps campaign names to funnel stages with CASE ... SIMILAR TO, but those categories depend on each advertiser's naming conventions.) Here is the workflow the agent submitted through the Amazon Ads MCP:

-- Path to conversion across DSP + sponsored ads, Sankey-ready output
-- Pattern: "Path to Conversion by Campaign Groups" IQ (supersedes the
-- "Path to Conversion by Campaign" IQ as of 2022-08-31)
WITH campaign_group (campaign, campaign_group) AS (
  VALUES
    -- placeholder campaign names/IDs; ungrouped rows fall back to
    -- '<product>-Others' so aggregation thresholds aren't violated
    ('111111111111111111', 'group 1'),
    ('222222222222222222', 'group 1'),
    ('SP_campaign', 'group 2'),
    ('SD_campaign', 'group 3'),
    ('SB_campaign', 'group 4')
),
impressions AS (
  SELECT
    COALESCE(g.campaign_group, 'DSP-Others') AS campaign_group,
    'DSP' AS product_type,
    i.user_id,
    MIN(i.impression_dt) AS impression_dt_first,
    MAX(i.impression_dt) AS impression_dt_last,
    SUM(i.impressions) AS impressions,
    SUM(i.total_cost) AS total_cost
  FROM dsp_impressions i
    LEFT JOIN campaign_group g ON g.campaign = i.campaign
  WHERE i.user_id IS NOT NULL
  GROUP BY 1, 2, 3
  UNION ALL
  SELECT
    COALESCE(g.campaign_group, 'SP-Others') AS campaign_group,
    'SP' AS product_type,
    a.user_id,
    MIN(a.event_dt) AS impression_dt_first,
    MAX(a.event_dt) AS impression_dt_last,
    SUM(a.impressions) AS impressions,
    SUM(a.spend) AS total_cost
  FROM sponsored_ads_traffic a
    LEFT JOIN campaign_group g ON g.campaign = a.campaign
  WHERE a.user_id IS NOT NULL
    AND a.ad_product_type = 'sponsored_products'
  GROUP BY 1, 2, 3
  UNION ALL
  SELECT
    COALESCE(g.campaign_group, 'SD-Others') AS campaign_group,
    'SD' AS product_type,
    a.user_id,
    MIN(a.event_dt) AS impression_dt_first,
    MAX(a.event_dt) AS impression_dt_last,
    SUM(a.impressions) AS impressions,
    SUM(a.spend) AS total_cost
  FROM sponsored_ads_traffic a
    LEFT JOIN campaign_group g ON g.campaign = a.campaign
  WHERE a.user_id IS NOT NULL
    AND a.ad_product_type = 'sponsored_display'
  GROUP BY 1, 2, 3
  UNION ALL
  SELECT
    COALESCE(g.campaign_group, 'SB-Others') AS campaign_group,
    'SB' AS product_type,
    a.user_id,
    MIN(a.event_dt) AS impression_dt_first,
    MAX(a.event_dt) AS impression_dt_last,
    SUM(a.impressions) AS impressions,
    SUM(a.spend) AS total_cost
  FROM sponsored_ads_traffic a
    LEFT JOIN campaign_group g ON g.campaign = a.campaign
  WHERE a.user_id IS NOT NULL
    AND a.ad_product_type = 'sponsored_brands'
  GROUP BY 1, 2, 3
),
converted AS (
  -- conversions attributed to in-window traffic; events can land up to
  -- 30 days after the window, so totals move until attribution closes
  SELECT
    user_id,
    SUM(conversions) AS conversions
  FROM amazon_attributed_events_by_traffic_time
  WHERE user_id IS NOT NULL
  GROUP BY 1
),
ranked AS (
  SELECT
    user_id,
    campaign_group,
    ROW_NUMBER() OVER (
      PARTITION BY user_id
      ORDER BY impression_dt_first
    ) AS path_rank
  FROM impressions
),
steps AS (
  -- explode the path into source -> destination pairs: QuickSight's
  -- Sankey visual needs one source and one destination dimension per row
  SELECT
    r1.user_id,
    r1.campaign_group AS path_step_source,
    r2.campaign_group AS path_step_destination
  FROM ranked r1
    LEFT JOIN ranked r2
      ON r2.user_id = r1.user_id
      AND r2.path_rank = r1.path_rank + 1
)
SELECT
  s.path_step_source,
  s.path_step_destination,
  COUNT(DISTINCT s.user_id) AS path_occurrences,
  SUM(c.conversions) AS conversions
FROM steps s
  LEFT JOIN converted c ON c.user_id = s.user_id
GROUP BY 1, 2
-- NO ORDER BY here: AMC rejects ORDER BY in the outer query of a
-- workflow ("ORDER BY unexpected"). Sort downstream, post-export.

Swap the placeholder VALUES rows for your own campaign names or IDs and the rest runs as-is.

Conversions keep landing for 30 days after your window, so day-zero numbers are not final

amazon_attributed_events_by_traffic_time has a property that surprises people: the traffic events all sit inside your query window, but the attributed conversions "may have occurred up to 30 days after the time window." Amazon extends the conversion range automatically and says plainly that "the output of a workflow that uses this table may change over time." The lookback itself is fixed per campaign and cannot be changed in AMC: 14 days for Brands, 7 days for Sellers' Sponsored Products.

I was skeptical when the agent flagged this, so we re-pulled the identical workflow later in the attribution window. The conversion column grew, and nothing was wrong; attribution was still filling in. Run the analysis the morning after your window closes and you under-count whatever is still inside that 14-day lookback, which is why the agent derives a safe re-pull date from the lookback rather than treating day-zero output as final.

One eligibility wrinkle from the Custom Attribution Overview is worth knowing too: DSP conversions require a viewable impression and Sponsored Products require a click, so impression-only SP exposures never appear in the attributed datasets at all.

Sankey-ready means source-to-destination rows, and the agent returns the dataset already in that shape

Amazon's path output arrives as ranked arrays, paths like [[1, DSP-Display], [2, DSP-Video], [3, BSI], [4, SB-Others]] with path_occurrences and impressions alongside. QuickSight cannot chart that directly. The playbook is explicit: the "Sankey diagram is a visual type within Amazon QuickSight and requires a one dimension in source and one dimension in destination." A four-element path "will 'explode into' 3 separate steps/rows," metrics repeated on every exploded row; the playbook does this in a notebook ending with df_final.to_csv('Sankey-Diagram_Input.csv', index=False).

The query above skips the notebook step. The ROW_NUMBER self-join in the steps CTE emits the exploded pairs directly, one row per hop, ordered by first impression time. A user's terminal step carries a NULL destination (single-exposure users keep one row); label that terminal node from the converted join and the diagram shows where each journey ends. Read the conversions column as the conversion total of users who traversed that hop, not as credit attributed to the hop itself.

What happens next

Reading the diagram is the fast part. The playbook's worked example charts the top 20 paths by purchase, with high-purchase users usually exposed to loyalty and consideration campaign categories and awareness overlap comparatively lower. The move: reuse what the high-overlap groups share (impression frequency, cost, line items) in the next campaign, and seed lookalikes from those audiences. One row to ignore: the "none" exposure group, purchasers with no impression recorded under their user_id; Amazon says to skip it.

From there I have the agent re-run the workflow as a recurring Skill, timed past attribution close, so each month's diagram compares settled numbers to settled numbers.

When the fixed 14-day window is the wrong lens, the custom attribution IQs (First Touch, Last Touch, Linear, Position Based) extend the lookback to 28 days and re-credit the same journey; that choice is its own guide: choosing a custom attribution model in AMC. The path query is one surface of Amazon Agent Flow, the Amazon Agent Data layer connecting the Amazon Ads MCP, the Selling Partner MCP, Atlas, and Skills into end-to-end workflows.

The pattern is the one this series keeps landing on: the agent runs Amazon's current query in your instance, grounded in Amazon's own playbook, and returns an artifact you can act on the same day. The journey was always in your data. The walls were in the chat.

Next up: how much your DSP and sponsored ads audiences actually overlap, and what that says about incrementality, in the four-way sponsored ads and DSP overlap analysis.

Preview Listing Patches Before They Go Live

2026-05-28T00:00:00Z

The Slack message came in right before a weekend push: "Our luggage listing is converting badly, the bullets read like a wall of text, and one image got rejected last week. Can the agent just fix it? But I don't want it quietly editing a live listing without me seeing what changed first."

That last clause is the whole job. Fixing a listing is easy to ask for and dangerous to automate, because a single wrong attribute name can wipe a field you never meant to touch. So I handed it to our agent, backed by Amazon Agent Atlas, with one rule: audit first, show me the diff, and do not write anything live until I say yes.

What a model without Atlas gets wrong

I gave the same prompt to a frontier model with no retrieval. The plan it produced looked reasonable and would have caused real damage.

Four failure modes in a single un-grounded response

It proposed a full putListingsItem replace instead of a patchListingsItem partial update. A full replace requires every attribute to be resent; the omitted ones get wiped. The agent only wanted to change two bullets.
It submitted the change directly, with no validation step. The Listings Items API offers mode=VALIDATION_PREVIEW, which runs the real validation and returns errors without committing. Skipping it means the first time you learn the patch is malformed is after the listing breaks.
It rewrote the bullets with an emoji and the phrase "eco-friendly." Amazon removes bullets containing emojis, trademark symbols, and prohibited phrases like eco-friendly or anti-microbial. The model had no idea the copy would be silently stripped.
It assumed a generic bullets attribute. Attribute names are product-type specific. The correct path is /attributes/bullet_point, and the model would have gotten a rejected patch for an unknown attribute.

None of this is exotic. It is all in Amazon's own documentation, scattered across the Selling Partner API (SP-API) reference and a handful of Seller Central help pages that only surface when you already know the exact term to search.

What Atlas retrieves

When the agent gets the question, it runs a semantic search across the amazon_sellers collection and pulls the governing documents before it writes a single attribute:

The Partially Update a Listing reference, which establishes that patchListingsItem applies a JSON Patch to one or more attributes without disturbing the rest of the listing.
The Preview Errors Before Partially Updating a Listing tutorial, the source of the mode=VALIDATION_PREVIEW parameter that turns a blind submission into a dry run.
The Catalog Items API reference, whose getCatalogItem call returns the live attributes, images, and summaries for an ASIN (Amazon Standard Identification Number), keyed to the product type definition.
Suppressed Listings Management, which explains how to download the suppressed listings report and why a listing is hidden from search in the first place.
Product Image Requirements for Amazon Listings, which states plainly that non-compliant images suppress the listing from search until compliant images are provided.
Suggest Changes to Your Product Detail Page, Amazon's own surface for recommended detail-page improvements, which the agent reads as a second opinion on what to fix.

Atlas does not write the patch. It surfaces the rules the patch has to obey, wired through the Amazon Selling Partner MCP, and the agent adapts them to this specific listing.

The agent's working output

The agent did not start by editing anything. It pulled the live listing state through getCatalogItem and produced an audit report that names each finding, its severity, and the document it is grounded in:

{
  "asin": "B0EXAMPLE12",
  "sku": "LUG-HARDSIDE-28",
  "listing_status": "active",
  "findings": [
    {
      "field": "bullet_point",
      "severity": "high",
      "finding": "Two bullets exceed 255 characters and one contains an emoji",
      "source": "Product Bullet Points Requirements"
    },
    {
      "field": "main_image",
      "severity": "medium",
      "finding": "Main image background is not pure white; at risk of suppression",
      "source": "Product Image Requirements for Amazon Listings"
    },
    {
      "field": "item_name",
      "severity": "low",
      "finding": "Title repeats the brand token three times",
      "source": "Suggest Changes to Your Product Detail Page"
    }
  ]
}

From that audit, the agent built a JSON Patch that touches only the bullet points, leaving every other attribute untouched. This is the body it would send to patchListingsItem:

{
  "productType": "LUGGAGE",
  "patches": [
    {
      "op": "replace",
      "path": "/attributes/bullet_point",
      "value": [
        {
          "value": "Hardside shell resists scuffs and cracking on checked flights",
          "marketplace_id": "ATVPDKIKX0DER"
        },
        {
          "value": "Spinner wheels roll in four directions for tight gate turns",
          "marketplace_id": "ATVPDKIKX0DER"
        },
        {
          "value": "TSA-approved combination lock built into the side panel",
          "marketplace_id": "ATVPDKIKX0DER"
        }
      ]
    }
  ]
}

Then the part the operator actually asked for. The agent submitted that body with mode=VALIDATION_PREVIEW, read the returned issues array, and refused to go live until a human approved:

import requests

SPAPI = "https://sellingpartnerapi-na.amazon.com"
MARKETPLACE = "ATVPDKIKX0DER"
SELLER_ID = "A1EXAMPLESELLER"


def preview_patch(sku, body, token):
    response = requests.patch(
        f"{SPAPI}/listings/2021-08-01/items/{SELLER_ID}/{sku}",
        params={"marketplaceIds": MARKETPLACE, "mode": "VALIDATION_PREVIEW"},
        headers={"x-amz-access-token": token},
        json=body,
    )
    return response.json()


def submit_patch(sku, body, token):
    response = requests.patch(
        f"{SPAPI}/listings/2021-08-01/items/{SELLER_ID}/{sku}",
        params={"marketplaceIds": MARKETPLACE},
        headers={"x-amz-access-token": token},
        json=body,
    )
    response.raise_for_status()
    return response.json()


def run(sku, patch_body, token, approver):
    preview = preview_patch(sku, patch_body, token)
    errors = [i for i in preview.get("issues", []) if i.get("severity") == "ERROR"]
    if errors:
        return {"status": "blocked", "errors": errors}
    if not approver.approves(sku, patch_body, preview):
        return {"status": "declined"}
    return submit_patch(sku, patch_body, token)

The design choice that matters is that the preview call and the live call send the same body. The only difference is the mode query parameter. That means the thing the human approves is byte-for-byte the thing that ships, with no second translation step where a new error can creep in. The agent also kept the patch scoped to /attributes/bullet_point rather than rewriting the whole listing, so an approval reviewer reads one diff instead of auditing the entire item. And because the audit flagged the main image as a suppression risk, the agent explicitly declined to claim the copy fix would lift a suppression. It cannot, and saying so is part of being honest about what a patch can do.

The footnotes the agent surfaced unprompted

This is where retrieval grounding pulls away from fluent guessing. Without being asked, the agent attached the caveats an operator needs but rarely thinks to request:

Things Atlas surfaced that the operator didn't ask for

Preview error codes are changing. The VALIDATION_PREVIEW error codes are being revised; Amazon supports both old and new codes during the transition, so match on issue meaning, not just the literal code string.
Bullet rules are strict. Each bullet must be 10 to 255 characters, carry no end punctuation, and exclude emojis, the registered or trademark symbols, and prohibited phrases like eco-friendly or anti-microbial. Include at least three.
An image-suppressed listing will not un-suppress from a copy edit. Fix the non-compliant image first; a clean bullet patch on a suppressed listing changes nothing a shopper can see.
Throttle is five requests per second per operation. Submit only items with material changes. Resubmitting unchanged attributes inflates processing backlogs and slows the whole queue.
Prefer notifications over polling. Subscribe to LISTINGS_ITEM_ISSUES_CHANGE to get near-real-time SKU, severity, and enforcement-action updates instead of repeatedly calling the API to check whether the issue cleared.
An ASIN must represent one product. Editing a detail page to describe a different product is a policy violation, not an optimization. The agent will refuse a patch that changes what the listing fundamentally is.

Any one of these would have cost an afternoon to rediscover after a failed submission.

What happens next

Once VALIDATION_PREVIEW returns a clean issues array and the human approves, the agent resends the identical body without the mode parameter and the change goes live. It then watches the LISTINGS_ITEM_ISSUES_CHANGE notification stream to confirm the issue actually cleared, rather than assuming success. For the findings a text patch cannot solve, the path forks: the image flagged as a suppression risk is handed to the seeded image-regeneration workflow, and recurring audits are wired up as a scheduled Skill so the listing is re-checked after every catalog change instead of once a quarter. The same approval gate applies every time, which is the pattern explored in human approval for agent activation.

The full workflow runs through the Amazon Agent Data layer: Selling Partner MCP reads and previews listing changes, the Amazon Ads MCP can add Amazon Marketing Cloud (AMC) campaign-side performance context, Atlas grounds the catalog rules, and Skills keep every recurring patch behind a reviewable approval gate.

Why this matters

A foundation model can draft a better bullet point. What it cannot reliably do is read the live product-type schema, scope the edit to a JSON Patch that leaves the rest of the listing intact, run it through Amazon's own validation before committing, and tell you that the real problem was the image all along. That sequence is not model cleverness. It is a corpus of Amazon's own listing rules, indexed and addressable by an agent at the moment it is about to act, with a human holding the final yes.

If your agent can edit a live listing, it should be able to show you the diff first.

Next in the series: using your current product photos as seeds for OpenAI image generation to regenerate listing visuals that still pass Amazon's image requirements, with the same approve-before-publish gate sitting in front of every upload.

Count New-to-Brand Customers in AMC

2026-05-17T00:00:00Z

What is the NTB customer question?

A Slack from our paid team last Tuesday: "Of all the customers our campaigns reached who actually bought, how many were buying our brand for the first time?"

The honest answer is: nobody at the agency knows, the Amazon Ads console gives a partial number that excludes Amazon's demand-side platform (DSP), and ChatGPT will hand back a SQL query that compiles and counts the wrong table. The right answer lives in three Amazon Marketing Cloud (AMC) instructional queries plus a schema doc, none of which a model has cleanly in its training data. I handed the question to our agent, backed by Amazon Agent Atlas.

The matrix the agent grounded in before writing a line of SQL:

Source	Use it for	Don't use it for
`amazon_attributed_events_by_conversion_time`	Recurring NTB measurement, by promoted Amazon Standard Identification Number (ASIN)	Anything time-of-impression
`amazon_attributed_events_by_traffic_time`	Same-day pacing only	Recurring workflows
`amazon_retail_purchases` (NTB gateway IQ)	Custom NTB lookback (e.g. 1095 days)	Ad-attribution analysis
`conversions` (custom attribution)	Pixel + off-Amazon NTB	Sponsored Ads NTB counts

The IQ behind the answer is New to brand customers.

What a model without Atlas gets wrong

Four failure modes I watched in a single un-grounded draft of this query

It picked amazon_attributed_events_by_traffic_time because the name sounds neutral. That table re-extends the conversion window by up to 30 days after the query, so the output changes after the workflow runs. A recurring NTB report pinned to it drifts.
It forgot purchases > 0 and counted every user the campaign reached, not just buyers. The denominator was wrong and so was the percentage.
It put SELECT user_id in the final output and the query ran but the column came back blocked. user_id carries an aggregation threshold and can only live inside a CTE that aggregates it away.
It confused the New-to-brand customers IQ with the New-to-brand purchases IQ. They use the same table but different denominators. The first counts distinct users; the second counts orders. The model swapped them and the answer to "how many first-time buyers did we acquire" came back as a purchase count inflated by repeat NTB orders.

None of these failures throw an error. The query runs. The number is wrong.

What Atlas retrieves

The agent didn't write SQL from training data. It pulled five chunks from Atlas and grounded the query in them:

The New to brand customers instructional query: the canonical AMC IQ for this exact operator question, including the requirement language ("ASINs must be tracked to campaigns") and the policy window ("previous 365 day period").
The Amazon Attributed Events Overview schema doc: defines the new_to_brand boolean column and the stability difference between amazon_attributed_events_by_conversion_time and the traffic-time variant. This is the source for the "use conversion_time for recurring workflows" rule. The table is wired through the Amazon Ads MCP, so the agent could resolve the column without resorting to a live web fetch via Amazon Agent Crawl.
The New to brand purchases analysis IQ, adjacent to the customer IQ and the one a model would otherwise confuse with this one. Atlas surfaced it so the agent could write Section 8 distinguishing the two.
The Understanding New-to-Brand ASINs on Amazon IQ, the natural follow-up. Once the operator knows the portfolio-level NTB%, the question becomes "which ASINs are the front door for NTB acquisition."
The Data aggregation thresholds in AMC reference: the privacy-safeguard doc that explains why user_id SELECTs get blocked at a final-output grain.

How the agent's NTB SQL output works

The SQL the agent returned, copy-pasteable into the AMC query editor:

-- New-to-brand customers: count and percentage by campaign.
-- Source IQ: New to brand customers (AMC instructional query).
-- NTB lookback: 365 days (Amazon-managed; not parameterizable in this IQ).
-- Run on the analytics table, NOT the for_audiences variant.
WITH ad_buyers AS (
  SELECT
    advertiser,
    campaign,
    user_id,
    MAX(new_to_brand) AS new_to_brand_flag
  FROM amazon_attributed_events_by_conversion_time
  WHERE purchases > 0
  GROUP BY 1, 2, 3
),
ntb_only AS (
  SELECT user_id, advertiser, campaign
  FROM ad_buyers
  WHERE new_to_brand_flag = TRUE
)
SELECT
  b.advertiser,
  b.campaign,
  COUNT(DISTINCT b.user_id) AS users_that_purchased,
  COUNT(DISTINCT n.user_id) AS ntb_users_that_purchased,
  COUNT(DISTINCT n.user_id) * 1.0
    / NULLIF(COUNT(DISTINCT b.user_id), 0) AS ntb_users_percentage
FROM ad_buyers b
LEFT JOIN ntb_only n
  ON  b.user_id    = n.user_id
  AND b.advertiser = n.advertiser
  AND b.campaign   = n.campaign
GROUP BY 1, 2
ORDER BY ntb_users_percentage DESC

Three decisions in this query would otherwise cost an operator an afternoon. The table choice is amazon_attributed_events_by_conversion_time, not the traffic-time variant. The Atlas chunk for Amazon Attributed Events Overview is explicit: traffic-time will re-extend the conversion window by up to 30 days after the query runs, so a recurring NTB report pinned to it produces a different answer each time. Conversion-time is the only safe table for a recurring measurement workflow.

The WITH CTE exists because user_id carries an aggregation threshold. AMC will block any final SELECT that tries to expose user_id directly. The CTE collapses each user into a single row tagged with their NTB flag, and the outer SELECT operates only on COUNT DISTINCT. That is legal; it is also why the IQ template uses a CTE rather than a single-pass SELECT.

The grouping is by campaign, not by advertiser alone. A portfolio-level NTB% hides the campaigns doing the actual acquisition work. If three campaigns are running and one is a loyalty-retargeting campaign with deliberately low NTB%, the aggregate percentage drops and looks like a problem. Grouping by campaign separates the loyalty workload from the acquisition workload so each campaign gets judged on its own goal.

What NTB footnotes the agent surfaced

Five things the agent surfaced unprompted, the ones an un-grounded model wouldn't include because it didn't know to

Amazon's docs phrase the NTB window two ways: the IQ chunk says "previous 365 day period" and the events table schema doc says "previous 12 months." Same definition, different wording. The IQ language is the authoritative one for this query; surface the inconsistency to the reader so nobody chases a ghost.
The pixel-only path is a different query. Advertisers without a promoted ASIN that resulted in an ad-attributed purchase cannot run this IQ at all. The Atlas retrieval surfaced the amazon_retail_purchases NTB gateway IQ as the alternative, with a custom-lookback parameter (1095 days = 3 years is a common pick).
The DSP NTB count includes only promoted-ASIN purchases. Sponsored Ads NTB also includes Brand Halo (related ASINs). A mixed-product portfolio measured by this IQ under-counts NTB on the DSP side relative to Sponsored Ads. The contrast with the custom-attribution data sources is sharper here than the IQ doc admits.
The column is tracked_asin. The IQ doc prose refers to "promoted ASIN." Same thing. Operators who grep the table schema for promoted_asin come up empty and assume the data isn't there.
If a campaign was deliberately set up as existing-only (a Subscribe & Save win-back, for example), NTB% will be near zero. That is correct, not a bug. The IQ explicitly requires campaigns to "target both new and existing customers" for the result to be interpretable, and an existing-only campaign violates that requirement on purpose.

What happens next

The single-run query is the first step. The repeatable workflow is what the operator actually wanted.

Activate this query as a recurring Skill on a weekly cadence. Push the per-campaign NTB% to a BI dashboard so brand managers can read the trend without re-running SQL. Wire the underlying retrieval through the Amazon Ads MCP so the agent surfaces the same context to a human reviewer mid-month that it had at compose time.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings campaign and AMC signals, the Selling Partner MCP can add catalog context, Atlas grounds the table choice, and Skills turn the query into a reviewed recurring automation.

The rule that fires off this measurement: campaigns below the brand's target NTB% get re-allocated toward upper-funnel placements (DSP awareness inventory, Sponsored Display NTB audiences). Campaigns above target hold steady. Campaigns dramatically below target with no upper-funnel exposure are the strongest signal that the budget is being spent on existing customers who would have purchased anyway.

The natural follow-on is the per-ASIN NTB breakdown. The portfolio number tells you whether acquisition is happening. The ASIN-level number tells you which products are doing the work.

Why this NTB count matters

If your acquisition number is just "total buyers," you are not measuring acquisition.

Next up: the per-ASIN NTB gateway analysis, which ASINs are the front door for new-customer purchases, and how to find them in the path-to-conversion data.

Question	Use this query	Why
DSP plus Sponsored Products only	Sponsored Products and DSP Display Overlap	Narrow legacy comparison
Sponsored Display plus DSP only	Sponsored Display and DSP Overlap	Older two-way comparison
DSP plus Sponsored Products, Brands, or Display	Sponsored Ads and DSP Overlap	Improved 2/3/4-way query
Ordered touch sequence	Path-to-conversion sankey	Sequence, not overlap

Choose the Right AMC Attribution Source

2026-05-16T00:00:00Z

The Slack message came in mid-afternoon, from our paid-media lead: "Our attribution model defaults are leaving us blind. Can we build a custom attribution view in AMC, and which data source do we use?"

This is the kind of ask that sounds like one question and is really three. There is not "one" Amazon Marketing Cloud (AMC) attribution table. There are several, they are not interchangeable, and the obvious moves get you the wrong one. Ask ChatGPT for the AMC attribution table and you get back a single name with no context. Search Amazon's docs and the Custom Attribution Overview instructional query (IQ) surfaces, but the data-source comparison is buried in section 3.6 where most readers never scroll. Ping the agency and they default to amazon_attributed_events_by_conversion_time because that is the standard reporting source used by the Amazon DSP (demand-side platform) UI.

So I handed it to our agent, which has Amazon Agent Atlas behind it. Atlas indexes the AMC documentation, the instructional queries, the schema reference for every Amazon Standard Identification Number (ASIN) the catalog tracks, and the privacy framework that governs which columns you can put in a SELECT. Here is what came back.

What a model without Atlas gets wrong

I ran the same prompt through a frontier model with no retrieval. The output looked plausible. It was wrong in five specific, silent ways.

Five failure modes I saw on a single un-grounded prompt

It treated amazon_attributed_events_by_conversion_time as a custom-attribution source. That table is the standard-reporting source: competition-aware, 14-day last-touch, de-duped across campaigns. You cannot build a custom model on it.
It wrote SELECT user_id from conversions_with_relevance for an audience-building query. user_id carries the aggregation threshold "Very high" and can never appear in the final SELECT of an analytics table. The only data source that permits audience-building semantics is conversions_with_relevance_for_audiences.
It filtered WHERE engagement_scope = 'PROMOTED' against conversions. engagement_scope lives on conversions_with_relevance; the plain conversions table excludes every campaign-dependent column.
It assumed conversions and conversions_with_relevance have the same row counts. They do not. In conversions_with_relevance, a single conversion can appear on multiple rows, one per relevant campaign. The IQ example splits conversion_id 123456 across campaign_a and campaign_b.
It quoted a 14-day pixel lookback to size pixel volume in custom attribution. That is the standard-reporting lookback. Inside custom attribution, the pixel lookback is bounded only by when the pixel was tracked to the campaign, or by the query time window.

None of these failures throw an error. The query runs. The numbers look like attribution numbers. They are the wrong ones, and you only find out when the downstream model contradicts a sanity check.

What Atlas retrieves

When the agent gets the question, it does a semantic search across the amazon_ads collection, which is the corpus that backs the Amazon Ads MCP. It pulls six chunks before it writes anything:

The Custom Attribution Overview (dataset conversions) defines the two custom-attribution data sources, the 28-day ASIN relevancy rules, and the section 3.6 comparison table that names all four AMC attribution sources.
The Amazon Ads Conversions with Relevance chunk (dataset conversions_with_relevance) names both physical variants: the Analytics table (conversions_with_relevance) and the Audience table (conversions_with_relevance_for_audiences).
The Amazon Attributed Events Overview (dataset amazon_attributed_events) is the schema reference for the standard-reporting attribution data, including the LOW-threshold dimension columns.
The Data Aggregation Thresholds in AMC chunk (dataset amazon_attributed_events_by_conversion_time) classifies every column as None, Low, Medium, High, or Very high, and explains why user_id cannot be SELECTed from a normal analytics table.
The Custom Attribution Linear Model IQ template shows how a chosen base table plugs into the standard-vs-custom comparison.
The Joining and Unioning Sponsored Ads Traffic with Conversions chunk (dataset sponsored_ads_traffic) demonstrates that sponsored_ads_traffic joins to conversions_with_relevance, not conversions, because campaign columns are required.

Atlas does not pick the table for you. It surfaces the rules and lets the agent make the call.

The agent's output

The artifact for this kind of question is not SQL. It is a decision plan: a matrix of every AMC attribution data source side by side, then a rule set keyed off the operator's actual use case. Here is the machine-readable form the agent returned, before the prose write-up:

{
  "artifact": "decision_plan",
  "topic": "amc-custom-attribution-base-table",
  "rules": [
    {"use_case": "align with Amazon DSP / Sponsored Ads UI numbers", "pick": "amazon_attributed_events_by_conversion_time", "why": "standard-reporting source; custom attribution will not reconcile by design"},
    {"use_case": "Prime Day delivered-impression effect on conversions", "pick": "amazon_attributed_events_by_traffic_time", "why": "anchors on traffic time, matching the campaign window"},
    {"use_case": "de-duped pixel volume across all campaigns, exposed and un-exposed users", "pick": "conversions", "why": "excludes campaign columns; one row per conversion"},
    {"use_case": "linear / position-based / first-touch / last-touch multi-touch model with per-campaign credit", "pick": "conversions_with_relevance", "why": "campaign columns + engagement_scope required to split credit; one row per (conversion x relevant campaign)"},
    {"use_case": "build an audience from users satisfying a custom-attribution rule", "pick": "conversions_with_relevance_for_audiences", "why": "only data source permitting SELECT user_id for audience materialization"},
    {"use_case": "measure halo lift specifically", "pick": "conversions_with_relevance", "why": "filter engagement_scope = 'BRAND_HALO' vs 'PROMOTED' on the relevance table"}
  ]
}

The JSON is the compact answer the Skill can hand to an operator or downstream workflow. The matrix below is the human review layer for the same decision: every row shows where the source is safe, where it silently drifts, and whether it can materialize users for activation.

Which AMC attribution source should you choose?

Data source	What it is	ASIN coverage	Pixel coverage	`engagement_scope`?	`SELECT user_id`?	Lookback	Dedup behavior	Use it for
`amazon_attributed_events_by_conversion_time`	Standard-reporting attribution, by conversion time	Ad-attributed only	Ad-attributed only	N/A	No (`user_id` is Very high)	14-day last-touch (pixel)	De-duped across campaigns	Aligning with the standard Amazon DSP and Sponsored Ads reports
`amazon_attributed_events_by_traffic_time`	Standard-reporting attribution, by traffic time	Ad-attributed only	Ad-attributed only	N/A	No	14-day last-touch (pixel)	De-duped across campaigns	Campaign-window analyses, like Prime Day delivered impressions
`conversions`	Custom-attribution base; relevant conversions only, no campaign columns	Promoted plus brand halo	All pixel conversions tracked to the campaign, exposed and un-exposed users	No	No	28-day ASIN relevancy; pixel lookback bounded by tracking start	De-duped	Volume questions and de-duped pixel performance across campaigns
`conversions_with_relevance` (Analytics table)	Custom-attribution base plus campaign and advertiser columns	Same conversions as `conversions`, one row per relevant campaign	Same conversions as `conversions`, one row per relevant campaign	Yes (PROMOTED, BRAND_HALO, null)	No	Same as `conversions`	Duplicated across relevant campaigns	Multi-touch and split-credit custom models (linear, position-based, first-touch, last-touch)
`conversions_with_relevance_for_audiences` (Audience table)	Audience-table variant of `conversions_with_relevance`	Same as `conversions_with_relevance`	Same as `conversions_with_relevance`	Yes	Yes, the only data source that permits `SELECT user_id` for audience-building	Same as `conversions_with_relevance`	Same	Materializing custom-attribution audiences for activation

A note on framing: Atlas's section 3.6 comparison lists four AMC attribution data sources by splitting amazon_attributed_events into the _by_conversion_time and _by_traffic_time variants. Other framings collapse those two into one and treat conversions_with_relevance_for_audiences as the fourth distinct surface. The matrix above shows all five rows so both views are visible; the decision rules below collapse to the four-way operator choice.

Decision rules

If the use case is "align my custom model output with the numbers in the Amazon DSP or Sponsored Ads UI," pick amazon_attributed_events_by_conversion_time, because it is the standard-reporting source and custom attribution will not reconcile by design.
If the use case is "Prime Day delivered-impression effect on conversions," pick amazon_attributed_events_by_traffic_time, because it anchors on traffic time and matches the campaign window.
If the use case is "de-duped pixel volume across all campaigns the pixel is tracked to, exposed and un-exposed users," pick conversions, because it excludes campaign columns and emits one row per conversion.
If the use case is "linear, position-based, first-touch, or last-touch custom model with per-campaign credit," pick conversions_with_relevance, because campaign columns and engagement_scope are required to split credit; expect one row per (conversion x relevant campaign).
If the use case is "build an audience from the users who satisfy a custom attribution rule," pick conversions_with_relevance_for_audiences, because it is the only data source that permits SELECT user_id for audience materialization.
If the use case is "measure halo lift specifically," pick conversions_with_relevance and filter on engagement_scope = 'BRAND_HALO' versus 'PROMOTED'.

A few things to notice about how the agent broke this apart.

The amazon_attributed_events_* family is not a custom-attribution base table. It is competition-aware, de-duped across campaigns, and follows fixed last-touch logic. Use it when you need to align with standard reporting numbers. Never use it when you are modeling, because the model logic is already baked in and you cannot unbake it.

The split between conversions and conversions_with_relevance is a row-shape difference, not a coverage difference. Both tables cover the same set of relevant conversions. conversions_with_relevance adds campaign and advertiser dimensions, and as a consequence it emits one row per relevant campaign per conversion. A dedup-aware question like "how many users converted in the window, period" uses conversions. A multi-touch model that splits credit across campaigns uses conversions_with_relevance because the per-campaign rows are exactly what gets weighted.

The audience-table variant exists because of aggregation thresholds, not because someone wanted three tables instead of two. user_id is classified Very high, which means a normal analytics table cannot put it in a final SELECT, cannot filter it against a literal value, and cannot use it as a join or group-by key against literals. The _for_audiences companion is the data source that allows audience-building semantics, and it is the only one. Anything materializing user-level audiences from custom attribution flows through it.

The engagement_scope column on conversions_with_relevance is the lever for halo measurement. Values are PROMOTED for the promoted ASIN, BRAND_HALO for halo conversions to other ASINs from the same brand, and null for pixel conversions. Any custom model that wants to isolate halo lift filters on this column. Any custom model that ignores it is silently treating halo and promoted as the same thing.

The footnotes the agent surfaced unprompted

This is the part where retrieval grounding earns its keep. None of these were asked for. All of them mattered.

Six things the agent surfaced that the operator did not ask about

The 28-day ASIN relevancy window for custom attribution is double the brand-based 14-day window in amazon_attributed_events_by_conversion_time and _by_traffic_time. Higher per-ASIN conversion counts in custom attribution are expected, not a bug.
The custom-attribution data sources are not competition-aware and include both viewable and non-viewable impressions. Two more reasons custom-attribution conversion counts run higher than the attributed-events numbers.
Pixel conversions in conversions and conversions_with_relevance do not require an ad impression or click to be relevant. If a pixel was tracked to a DSP campaign, all pixel conversions appear, including from users who were never exposed.
Pixel lookback inside custom attribution is bounded by when the pixel was tracked to the campaign, or by the query time window. It is not the 14-day last-touch lookback that amazon_attributed_events_* uses. Sizing pixel volume with the wrong lookback is a common silent error.
engagement_scope is always PROMOTED for pixel conversions (when event_category = 'pixel'), and halo_code is null for pixels. Both columns are LOW-threshold dimensions and both live only on conversions_with_relevance.
user_id (aggregation threshold Very high) can never appear in the final SELECT, cannot be filtered with literal values, and cannot be used as a join or group-by key against literals. It can, however, be COUNT or COUNT DISTINCTed, which is how reach, optimal-frequency, and customer-journey queries get written. The _for_audiences audience table exists as a separate physical surface precisely because the analytics tables cannot do the audience-shaped thing.

Most of these would have cost an hour each to discover the hard way. Compounded across a quarter, they are the difference between a custom attribution program that ships and one that gets quietly abandoned.

What happens next

The decision plan is the input, not the output. Once you have picked the base table, the operational moves diverge.

If you picked conversions_with_relevance for a multi-touch model, the next step is to schedule the linear or position-based IQ as a recurring AMC workflow. Package it as a verified Skill and export the campaign-weighted credit to a dashboard. If you picked conversions_with_relevance_for_audiences, the next step is to activate the resulting user set as an AMC audience, following the same pattern documented in the cart-abandoner audience guide. If you picked conversions for de-duped pixel volume across campaigns, feed it into the same pipeline pattern used in the Subscribe & Save lift workflow, substituting your custom-attribution filters.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings AMC and campaign signals, the Selling Partner MCP can add catalog context when ASIN eligibility matters, Atlas grounds the source selection, and Skills keep the attribution model on a reviewable schedule.

If you picked amazon_attributed_events_by_conversion_time or _by_traffic_time, stop. You are doing standard reporting alignment, not custom modeling. Route the work to the standard-reports surface and save AMC for the questions standard reports cannot answer.

Why this matters

Pick the wrong base table and every downstream model inherits the wrong numbers, silently, for as long as the workflow runs.

Next in the series: building a path-to-conversion view in AMC that stitches DSP, Sponsored Products, Sponsored Brands, and Sponsored Display into a single touch-ordered timeline. Custom attribution sets the base table; path analysis is what you do with it.

Evaluate Prime Day AMC Lookalikes

2026-05-13T00:00:00Z

The Slack message came in two days after the Prime Day campaign closed: "The lookalike audience shipped. Did it actually beat last year's rule-based audience, or did we just add a new prospecting line item?"

That question should not be answered from an Amazon DSP screenshot. The operator needs a matched-window read in Amazon Marketing Cloud: same promotional period, comparable spend, and the same conversion definition. If the lookalike audience reached more shoppers but bought new-to-brand customers at a worse cost, it did not win. It scaled noise. If it held cost per new-to-brand customer while expanding reach, the seed is worth keeping.

So I asked our agent in Claude. The agent has Amazon Agent Atlas behind it: a corpus of AMC playbooks, instructional queries, reporting patterns, and audience notes. The same prompt would work in ChatGPT because Kuudo exposes that Amazon context through standards-based Model Context Protocol (MCP), not through one chat app. If the follow-up belongs in code, Cursor or Codex can use the same server. If it needs to run weekly, n8n or Make can call the same workflow. The AI client changes; the grounded Amazon context does not.

What ChatGPT or Claude without Atlas gets wrong in lookalike evaluation

I ran the same ask without retrieval. The answer sounded reasonable: pull conversions, compare totals, report lift. That is not enough for a Prime Day audience decision.

Five failure modes in the un-grounded response

It compared the lookalike audience to total campaign performance instead of to last year's rule-based audience baseline. That makes the lookalike inherit credit from every other tactic in the flight.
It treated reach as the win condition. For Prime Day prospecting, reach only matters if new-to-brand efficiency holds.
It ignored the attribution settling period. Reading the audience too early undercounts late conversions and can make the model look worse than the baseline.
It did not normalize for spend. A line item with 40% more spend should produce more conversions; the question is whether it produced cheaper or more incremental customers.
It did not create a next action. The operator needs a keep, rotate, or rebuild decision, not a dashboard summary.

This is the same problem as the seed post in reverse. The model can write the query-shaped thing. The Atlas-grounded agent knows which comparison decides the next Prime Day seed.

What Atlas retrieves for Prime Day lookalike measurement

When the agent gets the question, it pulls the audience-building post's downstream playbook pieces before writing SQL:

The AMC Lookalike Audiences for Promotional Events playbook: the source of the Prime Day lead-in and lead-out logic, plus the expectation that performance is evaluated after activation rather than at seed creation.
The Introduction to AMC Lookalike Audiences instructional query: the expansion-type context that explains why Balanced, Similar, and Broad should be evaluated differently.
The Customer Journey Analytics playbook: the follow-on analysis path for checking whether the lookalike is creating new conversion journeys or entering journeys the rule-based audience already covered.
The DSP and AMC conversion reporting table notes: the table-shape reminders for dsp_impressions, dsp_clicks, and amazon_attributed_events_by_traffic_time.
The Subscribe & Save lift analysis pattern: the upstream check that tells the operator whether SnS behavior was strong enough to be a seed in the first place.

The seed can also be rebuilt around Amazon Standard Identification Number (ASIN) behavior if the evaluation shows that subscription buyers reached well but did not produce enough new customers.

The retrieved set matters because this is not just a measurement query. It is a decision about whether the next seed should stay SnS, rotate to multi-ASIN purchasers, or use a spend threshold.

The agent's working output: AMC lookalike lift SQL

The agent produced an evaluation skeleton that compares the activated lookalike line item with a prior rule-based audience baseline. The placeholder IDs are intentionally visible so the operator can audit what is being compared before running it.

/* AMC lookalike audience evaluation skeleton
   Run after the promotional flight closes and attribution has settled.
   Last verified: 2026-05-13.

   Replace:
  - LOOKALIKE_CAMPAIGN_ID with the Prime Day lookalike line item/campaign
   - BASELINE_CAMPAIGN_ID with last year's rule-based audience campaign
   - flight windows with matched Prime Day periods
*/

WITH comparison_windows AS (
  SELECT
    'lookalike_2026' AS cohort,
    TIMESTAMP '2026-07-01 00:00:00' AS window_start,
    TIMESTAMP '2026-07-15 23:59:59' AS window_end,
    'LOOKALIKE_CAMPAIGN_ID' AS campaign_id
  UNION ALL
  SELECT
    'rule_based_2025' AS cohort,
    TIMESTAMP '2025-07-01 00:00:00' AS window_start,
    TIMESTAMP '2025-07-15 23:59:59' AS window_end,
    'BASELINE_CAMPAIGN_ID' AS campaign_id
),
impressions AS (
  SELECT
    w.cohort,
    i.user_id,
    COUNT(*) AS impressions,
    SUM(i.total_cost) AS spend
  FROM comparison_windows w
  JOIN dsp_impressions i
    ON i.campaign_id = w.campaign_id
   AND i.impression_dt_utc BETWEEN w.window_start AND w.window_end
  WHERE i.user_id IS NOT NULL
  GROUP BY 1, 2
),
conversions AS (
  SELECT
    w.cohort,
    a.user_id,
    COUNT(*) AS orders,
    SUM(a.total_product_sales) AS sales,
    SUM(CASE WHEN a.new_to_brand = TRUE THEN 1 ELSE 0 END) AS ntb_orders
  FROM comparison_windows w
  JOIN amazon_attributed_events_by_traffic_time a
    ON a.campaign_id = w.campaign_id
   AND a.event_dt_utc BETWEEN w.window_start AND w.window_end
  WHERE a.conversion_event_subtype = 'order'
    AND a.user_id IS NOT NULL
  GROUP BY 1, 2
),
cohort_rollup AS (
  SELECT
    i.cohort,
    COUNT(DISTINCT i.user_id) AS reached_users,
    SUM(i.impressions) AS impressions,
    SUM(i.spend) AS spend,
    COUNT(DISTINCT c.user_id) AS converting_users,
    SUM(c.orders) AS orders,
    SUM(c.sales) AS sales,
    SUM(c.ntb_orders) AS ntb_orders
  FROM impressions i
  LEFT JOIN conversions c
    ON i.cohort = c.cohort
   AND i.user_id = c.user_id
  GROUP BY 1
)
SELECT
  cohort,
  reached_users,
  spend,
  orders,
  sales,
  ntb_orders,
  orders / NULLIF(reached_users, 0) AS conversion_rate,
  ntb_orders / NULLIF(orders, 0) AS ntb_share,
  spend / NULLIF(ntb_orders, 0) AS cost_per_ntb_order,
  sales / NULLIF(spend, 0) AS roas
FROM cohort_rollup
ORDER BY cohort;

Three choices matter in that SQL. First, the comparison is campaign-scoped, not account-scoped. The lookalike line item should not borrow credit from branded search, retargeting, or other Prime Day tactics.

Second, the windows are explicit. If you compare a 2026 lead-in window to a 2025 full-event window, the result will look precise and be useless. The agent forces both cohorts into matched promotional periods.

Third, the output includes cost_per_ntb_order, not just return on ad spend (ROAS). For a lookalike audience, the question is not only whether it sold product. The question is whether it found new customers at a cost worth repeating in Amazon demand-side platform (DSP) activation.

The footnotes the agent surfaces before you trust the lift read

Things Atlas surfaced that the operator did not ask for

Do not evaluate before attribution settles. A same-day read can undercount late attributed conversions and distort the lookalike result.
Spend-normalize before calling lift. More spend usually means more orders. Efficiency metrics decide whether the audience actually improved the plan.
Compare to the right baseline. Last year's rule-based audience is a better baseline than total Prime Day performance because it isolates audience strategy.
Treat expansion type as a test variable. If Balanced scaled reach but lost new-to-brand efficiency, test Similar next. If Similar is efficient but too small, test Broad.
Use path analysis as the next diagnostic. If the lookalike appears in the same journeys as existing retargeting, it may not be creating new demand.

The footnotes change the shape of the readout. Without them, the operator gets a table. With them, the operator gets a decision tree.

What happens next: keep, rotate, or rebuild the seed

The agent turns the output into three possible decisions. If the lookalike improves new-to-brand share and lowers cost per new-to-brand order, keep the seed and test a tighter expansion type. If reach improves but efficiency falls, rotate the seed from SnS subscribers to multi-ASIN purchasers or a spend threshold. If the rule-based audience still wins on conversion rate and cost, keep lookalikes in the lead-in phase and use rule-based audiences for lead-out retargeting.

This is where the standards-based setup matters operationally. If you are in Claude, ask for the recommendation in plain language. If your team works in ChatGPT, ask the same question there. If the marketing analyst wants to inspect the SQL, open it in Cursor or Codex. If the read should run every Monday after a promotional flight, schedule it in n8n or Make. Kuudo speaks MCP, so the same Amazon context follows the work into whichever standards-supporting client your team prefers.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings AMC and DSP signals, the Selling Partner MCP can add catalog and ASIN context, Atlas grounds the baseline comparison, and Skills keep the post-flight read on a repeatable schedule.

The follow-on analysis is the conversion path. If the lookalike wins, use the path-to-conversion Sankey workflow to see whether it is creating new journeys or merely joining paths your existing campaigns already owned.

Why standards-based AI clients make this more useful

This is not a Claude workflow, a ChatGPT workflow, or a Cursor workflow. It is an Amazon Marketing Cloud workflow exposed through a standard interface. The useful part is the stable context: the tables, playbooks, thresholds, and audience history. The chat or coding tool is just where the operator happens to be working.

That is the same reason the evaluation produces an action instead of a report. The agent can move from question to SQL to scheduling because the context is portable. It can answer in chat, edit in code, and run in a workflow tool without rewriting the operating logic.

If your lookalike readout stops at reach and ROAS, it has not answered the Prime Day question.

Next: use path-to-conversion analysis to see whether the lookalike audience created new customer journeys or just overlapped with existing retargeting paths.

Segment AMC Customers by CLTV

2026-05-11T00:00:00Z

"Which of our customer cohorts are actually worth the most over time, and which look profitable but aren't?" — that was my Slack question on a Tuesday, and I handed it to our Amazon Agent Atlas with a strict brief: no fluffy summaries, just a query-first proof of concept. I already tried three obvious approaches: a ChatGPT-style single-shot which ignored Amazon Marketing Cloud's 12-month customer lifetime value (CLTV) cohort window, the AMC docs alone that described CLTV but didn't surface the exact AVG(... ) OVER () CASE pattern we needed, and an agency pitch deck that happily swapped segment labels and ignored activation timing. I asked the agent to return a per-user labeling of High Value / Growth Potential / Revenue Potential / Low Value ready for a 48-hour Amazon demand-side platform (DSP) activation window for resulting audiences.

What a model without Atlas gets wrong

I ran the same prompt through a frontier model with no retrieval. The output read confidently. It was wrong in five places, each subtle enough that an operator would only catch the failures at activation time, when the DSP audience comes back empty or the segment labels don't match the deck.

This is the differentiator. The model isn't lying. It is producing a plausible-looking artifact that fails against the AMC playbook's actual mechanics: the audience-build table variant, the composite window-function semantics, the activation timing, the named segment taxonomy, and the diagnostic dimension that catches drift over time.

What Atlas retrieves

"Understanding Customer Long-Term Value (CLTV)" playbook: the canonical AMC CLTV reference that explains CLTV versus return on ad spend (ROAS) and reminds us the AMC long-term window is bounded to 12 months. (source: Customer long-term value (CLTV): Amazon Marketing Cloud)
"Lifetime * Value CLTV SQL Export Logic": the composite-score template that defines the Lifetime Ratio and the overall Lifetime × Value construct. This includes the formula Lifetime Ratio = Purchase Frequency × Purchase Quantity × User Lifetime ratios. (source: Lifetime * Value CLTV SQL Export Logic)
"Audience Labeling" CASE statement for the four segments: the exact AVG(...) OVER () CASE pattern you need to convert scores into High Value, Growth Potential, Revenue Potential, and Low Value labels. (source: Audience segmentation (based on CLTV))
"Identify high value customer segments": a data-interpretation guide with percentile examples and audience-size guidance so you can pick seed thresholds and respect rule-based audience (RBA) and lookalike (LAL) guardrails. (source: Identifying High Value Customer Segments: Flexible Amazon shopping insights)
"CLTV Audience Segmentation (Year-Over-Year)": the diagnostic view and recommended recurring check to detect cohort migration between segments over time. (source: Customer long-term value (CLTV): Year-over-year guidance)

The agent's output

-- Per-user CLTV segmentation skeleton for AMC
WITH
-- 1) base events: filter to the 12-month AMC window and to the audience build table
events AS (
    SELECT
        user_id,
        event_time,
        tracked_asin, -- optional: later join to ASIN->category mapping for descriptive stats
        quantity,
        sale_price,   -- revenue per event (use Paid Features mappings if available)
        ad_spend      -- spend attributed to the event (nullable; a proxy may be filled for off-Amazon)
    FROM conversions_for_audiences -- use conversions_all for sizing/coverage experiments
    WHERE event_time BETWEEN DATE_ADD('month', -12, CURRENT_DATE) AND CURRENT_DATE
),

-- 2) per-user purchase aggregates
user_purchases AS (
    SELECT
        user_id,
        COUNT(DISTINCT event_time)                             AS purchase_count,
        SUM(quantity)                                         AS total_units,
        SUM(COALESCE(sale_price,0) * COALESCE(quantity,0))    AS total_revenue,
        SUM(COALESCE(ad_spend,0))                             AS total_ad_spend,
        MIN(event_time)                                       AS first_purchase_ts,
        MAX(event_time)                                       AS last_purchase_ts
    FROM events
    GROUP BY user_id
),

-- 3) derived per-user metrics required by the playbook
user_metrics AS (
    SELECT
        user_id,
        purchase_count,
        total_units,
        total_revenue,
        total_ad_spend,
        -- user lifetime in days within the 12-month window (inclusive)
        DATE_DIFF('day', first_purchase_ts, last_purchase_ts) + 1 AS user_lifetime_days,
        -- purchase frequency: purchases per active 30-day period (approx)
        CASE WHEN DATE_DIFF('day', first_purchase_ts, last_purchase_ts) >= 30
            THEN purchase_count / (GREATEST(DATE_DIFF('day', first_purchase_ts, last_purchase_ts),1) / 30.0)
            ELSE purchase_count
        END AS purchase_frequency,
        -- purchase quantity per purchase
        CASE WHEN purchase_count > 0 THEN total_units / CAST(purchase_count AS DOUBLE) ELSE 0 END AS purchase_quantity,
        -- customer cost: currently only ad spend; retention_cost can be added to this field
        (total_ad_spend) AS customer_cost
    FROM user_purchases
),

-- 4) cohort selection: cohort_month as a simple acquisition cohort; replace with channel or category as needed
cohorted AS (
    SELECT
        um.*,
        DATE_FORMAT(first_purchase_ts, '%Y-%m') AS cohort_month
    FROM user_metrics AS um
),

-- 5) cohort-level means used to normalize into ratios
cohort_stats AS (
    SELECT
        cohort_month,
        AVG(purchase_frequency)     AS avg_purchase_frequency,
        AVG(purchase_quantity)      AS avg_purchase_quantity,
        AVG(user_lifetime_days)     AS avg_user_lifetime_days,
        AVG(total_revenue)          AS avg_revenue,
        AVG(customer_cost)          AS avg_cost,
        COUNT(*)                    AS cohort_size
    FROM cohorted
    GROUP BY cohort_month
),

-- 6) per-user ratios (Lifetime and Value components)
ratios AS (
    SELECT
        c.user_id,
        c.cohort_month,
        -- Lifetime Ratio = Purchase Frequency Ratio × Purchase Quantity Ratio × User Lifetime Ratio
        (COALESCE(c.purchase_frequency,0) / NULLIF(s.avg_purchase_frequency,0)) *
        (COALESCE(c.purchase_quantity,0)  / NULLIF(s.avg_purchase_quantity,0)) *
        (COALESCE(c.user_lifetime_days,0) / NULLIF(s.avg_user_lifetime_days,0)) AS lifetime_ratio,
        -- Value side: revenue vs cost ratios (higher revenue and lower cost should increase value)
        (COALESCE(c.total_revenue,0) / NULLIF(s.avg_revenue,0)) AS revenue_ratio,
        (COALESCE(c.customer_cost,0) / NULLIF(s.avg_cost,1)) AS cost_ratio
    FROM cohorted c
    JOIN cohort_stats s USING (cohort_month)
),

-- 7) per-user scores: lifetime_score (product) and value_score (revenue - cost composite)
scores AS (
    SELECT
        r.user_id,
        r.cohort_month,
        r.lifetime_ratio AS lifetime_score,
        (r.revenue_ratio - r.cost_ratio) AS value_score
    FROM ratios r
)

-- Final: label users using global AVG(...) OVER () thresholds so both legs compare to the same population
SELECT
    s.user_id,
    s.cohort_month,
    s.lifetime_score,
    s.value_score,
    CASE
        WHEN s.lifetime_score >= AVG(s.lifetime_score) OVER () AND s.value_score >= AVG(s.value_score) OVER () THEN 'High Value'
        WHEN s.lifetime_score >= AVG(s.lifetime_score) OVER () AND s.value_score <  AVG(s.value_score) OVER () THEN 'Growth Potential'
        WHEN s.lifetime_score <  AVG(s.lifetime_score) OVER () AND s.value_score >= AVG(s.value_score) OVER () THEN 'Revenue Potential'
        WHEN s.lifetime_score <  AVG(s.lifetime_score) OVER () AND s.value_score <  AVG(s.value_score) OVER () THEN 'Low Value'
        ELSE 'Unlabeled'
    END AS customer_segment
FROM scores s;

I kept the SQL intentionally modular so the parts are pluggable into our pipeline. The agent used the composite formula from the "Lifetime * Value CLTV SQL Export Logic": Lifetime Ratio = Purchase Frequency × Purchase Quantity × User Lifetime ratios, and modeled value_score as a revenue-minus-cost composite so that higher revenue and lower cost increase value. Cohorting is done by first_purchase month as a placeholder; replace cohort_month with acquisition_channel or tracked_asin category if that's more meaningful for your ops.

I also made two operational choices: use conversions_for_audiences for the canonical audience build exports and run the same query against conversions_all only when you need a sizing or coverage experiment. Finally, ensure the AVG(...) OVER () comparisons are computed over the same population so the thresholds are comparable.

The footnotes the agent surfaced unprompted

What happens next

Export the four labeled audiences as rule-based audience manifests and activate into Amazon DSP with differentiated bidding: Higher bid for High Value, conversion-first creatives for Growth Potential, revenue-focused bids for Revenue Potential while excluding low-margin ASINs, and exclude or suppress Low Value audiences from high-cost buys. (See Swim Lane #3 and #4 from the Off-Amazon Conversions Playbook.)
Schedule this query as a recurring AMC job monthly, aligned to cohort_month granularity, and push audiences after respecting the 48-hour DSP activation window for resulting audiences.
Run the year-over-year diagnostic at the same cadence and produce cohort-migration charts that bucket users by percentile so you can detect movement between Growth Potential and High Value or slides toward Low Value.
For ops handoff: publish an audience manifest with Amazon Standard Identification Number (ASIN) category mappings, provide audience sizes and seed counts, and filter out cohorts under minimum seed thresholds before requesting DSP activation. Consider running overlap scoring against Persona Builder API outputs to avoid audience saturation.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings AMC and campaign signals, the Selling Partner MCP can add catalog context for ASIN grouping, Atlas grounds the CLTV taxonomy, and Skills turn the segment export into a reviewed recurring automation.

Why this matters

A foundation model can write CLTV-shaped SQL. What it cannot reliably do is produce a query that compiles against the AMC table variants Audiences actually accepts, uses the exact composite window-function pattern the CLTV playbook prescribes, labels users with the four-segment taxonomy operators downstream are already wired for, and bakes in the 48-hour activation window plus the year-over-year diagnostic. The agent didn't have to remember any of that. It had to know where to look.

Composite Lifetime × Value cohorting.

Next guide in the series: moving from segmentation to actual bidding rules. What amazon_rules says you should do once you have a High Value cohort: Path to conversion sankey.

Build High-Value AMC Audience Seeds

2026-05-11T00:00:00Z

The Slack ping landed on a Thursday from our CRM lead: "Who are our actual best customers, and can we build a demand-side platform (DSP) audience that targets people who look like them?"

It sounds like a five-minute question. Ask ChatGPT and you get a single "high value" SQL block, almost always a total-spend filter, usually against the wrong table variant, almost never inside the seed-size band Amazon Marketing Cloud actually requires. Search the AMC console's Instructional Query library and you find the answer, except it lives in two separate playbooks you have to stitch together yourself. By the time you've reconciled them, the campaign launch has slipped a day.

So I asked our agent. It runs on Amazon Agent Atlas, a curated corpus of AMC playbooks, DSP activation guides, and event-subtype references indexed for semantic retrieval. The answer came back in the shape the IQ library actually recommends: three seed audiences, tested separately, each sized into the 1,000 to 450,000 buffer before activation.

What a model without Atlas gets wrong

I ran the same prompt through a frontier model with no retrieval first. The SQL it produced looked competent. It would have failed at audience creation in at least four distinct ways.

Five failure modes I saw in a single un-grounded response

It selected user_id from conversions_all. Audience-build queries that return user IDs must run against the _for_audiences variant, in this case conversions_all_for_audiences. The sizing wrapper does the opposite: it counts user IDs against conversions_all. The Atlas chunk is explicit, "change user_id to count(user_id), remove the suffix of _for_audiences in the table name."
It returned one blended seed that combined SnS, multi-purchase, and a spend threshold joined with AND. The result was an overly specific cohort of around 300 users. The IQ guidance is the opposite, "we recommend testing these audiences separately to avoid overly specific seeds."
It hallucinated the event filter as event_subtype = 'SnS'. The real values are event_subtype IN ('firstSnSOrder', 'repeatSnSOrder'). The repeatSnSOrder value was added to Flexible Shopping Insights on 02/05/2024, so any model with a training cutoff before that date does not know it exists and will quietly miss every recurring SnS shipment.
It said nothing about the 500 to 500,000 hard sizing bound. Audience refresh fails outside that range, silently for the operator until the DSP line item runs empty.
It left a comment as the final line of the SQL. AMC's audience pusher rejects any query whose last line is a comment, with an error message that does not tell you which line.

Any one of these would have cost the launch day. The combination would have looked like a working audience right up until the DSP line item failed to spend.

What Atlas retrieves

When the agent gets the question, it does a semantic search across the amazon_ads collection and pulls six chunks before writing a single line of SQL:

The Introduction to AMC Lookalike Audiences playbook, section 3.2, which enumerates the three high-value seed strategies (Subscribe and Save, Multiple Purchases, Total Purchase Value) and gives the verbatim recommendation to test them separately to avoid overly specific seeds.
The same Introduction to AMC Lookalike Audiences chunk on the companion measurement query template, the 500 to 500,000 hard bound, and the recommended 1,000 to 450,000 seed-size buffer.
The Understanding Amazon's Subscribe & Save Repeat Purchases chunk, which documents the firstSnSOrder and repeatSnSOrder event subtypes, the 02/05/2024 enhancement date when repeat signals were added, and the Sandbox restriction on SnS data.
The Flexible Shopping Insights Trial Guide chunk, which carries the working conversions_all_for_audiences template for the SnS seed and the audience-vs-sizing table-name swap pattern.
The Identifying High Value Customer Segments chunk, which frames Total Spend seeds through percentile rank (top 71-100, top 96-100) rather than a flat dollar threshold, and endorses these segments specifically as lookalike seeds.
The AMC Lookalike Audiences for Promotional Events chunk, which explains the gap lookalikes fill (the high-value new-to-brand and impulse buyers that DSP rule-based audiences miss) and warns against using lookalikes in the lead-out phase of a promotion.

Atlas does not generate the SQL. It surfaces the playbooks with the right caveats attached, and the agent adapts them.

The agent's output

The agent returned four SQL blocks: three seed audience queries and one companion sizing wrapper. The seed queries go into the AMC Audiences query editor, the sizing wrapper runs in the main query editor against the non-_for_audiences table.

-- =========================================================================
-- Companion measurement query (sizing): runs in the MAIN AMC query editor
-- against conversions_all (not _for_audiences). Use this BEFORE pushing each
-- seed to audience creation. Hard fail: <500 or >500,000.
-- Recommended buffer: 1,000 to 450,000.
-- =========================================================================
SELECT
    COUNT(user_id) AS user_count
FROM (
    {UPDATE: paste one of the three seed queries below here, but swap
     conversions_all_for_audiences -> conversions_all and
     SELECT DISTINCT user_id -> SELECT user_id }
)
GROUP BY 1


-- =========================================================================
-- SEED 1: Subscribe & Save subscribers
-- Run in the AMC AUDIENCES query editor (NOT the main editor) because it
-- selects individual user_id values.
-- STRIP ALL COMMENT LINES before pushing to audience creation. The trailing
-- GROUP BY 1 at the very end is what makes the push succeed.
-- =========================================================================
WITH sns_users AS (
    SELECT
        user_id,
        COUNT(DISTINCT conversion_id) AS sns_purchase_times
    FROM conversions_all_for_audiences
    WHERE event_subtype IN ('firstSnSOrder', 'repeatSnSOrder')
      -- Optional: scope to your ASIN(s). Remove this AND clause to capture
      -- all SnS purchasers across the brand.
      AND tracked_asin IN ('{ASIN_1}', '{ASIN_2}')   -- {UPDATE} or remove
    GROUP BY user_id
)
SELECT DISTINCT user_id
FROM sns_users
WHERE sns_purchase_times >= 1
GROUP BY 1


-- =========================================================================
-- SEED 2: Multi-Purchase (users with multiple distinct ASIN orders)
-- =========================================================================
WITH multi_asin_users AS (
    SELECT
        user_id,
        COUNT(DISTINCT tracked_asin) AS distinct_asin_count
    FROM conversions_all_for_audiences
    WHERE event_subtype = 'order'
      AND tracked_asin IN ('{ASIN_1}','{ASIN_2}','{ASIN_3}')  -- {UPDATE}
    GROUP BY user_id
)
SELECT DISTINCT user_id
FROM multi_asin_users
WHERE distinct_asin_count >= 2   -- {UPDATE: raise to 3+ if seed > 450k}
GROUP BY 1


-- =========================================================================
-- SEED 3: Total Spend threshold
-- Threshold is configurable. Atlas recommends a percentile-rank approach
-- (e.g., top 71-100 percentile) rather than a hardcoded dollar value.
-- A flat dollar threshold is shown here for simplicity.
-- =========================================================================
WITH spend_by_user AS (
    SELECT
        user_id,
        SUM(purchase_amount) AS total_spend
    FROM conversions_all_for_audiences
    WHERE event_subtype = 'order'
      AND tracked_asin IN ('{ASIN_1}','{ASIN_2}','{ASIN_3}')  -- {UPDATE}
    GROUP BY user_id
)
SELECT DISTINCT user_id
FROM spend_by_user
WHERE total_spend >= {SPEND_THRESHOLD}   -- {UPDATE: configurable, e.g., 200}
GROUP BY 1

Three queries, not one. The IQ library explicitly recommends testing these audiences separately to avoid overly specific seeds, and the math agrees: combining filters with AND collapses the overlap into a cohort that often falls under the 500-user hard bound. The operator runs all three through the companion sizing query first, confirms each lands in the 1,000 to 450,000 buffer, and only then optionally unions them. The agent does not start by unioning. The table name swaps between the seed and the sizing wrapper: conversions_all_for_audiences is required for the seed queries because AMC's audience builder only permits SELECT user_id against the _for_audiences table variants, while the sizing wrapper runs in the main query editor against the regular conversions_all table. The agent stages the swap inside the wrapper so the operator cannot paste the wrong table name into the wrong editor.

The SnS filter includes both firstSnSOrder and repeatSnSOrder. Limiting to repeatSnSOrder alone would exclude users on their first scheduled subscription order, which is exactly the cohort you want to lookalike against. Both values together capture the full SnS-engaged audience that became available on 02/05/2024 when Flexible Shopping Insights was enhanced to include repeat purchase signals. The Multi-Purchase and Total Spend queries are not verbatim Atlas snippets. The agent adapted the SnS template pattern, swapping the WHERE filter to event_subtype = 'order' and the aggregation to either COUNT(DISTINCT tracked_asin) or SUM(purchase_amount) per user.

The Total Spend threshold is a placeholder. The right number is corpus-specific. Atlas points at a percentile-rank approach (top 71-100 percentile, or the tighter top 96-100 for premium-spend seeds) rather than a hardcoded dollar value. The {SPEND_THRESHOLD} token in the SQL is operator-configurable, and the parenthetical "e.g., 200" is illustrative only, not a recommendation.

The footnotes the agent surfaced unprompted

This is the part that separates retrieval-grounded responses from fluent guesses. Without being asked, the agent attached a short list of caveats to the artifact.

What Atlas surfaced that the operator didn't ask for

Hard sizing bounds: 500 and 500,000. Audience refresh fails if the seed size falls below 500 or above 500,000. Aim for the 1,000 to 450,000 buffer to keep refreshes alive as the cohort drifts.
Sandbox gap. The sns_subscription_id field and the repeat SnS purchase signals are not available in AMC Sandbox. You cannot dry-run the SnS seed there. Run against production, or you will see zero rows and assume the seed is broken.
Version cliff on 02/05/2024. Repeat SnS purchase signals were added to Flexible Shopping Insights on that date. Any model whose training data predates it will produce a SnS seed that returns zero rows. This is one of the cleanest examples of what Atlas catches that an ungrounded model cannot.
Comment-line trap. Per the IQ playbook, we recommend removing all comment lines from the query before pushing to audience creation. The trailing GROUP BY 1 works as a safe terminator because the audience pusher will not accept a query whose last line is a comment, but only if the comments above are also stripped.
Category eligibility. Only certain product categories (Beauty, Grocery, and a handful of others) are eligible for Subscribe & Save. If your catalog sits outside those categories, the SnS seed will undersize regardless of how broad you make the ASIN filter.
Not for the lead-out phase. Lookalike audiences are not appropriate for the lead-out phase of a promotional campaign, where the NTB mix shifts. For lead-out, switch to AMC rule-based audiences instead.

Each of these would have cost the operator at least an hour to discover by hitting the failure first.

What happens next

Once each seed lands inside the 1,000 to 450,000 buffer, the operator pushes it to AMC Audiences from the Audiences query editor. AMC compiles the audience and activates it to Amazon DSP. The standard DSP activation lag is around 48 hours before the audience materializes and becomes targetable in line items, so the push has to land at least two days before the campaign launch, not on the day of.

The agent also recommends setting each seed query as a recurring AMC workflow so the lookalike model rebuilds on a cadence. Weekly is typical for high-value cohorts, because the SnS seed in particular grows as repeat purchase signals accumulate week over week. Static lookalikes age out fast.

For the DSP build, the agent targets each lookalike in a separate line item rather than stacking them in one. Three line items, one per seed, gives a clean read on NTB rate and return on ad spend (ROAS) by seed strategy after the first 14 days. The Total Spend lookalike usually wins on order value, the Multi-Purchase lookalike on order frequency, and the SnS lookalike on retention. Knowing which is which informs the next round of seeds.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings AMC and DSP signals, the Selling Partner MCP can add catalog and Amazon Standard Identification Number (ASIN) context, Atlas grounds the seed rules, and Skills keep each seed test on a reviewable cadence.

Why this matters

Three seeds, three sizes, one DSP activation: the difference between a good guess and a working audience. The seed strategies are not novel, but the constraints around them are, and most of those constraints are not in any single playbook. The agent's value is not that it wrote better SQL than a model could write from memory. The agent's value is that it pulled the right two playbooks, applied the right table swap, surfaced a six-month-old event_subtype that most models still do not know about, and attached the activation timing the operator needed before they hit it.

If your agents are guessing at AMC high-value seeds, they don't have to be.

Part of an ongoing series on how agents grounded in Amazon Agent Atlas approach real AMC workflows. Next: lookalike audiences for Prime Day, taking these three seeds through the promotional-event activation playbook, including the lead-in versus lead-out split that determines whether a lookalike belongs in the line item at all.

Re-Engage Lapsed AMC Loyalists

2026-05-11T00:00:00Z

The Slack message landed during a retention review: "We have customers who bought from us three or more times last year, and we haven't heard from them in 90 days. Can we get them into a demand-side platform (DSP) campaign before they churn for good?"

It sounds like a five-minute audience build. In practice the trap is in the tables, the lookback, and the size floor. Amazon Marketing Cloud (AMC) Audiences uses a different set of tables than the main query editor. The lookback you actually want is a 180-day rolling window, not a calendar quarter. The audience won't activate at all if it resolves to fewer than 2,000 distinct users, and you find that out only after pushing it. So I asked our agent, which has Amazon Agent Atlas behind it. Here is what came back.

What a model without Atlas gets wrong

I ran the same prompt through a frontier model with no retrieval. The response looked workable. It wasn't.

Four failure modes in a single un-grounded response

It pulled from conversions_all. The Audiences editor only accepts the _for_audiences variants for SELECT user_id queries. The right table for this workflow is conversions_all_for_audiences, and pasting the un-suffixed name produces a "user_id not selectable" rejection in the AMC Audiences UI.
It built the 180-day lookback by hardcoding event_dt_utc >= CURRENT_DATE - INTERVAL '180 day'. The Atlas playbook uses TABLE(EXTEND_TIME_WINDOW('conversions_all_for_audiences', 'P180D', 'P0D')), which is the only construct that reaches outside the AMC Audiences query editor's default analysis window. Without it, your "180-day lookback" is silently truncated.
It dropped the exposure_type = 'non-ad-exposed' filter. The lapsed-loyalist audience is the one Atlas explicitly recommends building from organic repeat buyers, customers who came back on their own. Without the filter, the audience scoops up everyone you already retargeted, which is exactly the population you don't need to spend on.
It didn't mention the 2,000-user activation floor. AMC Audiences refuses to push an audience smaller than 2,000 distinct users to Amazon DSP. The query returns no error in that case; the audience appears to compile, then quietly fails to land in DSP. You discover the floor by missing a campaign launch.

Every one of these would have produced a query that runs without complaint and an audience that never activates. The combination would have eaten a week of debugging.

What Atlas retrieves

When the agent gets the question, it does a semantic search across the amazon_ads collection and pulls a handful of chunks before writing any SQL:

The Flexible Shopping Insights Trial Guide, section 4.2 "Engage lapsed customers": the canonical AMC template for exactly this workflow, complete with the EXTEND_TIME_WINDOW lookback, the conv_cnt > 2 filter on repeat purchases, and the BUILT_IN_PARAMETER('TIME_WINDOW_START') exclusion that defines "haven't bought recently."
The AMC Audiences table-variant rule, indexed from "Creating an Audience for Wishlist or Registry Additions": why conversions_all_for_audiences is the only table that permits SELECT user_id, and the suffix pattern that distinguishes Audiences-editor tables from main-editor tables.
The Engage non-ad-exposed audience section of the same FSI Trial Guide: the sister query in section 4.1 that establishes the count(user_id) sizing trick, run in the main editor against the un-suffixed table, before any audience is pushed.
The Introduction to AMC Lookalike Audiences playbook: the downstream activation path if the seed turns out to be too small to use directly, with the 500-to-500,000 lookalike seed constraint and the model-expansion behavior.

Atlas doesn't generate the SQL. It surfaces the playbook with its constraints intact, and the agent adapts the template to the operator's hero ASINs and window.

The agent's output

Here is the audience query the agent produced. It pastes directly into the AMC Audiences query editor, uses the 180-day extended window, and filters to customers with three or more organic purchases who have gone silent inside the current analysis window:

-- Audience Instructional Query: Re-engage lapsed three-time buyers
-- Source: AMC FSI Trial Guide, section 4.2 "Engage lapsed customers"
-- Run in: AMC Audiences query editor (not the main editor)
-- Table:  conversions_all_for_audiences (_for_audiences variant required)

WITH purchase AS (
  -- Count distinct organic conversions per user over the trailing 180 days,
  -- and capture each user's most recent purchase date.
  SELECT
    user_id,
    COUNT(DISTINCT conversion_id) AS conv_cnt,
    MAX(event_date_utc)           AS event_max
  FROM TABLE(EXTEND_TIME_WINDOW('conversions_all_for_audiences', 'P180D', 'P0D'))
  WHERE event_subtype = 'order'
    AND exposure_type = 'non-ad-exposed'
    AND user_id IS NOT NULL
  GROUP BY user_id
),
multiple_purchase AS (
  -- Keep only the customers with three or more organic orders in the lookback.
  SELECT user_id, event_max
  FROM purchase
  WHERE conv_cnt > 2
)
-- Final seed: three-plus buyers whose most recent order predates the analysis
-- window. With a 90-day window, that means no purchase in the last 90 days.
SELECT user_id
FROM multiple_purchase
WHERE user_id NOT IN (
  SELECT user_id
  FROM multiple_purchase
  WHERE event_max > BUILT_IN_PARAMETER('TIME_WINDOW_START')
)

Three things to notice about what the agent chose to do. First, the lookback uses EXTEND_TIME_WINDOW('conversions_all_for_audiences', 'P180D', 'P0D'), not a hand-rolled date filter. Inside the AMC Audiences editor, the default analysis window is shorter than the 180 days this audience needs, and EXTEND_TIME_WINDOW is the only mechanism that opens it. The P180D is an ISO-8601 duration; P0D means the window ends at the current analysis-window boundary. The agent inherited this directly from the FSI playbook.

The exposure_type = 'non-ad-exposed' filter is the entire point of the audience. The retention lead wanted organic loyalists, the customers who came back without seeing ads, because those are the ones whose silence is a churn signal rather than ad fatigue. Without the filter, the seed is contaminated with customers you've already retargeted, and the DSP campaign you build from it overlaps with campaigns you're already running.

Finally, the lapsed condition is expressed as a NOT IN against the same multiple_purchase CTE, gated on BUILT_IN_PARAMETER('TIME_WINDOW_START'). That parameter resolves to the start of the analysis window the operator sets in the editor, so a 90-day analysis window automatically defines "lapsed" as "no order in the last 90 days." Change the window in the editor, and the lapsed definition shifts with it. No code edits required.

The footnotes the agent surfaced unprompted

This is the part that separates a retrieval-grounded response from a fluent guess. Without being asked, the agent attached a short list of things the retention lead needed to know but didn't think to ask about:

What Atlas surfaced that the operator didn't ask for

Size the audience before you push it. AMC Audiences refuses to activate any audience under 2,000 distinct users. Run the query in the main editor first with user_id swapped for count(user_id) and the _for_audiences suffix removed from the table name; that returns the seed size without creating anything.
Loosen the conditions when the floor isn't met. The FSI playbook calls out the relaxation order explicitly: change conv_cnt > 2 to conv_cnt > 1 first (two-plus buyers instead of three-plus), then extend the lookback from 180 to 270 days. Both are documented adjustments, not hacks.
Don't end the query on a comment line. AMC's audience editor rejects any submission whose last non-blank line is a -- comment. Strip trailing annotations before pasting, or the editor will swallow the query without a useful error.
event_subtype = 'order' is required. conversions_all_for_audiences carries every conversion subtype Amazon tracks, not just purchases. Without the 'order' filter, detail-page views, wishlist adds, and Subscribe & Save subscription events count toward the conv_cnt and inflate the seed with users who never actually bought.
Flexible Shopping Insights is a paid feature. The exposure_type column and the non-ad-exposed signal only populate when FSI is enabled on the AMC instance. Without it, the filter returns zero rows and the audience appears empty for reasons the editor will not surface.

Any one of these would have cost the operator a half-day to discover. The compounding effect is why this kind of audience normally takes a week to ship and not an afternoon.

What happens next

Once the seed sizes above 2,000 users, the agent flips into activation mode and routes the audience through the standard AMC Audiences-to-DSP path: paste the query into the Audiences editor, push it to a named audience, wait for the activation window to close, and verify the audience appears as targetable in Amazon DSP. If the seed comes back undersized even after both relaxations, the agent recommends pivoting to AMC Lookalike Audiences, using the lapsed loyalists as a seed (even a small one) and letting the lookalike model expand it. That path uses the same workflow we walked through for cart abandoners, but with the loyalist seed in place of the cart-abandoner seed and a 500-to-500,000 lookalike size band instead of the 2,000-user activation floor. Either way, the agent doesn't stop at SQL: it carries the audience to the activation handoff and tells you which path it took and why.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings AMC and DSP signals, the Selling Partner MCP can add catalog context, Atlas grounds the lapsed-loyalist rules, and Skills keep the reengagement audience on a reviewed refresh cadence.

Why this matters

The lapsed-loyalist workflow is the kind of audience build that is easy to ask for, hard to ship, and impossible to debug after the fact. The query has to use the right table variant, the right time-window construct, the right exposure filter, and the right size floor; miss any one of them and the audience either fails to compile, fails to activate, or activates against the wrong population. None of this is exotic knowledge, but it lives in four different sections of two different playbooks, and a model without retrieval has to guess at all of it.

If your retention agents are guessing at AMC Audiences, they don't have to be.

Part of an ongoing series on how agents grounded in Amazon Agent Atlas approach real AMC workflows. Next: turning a too-small loyalist seed into an activated audience through AMC Lookalike Audiences, and the rules the lookalike model uses to expand a seed without diluting it.

Build Prime Day AMC Lookalikes

2026-05-11T00:00:00Z

The Slack message landed six weeks before Prime Day: "Can we build a lookalike audience of customers similar to our best buyers, sized correctly so it actually activates?"

This sounds like one SQL query. It is really four decisions: which customers count as "best," which Amazon Marketing Cloud table variant allows SELECT user_id, which Amazon Standard Identification Number (ASIN) filters belong in the seed, how large the seed can be before the lookalike model refuses it, and how to size the seed before spending two days waiting on a refresh. Get one of those wrong and the audience either fails silently or trains on the wrong population.

So I asked our agent. The agent has Amazon Agent Atlas behind it: a corpus of AMC playbooks, instructional queries, and audience patterns indexed for semantic retrieval. Here's what came back.

What a model without Atlas gets wrong in AMC lookalike seed generation

I ran the same prompt through a frontier model with no retrieval. The output was confident, would have compiled in the wrong query editor, and was wrong about every threshold that decides whether the audience activates.

Five failure modes in the un-grounded response

It picked one seed definition, "top 20% of spenders," and committed to it. The actual playbook recommends three distinct seed strategies tested separately first: Subscribe & Save (SnS) subscribers, multi-ASIN purchasers, and a total-spend threshold.
It quoted a seed size minimum of "a few thousand users" and no upper bound. The real guardrail is specific: the seed should contain between 500 and 500,000 distinct user_id values.
It wrote the seed query against conversions and used SELECT DISTINCT user_id in the outer query. AMC Audiences requires the _for_audiences table family, specifically conversions_for_audiences, for this seed shape.
It did not size the seed before submission. The playbook has a companion measurement query that runs in the main editor against conversions_all and returns the seed count before the audience refresh starts.
It ended the query on a -- comment line. AMC Audiences can reject submissions whose last line is a comment, so the template intentionally ends on executable SQL.

None of these failures look wrong on a casual read. They are the kind of mistakes you catch after submitting an audience, waiting for refresh, and watching the status sit there.

What Atlas retrieves for an AMC Prime Day lookalike audience

When the agent gets the question, it does a semantic search across the amazon_ads collection and pulls five chunks before writing a line of SQL:

The AMC Lookalike Audiences for Promotional Events playbook, version-tagged 2023-10-01: the canonical Prime Day and Black Friday workflow covering ASIN selection, seed creation, flight-time analysis, and activation.
The Introduction to AMC Lookalike Audiences instructional query (IQ): the mechanics behind seed scoring, the five expansion types, and the three-seed template for high-value customers.
The Companion measurement query chunk from the lookalike audiences IQ: the SELECT COUNT(user_id) FROM (...) pattern that runs in the main AMC editor.
The Creating Audiences Based on High Value Customer Segments playbook: the percentile-rank variant for "top X% by spend" seeds.
The Flexible Shopping Insights Trial Guide Section 5: SnS-specific seed patterns, including firstSnSOrder and repeatSnSOrder event subtype notes for advertisers with Flexible Shopping Insights (FSI).

The agent does not invent the SQL. It surfaces the right template with the right caveats, then adapts it.

Seed strategies and expansion types for AMC lookalike audiences

The playbook gives the operator two taxonomies to make explicit before submission.

Taxonomy	Option	When to use it
Seed strategy	SnS subscribers	Use when repeat subscription behavior is the clearest signal of loyalty.
Seed strategy	Multi-ASIN purchasers	Use when cross-catalog buying is more important than a single-product purchase.
Seed strategy	Total spend threshold	Use when revenue concentration matters more than purchase frequency.
Expansion type	Most Similar	Start here when performance matters more than reach.
Expansion type	Similar	Use when the seed is strong but the campaign needs more scale.
Expansion type	Balanced	Practical default for Prime Day prospecting when you need both reach and relevance.
Expansion type	Broad	Use when the seed is valid but projected audience size is too constrained.
Expansion type	Most Broad	Use for reach-first testing, not for the first high-efficiency launch.

This block matters because it prevents the model from collapsing three separate operator decisions into one vague "high-value lookalike" audience.

The agent produced two artifacts. First, the seed query, lifted from the three-seed template in the Introduction to AMC Lookalike Audiences instructional query with the optional clauses set for the SnS strategy:

/* Audience instructional query: Introduction to lookalike audiences (High Value Customers)
   Run in the AMC Audiences query editor, not the main editor.
   Last verified: 2026-05-13.

   Three seed strategies are supported below. Test them separately first:
   [1 of 4]: ASIN filter
   [2 of 4]: SnS subscribers
   [3 of 4]: Multi-ASIN purchasers
   [4 of 4]: Total purchase value threshold

   Keep the final GROUP BY 1 as executable SQL so the query does not end
   on a comment line.
*/

WITH user_sales_cte AS (
  SELECT
    user_id,
    CASE
      WHEN event_subtype = 'snsSubscription' THEN 1
      ELSE 0
    END AS sns_flag,
    SUM(total_units_sold) AS total_purchases,
    SUM(total_product_sales) AS total_product_sales,
    COUNT(DISTINCT tracked_item) AS unique_items_purchased
  FROM conversions_for_audiences
  WHERE event_subtype IN ('snsSubscription', 'order')
    /* AND tracked_asin IN ('B0HERO0001','B0HERO0002') */
    AND user_id IS NOT NULL
  GROUP BY 1, 2
),
user_aggregate AS (
  SELECT
    user_id,
    CASE WHEN unique_items_purchased > 1 THEN 1 ELSE 0 END AS multi_purchase_flag,
    MAX(sns_flag) AS sns_flag,
    SUM(total_purchases) AS total_purchases,
    SUM(total_product_sales) AS total_product_sales,
    SUM(unique_items_purchased) AS unique_items_purchased
  FROM user_sales_cte
  GROUP BY 1, 2
),
audience_grouping AS (
  SELECT
    user_id,
    sns_flag,
    MAX(multi_purchase_flag) AS multi_purchase_flag,
    SUM(total_purchases) AS total_purchases,
    SUM(total_product_sales) AS total_product_sales,
    SUM(unique_items_purchased) AS unique_items_purchased
  FROM user_aggregate
  GROUP BY 1, 2
)
SELECT user_id
FROM audience_grouping
WHERE sns_flag = 1
  -- AND multi_purchase_flag = 1
  -- AND total_product_sales >= 250
GROUP BY 1;

The event_subtype IN ('snsSubscription', 'order') filter keeps the inner CTE focused on purchase behavior. That prevents cart additions, wishlist saves, or other engagement events from diluting the seed. Filtering there is cheaper and cleaner than trying to fix the population at the final WHERE.

The audience_grouping CTE looks redundant, and the agent kept it anyway. The playbook leaves that pass in place because the model trainer expects a clean row-grain. Stripping it can still work, but the failure mode is opaque enough that the safer version is worth the extra CTE.

The optional clauses stay visible because the operator should run SnS, multi-ASIN, and spend-threshold seeds separately before combining anything. Pre-baking that comparison into the template matches the way operators actually test seeds.

How to size an AMC seed audience before submission

Before submitting any seed to AMC Audiences, the agent produced the sizing companion. This is the part the un-grounded model skipped.

/* Companion measurement query.
   Run in the main AMC query editor, not the Audiences editor.
   Last verified: 2026-05-13.

   Change conversions_for_audiences to conversions_all for sizing.
   Keep SELECT user_id inside the subquery; COUNT() wraps it outside.
*/

SELECT COUNT(user_id) AS user_count
FROM (
  WITH user_sales_cte AS (
    SELECT
      user_id,
      CASE WHEN event_subtype = 'snsSubscription' THEN 1 ELSE 0 END AS sns_flag,
      SUM(total_units_sold) AS total_purchases,
      SUM(total_product_sales) AS total_product_sales,
      COUNT(DISTINCT tracked_item) AS unique_items_purchased
    FROM conversions_all
    WHERE event_subtype IN ('snsSubscription', 'order')
      AND user_id IS NOT NULL
    GROUP BY 1, 2
  ),
  user_aggregate AS (
    SELECT
      user_id,
      MAX(sns_flag) AS sns_flag
    FROM user_sales_cte
    GROUP BY 1
  )
  SELECT user_id
  FROM user_aggregate
  WHERE sns_flag = 1
)
GROUP BY 1;

The query returns one number: the distinct user_id count of the seed. If it is under 500, the audience refresh can fail. If it is over 500,000, the refresh can also fail. The practical habit is to stay comfortably inside the band so a seasonal data swing does not push the audience across either edge.

The diagnostic table above is the operator checkpoint. The fourth row, Total spend >= $500 returning 470 users, is the negative result that saves the most time. Without the sizing companion, the operator would discover that failure only after submitting the audience.

The footnotes the agent surfaces for AMC Audiences

This is the part that separates an Atlas-grounded agent from a fluent one. The agent did not wait to be asked. It surfaced the caveats the operator was about to need:

Things Atlas surfaced that the operator did not ask for

Seed size has hard boundaries. The seed should contain 500 to 500,000 user_id values. Always run the sizing query first.
Test the three seed strategies separately. Combining SnS, multi-ASIN, and spend thresholds too early can create a seed that is technically valid but strategically empty.
Expansion type is a decision, not a default. Balanced is a practical starting point, but Most Similar, Similar, Broad, and Most Broad change the reach-performance tradeoff.
Lookalikes address the non-ad-exposed gap. Rule-based audiences are useful for remarketing; Prime Day prospecting usually needs users who share seed traits but were not already in the ad-exposed pool.
The query should not end on a comment line. Keep an executable final line such as GROUP BY 1.
The promotional-event variant uses a fixed window. For Prime Day, the API payload should use the prior promotional window rather than a rolling relative window.

Any one of these can eat an afternoon after submission. Getting all six before the first API call is the difference between a day-one launch and a day-three debugging thread.

What happens next: submit the AMC Audiences API payload

The seed query, sizing query, and diagnostic table close the loop on creation but not activation. The next move is to flatten the chosen seed SQL into an AMC Audiences API payload, submit it with audienceName, advertiserId, timeWindowStart, timeWindowEnd, refreshRateDays, timeWindowRelative, and lookalikeAudienceExpectedReach, then wait for the audience to become available for Amazon demand-side platform (DSP) activation.

For Prime Day, timeWindowRelative should be false because the seed is tied to a fixed promotional window. refreshRateDays: 7 keeps the audience fresh without turning the seed into a rolling interpretation of last year's event. lookalikeAudienceExpectedReach: "BALANCED" is a defensible first pass because it gives the team enough scale to test without starting at the loosest expansion setting.

The evaluation pass comes after activation. Compare the lookalike audience against last year's rule-based audience baseline, then decide whether to keep the SnS seed, rotate to multi-ASIN purchasers, or loosen the spend threshold.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings AMC and DSP signals, the Selling Partner MCP can add catalog and ASIN context, Atlas grounds the sizing and payload rules, and Skills keep the audience refresh reviewable.

Why this matters for Prime Day audience activation

A lookalike audience that fails silently is worse than no audience. The operator has staged creative and media against an audience assumption, and the refresh can still be pending when the event opens. The rules that decide success are knowable, but they are scattered across a playbook, an instructional query, an API reference, and paid-feature notes.

Atlas is not a model upgrade. It is the corpus made available at the moment of need. The agent did not have to remember the 500-to-500,000 band, the _for_audiences suffix rule, the fixed-window payload, or the comment-line restriction. It looked them up.

If your agents are guessing at AMC seed sizes, they do not have to be.

Next: use the lookalike evaluation workflow to test whether the shipped audience outperformed the rule-based audience from the previous Prime Day.

Build an AMC Cart-Abandoner Audience

2026-05-10T00:00:00Z

The Slack message came in on a Tuesday: "Can you build me a demand-side platform (DSP) audience of people who added one of our hero Amazon Standard Identification Numbers (ASINs) to cart in the last 30 days but never bought? I want to retarget them before the next promotion."

This is the kind of ask that should take ten minutes. In practice, it eats an afternoon - not because the SQL is hard, but because Amazon Marketing Cloud has a dozen quiet rules that aren't in any one place. The query has to hit the right table. The user-level fields have to come from the variant table that AMC Audiences will actually accept. The seed has to land between 500 and 500,000 users or the audience refresh fails silently. Attribution windows have to close before the numbers stop lying to you.

So I asked our agent instead. The agent has Amazon Agent Atlas behind it - a curated corpus of AMC playbooks, instructional queries, audience patterns, and decision rules indexed for semantic retrieval. Here's what came back.

What a model without Atlas gets wrong

I tested this same prompt against a frontier model with no retrieval. The response looked confident. It wasn't.

None of this is exotic knowledge. It's all in Amazon's public docs. But it's scattered across a dozen pages, half of which surface in search rankings only when you already know what to type.

What Atlas retrieves

When the agent gets the question, it does a semantic search across the amazon_ads collection and pulls four chunks before it writes a single line of SQL:

The Audience that added to cart but did not purchase instructional query - the canonical AMC template for this exact use case
The AMC Audiences table-variant rule - why conversions_for_audiences is the only table that allows SELECT user_id, and the corresponding _for_audiences suffix pattern across other AMC datasets
The AMC Audiences activation guide - the 500 to 500,000 seed-size constraint and the ~48-hour DSP activation window
The Introduction to AMC Audiences companion measurement query - the trick of changing user_id to COUNT(user_id) and dropping the _for_audiences suffix to size your audience before you try to create it

Atlas doesn't generate the SQL. It surfaces the playbook, and the agent adapts it.

The agent's output

Here's the query the agent produced. It compiled on the first try and resolved to a seed of just over 12,000 users - comfortably inside the activation window:

/* AMC Audiences IQ: Added to cart but did not purchase
   Adapted for hero-ASIN retargeting, 30-day window.
   Run in the AMC Audiences query editor (not the main editor) - _for_audiences
   table variants are required for SELECT user_id. */

WITH asins (asin) AS (
  VALUES
    ('B0XXXXXXX1'),   -- hero ASIN #1
    ('B0XXXXXXX2'),   -- hero ASIN #2
    ('B0XXXXXXX3')    -- hero ASIN #3
),
purchase AS (
  SELECT
    user_id,
    MAX(event_dt_utc) AS purchase_dt_max
  FROM conversions_for_audiences
  WHERE event_subtype = 'order'
    AND tracked_item IN (SELECT asin FROM asins)
  GROUP BY 1
),
atc AS (
  SELECT
    user_id,
    MAX(event_dt_utc) AS atc_dt_max
  FROM conversions_for_audiences
  WHERE event_subtype = 'shoppingCart'
    AND tracked_item IN (SELECT asin FROM asins)
  GROUP BY 1
)
SELECT atc.user_id
FROM atc
LEFT JOIN purchase
  ON atc.user_id = purchase.user_id
WHERE atc_dt_max > purchase_dt_max
   OR purchase_dt_max IS NULL;

Three things to notice about what the agent chose to do:

The ASIN filter is in the CTEs, not the final SELECT. Filtering at the CTE level is the difference between a query that scans a focused slice of the conversions table and one that scans everything and discards 99% of it. AMC's compute budget isn't infinite, and the Atlas playbook flagged this explicitly.
The OR purchase_dt_max IS NULL clause matters. Without it, the audience would only include people who previously bought and then abandoned again, missing every first-time prospect who added to cart and walked. The agent inherited this from the AMC IQ template, which spells out the join semantics.
The outer query is a plain SELECT user_id, not SELECT DISTINCT. AMC Audiences expects user IDs and de-duplicates internally. Adding DISTINCT doesn't help performance and occasionally trips the audience compiler.

The companion sizing query - run this first

Before the agent suggested pushing the audience to DSP, it produced a sizing check. This is the part most ad-hoc workflows skip, and it's why most "build me an audience" requests fail their first activation:

/* Audience sizing check - run this in the MAIN AMC query editor (not Audiences).
   Note the table name change: conversions_all, not conversions_for_audiences. */

SELECT COUNT(DISTINCT atc.user_id) AS audience_size
FROM (
  SELECT user_id, MAX(event_dt_utc) AS atc_dt_max
  FROM conversions_all
  WHERE event_subtype = 'shoppingCart'
    AND tracked_item IN ('B0XXXXXXX1','B0XXXXXXX2','B0XXXXXXX3')
  GROUP BY 1
) atc
LEFT JOIN (
  SELECT user_id, MAX(event_dt_utc) AS purchase_dt_max
  FROM conversions_all
  WHERE event_subtype = 'order'
    AND tracked_item IN ('B0XXXXXXX1','B0XXXXXXX2','B0XXXXXXX3')
  GROUP BY 1
) purchase
  ON atc.user_id = purchase.user_id
WHERE atc.atc_dt_max > purchase.purchase_dt_max
   OR purchase.purchase_dt_max IS NULL;

If this returns less than 500, the audience won't activate. If it returns more than 500,000, the audience won't refresh. The agent knows both thresholds and tells you to widen or tighten the ASIN list accordingly.

The footnotes the agent surfaced unprompted

This is the part that separates a retrieval-grounded agent from a fluent one. Without being asked, the agent included a short list of things the operator needed to know but didn't think to ask about:

Things Atlas surfaced that the operator didn't ask for

Seed size: 500 to 500,000. Outside that range, the audience either refuses to activate or refuses to refresh. Always run the sizing query first.
DSP activation lag: ~48 hours. Build the audience two days before the campaign launch, not the day of.
Sandbox limitations. AMC Sandbox doesn't populate certain event types reliably - including some Subscribe & Save signals. For audience work, run against production.
Comment-line restriction. AMC Audiences queries cannot end on a comment line. Strip trailing -- annotations before pushing to audience creation, or the editor will reject the query.
Upstream variants. Swap event_subtype = 'shoppingCart' for 'detailPageView' to reach further up the funnel, or for 'wishlist' to capture lower-intent interest. The agent will adjust the seed-size expectations accordingly.

Any one of these would have cost the operator an hour to discover. The compounding effect is why the workflow took ten minutes instead of an afternoon.

What happens next

The agent doesn't stop at SQL. Once the audience compiles and the sizing check passes, Atlas's activation playbook covers the next two hops: pushing the audience definition to AMC Audiences from the Audiences query editor, waiting for the activation window to close, and verifying the audience appears as targetable in Amazon DSP. The agent also flags that the audience is static at creation time - it doesn't auto-refresh as new users add to cart. For a retargeting program you'd want to run continuously, the agent recommends scheduling the audience as a recurring AMC workflow with a 7-day refresh cadence, and points to the corresponding Atlas playbook chunk on workflow scheduling.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings AMC and DSP context, the Selling Partner MCP can add catalog and ASIN context, Atlas grounds the audience rules, and Skills keep the refresh cadence reviewable.

That's the loop closed: ask, retrieve, build, size, activate, monitor.

Why this matters

A foundation model can write SQL. So can a junior analyst with a textbook. What neither can reliably do is produce a query that compiles against the specific table variants AMC exposes, respects the seed-size constraints DSP enforces, and bakes in the timing assumptions Amazon's attribution model requires - all without being told to.

Atlas isn't a magic upgrade to model capability. It's a corpus of Amazon's own playbook content, indexed and addressable by an agent at the moment of need. The agent doesn't have to remember any of this. It has to know where to look. That's a lower bar - and a much more reliable one.

If your agents are guessing at AMC, they don't have to be.

This is the first in a series on how agents grounded in Amazon Agent Atlas approach real Amazon Marketing Cloud workflows. Next: building a Subscribe & Save lift analysis that quantifies the spend gap between subscribers and one-off buyers, including the February 2024 repeatSnSOrder signal that most ungrounded models still don't know exists.

Measure Subscribe & Save Lift in AMC

2026-05-10T00:00:00Z

The question came up in a quarterly review: "Is Subscribe & Save actually doing anything for us, or are we just discounting the same customers who would have bought anyway?"

It's the kind of question that sounds answerable in five minutes and isn't. Amazon's Subscribe & Save program - auto-replenishment with a small discount - generates a stream of conversion events that look like ordinary purchases in most reports. The standard Sponsored Ads reporting doesn't separate them. Brand Analytics doesn't separate them. The Business Reports in Seller Central treat an SnS unit the same as a one-off unit. To actually measure SnS lift - the spend gap between subscribers and one-off buyers - you have to query Amazon Marketing Cloud, against the right tables, with the right event subtypes, over the right window.

So I asked our agent. The agent has Amazon Agent Atlas behind it, and Atlas has the AMC Flexible Shopping Insights playbook indexed in full. Here's what came back.

What a model without Atlas gets wrong

I ran the same prompt through a frontier model with no retrieval. The output was confident and wrong in a way that would have looked right until the numbers didn't make sense.

Four things the un-grounded model missed

It didn't know repeatSnSOrder exists. Amazon added this event_subtype to Flexible Shopping Insights on February 5, 2024. Without it, you only count the initial subscription event and the first SnS purchase - missing every recurring shipment, which is where the actual lift lives. Most models' training data predates this change, so they confidently produce queries that undercount SnS revenue by 60–80%.
It used conversions instead of conversions_all. AMC has multiple conversion tables and they don't carry the same fields. conversions_all is the table Flexible Shopping Insights writes the SnS signals to.
It didn't mention that Flexible Shopping Insights is a paid AMC feature with regional availability. Running the query without an active FSI subscription returns empty results with no error - the table exists but contains no SnS rows for your account.
It quoted a 30-day analysis window. The playbook recommends a minimum of 3 months to capture SnS cadence, because subscription cycles run on 1, 2, 3, or 6-month schedules and a 30-day query misses the majority of repeat orders entirely.

Any one of these would silently corrupt the lift number. The combination would tank a quarterly business case.

What Atlas retrieves

When the agent gets the question, it does a semantic search across the amazon_ads collection and pulls four chunks before writing any SQL:

The Subscribe and Save repeat purchases instructional query - the canonical AMC template, version-tagged 2024-02-05
The Flexible Shopping Insights trial guide - the surrounding context on which AMC tables FSI writes to and which event subtypes are exposed
The FSI access requirements note - that FSI is a paid feature with regional restrictions, and Sandbox doesn't populate the repeat-SnS signals reliably
The AMC query window guidance - the 3-month minimum recommendation, the ASIN filter performance tip, and the join-grain rules for analyses that span event-level and weekly aggregations

Atlas doesn't write the SQL. It surfaces the right playbook with the right caveats, and the agent adapts.

The agent's output

Here's the lift comparison query the agent produced. It runs against the main AMC query editor (not the Audiences editor - we're measuring, not building an audience), uses the three event subtypes that together capture the full SnS lifecycle, and treats every other purchaser as the comparison group:

-- Subscribe & Save lift: average spend by user type
-- Source: AMC IQ "Subscribe and save repeat purchases" (v 2024-02-05)
-- Run window: last full 90 days (set Date range in Query Editor)
-- Table: conversions_all (main editor, not _for_audiences)

SELECT
  CASE
    WHEN event_subtype IN (
      'snsSubscription',   -- initial subscription event
      'firstSnSOrder',     -- first scheduled order after subscribing
      'repeatSnSOrder'     -- recurring orders (added 2024-02-05)
    ) THEN 'subscriber'
    ELSE 'non-subscriber'
  END AS user_type,
  COUNT(DISTINCT user_id)                              AS users_that_purchased,
  SUM(total_product_sales)                             AS total_sales,
  SUM(total_product_sales) / COUNT(DISTINCT user_id)   AS average_spend_per_user
FROM conversions_all
WHERE tracked_item IN (
  'B0XXXXXXX1', 'B0XXXXXXX2', 'B0XXXXXXX3'   -- restrict to ASINs in SnS program for perf
)
GROUP BY 1
ORDER BY 1;

Three things to notice about what the agent chose to do:

The three event subtypes are an IN list, not a chain of ORs. The IQ template uses this exact pattern because it's the most readable way to express "any of these three states means the user is in the subscriber bucket." If you swap in event_subtype = 'snsSubscription' OR event_subtype = 'firstSnSOrder', you'll get the same result and a query that's harder to maintain, and a future you will forget which subtypes you included.
The ASIN filter goes in the WHERE clause of the main query, not in a CTE. SnS lift analyses are usually run against the subset of your catalog that's actually enrolled in the SnS program; there's no reason to scan the rest of conversions_all and discard 90% of it. The Atlas playbook explicitly flags this as a performance pattern.
The comparison bucket is "every other purchaser," not "purchasers who explicitly opted out of SnS." Amazon doesn't expose an opt-out signal; the inverse of an SnS subscriber is just any user whose purchase event doesn't carry one of the three SnS event subtypes. The agent inherited this from the IQ template and didn't try to over-engineer it.

The companion ASIN-level query

The lift number is the headline, but the question that follows it is always "which Amazon Standard Identification Numbers (ASINs) are pulling their weight in SnS?" - and the playbook has a companion query for exactly that:

-- SnS purchases by ASIN: volume + percentage of total purchases
-- Run alongside the lift query, same window, same ASIN scope

WITH sns AS (
  SELECT tracked_item AS asin,
         COUNT(*) AS sns_purchases
  FROM conversions_all
  WHERE event_subtype IN ('firstSnSOrder', 'repeatSnSOrder')
    AND tracked_item IN ('B0XXXXXXX1','B0XXXXXXX2','B0XXXXXXX3')
  GROUP BY 1
),
total AS (
  SELECT tracked_item AS asin,
         COUNT(*) AS total_purchases
  FROM conversions_all
  WHERE event_subtype = 'order'
    AND tracked_item IN ('B0XXXXXXX1','B0XXXXXXX2','B0XXXXXXX3')
  GROUP BY 1
)
SELECT
  total.asin,
  sns.sns_purchases,
  total.total_purchases,
  ROUND(100.0 * sns.sns_purchases / NULLIF(total.total_purchases, 0), 2) AS sns_share_pct
FROM total
LEFT JOIN sns ON sns.asin = total.asin
ORDER BY sns_share_pct DESC NULLS LAST;

The NULLIF is the agent being defensive - a recently launched ASIN with zero recorded order events would otherwise divide by zero. Small thing. Saves a re-run.

How to read the numbers

The lift query returns two rows. Subscriber average_spend_per_user divided by non-subscriber average_spend_per_user is the headline lift ratio. A ratio of 2.4x means subscribers spend 2.4 times more than one-off buyers on the same ASIN set over the same window. The ASIN-level query then shows where that lift is concentrated - typically a handful of consumables (coffee, supplements, pet food, household goods) drive the majority of subscriber revenue, and the long tail of one-time products contributes almost nothing to the SnS program.

The decision the marketing director was actually trying to make - do we push more aggressively into SnS? - turns on whether the high-lift ASINs already have full SnS enrollment, or whether there's headroom. If your top-5 lift ASINs are already at 60%+ sns_share_pct, the upside is in expanding the catalog. If they're at 15%, the upside is in conversion campaigns targeting existing buyers of those ASINs.

The footnotes the agent surfaced unprompted

This is the part that separates retrieval-grounded responses from fluent guesses. Without being asked, the agent included a short list of things the operator needed to know but didn't think to ask about:

What Atlas surfaced that the operator didn't ask for

Flexible Shopping Insights subscription required. If FSI isn't enabled on your AMC instance, the query will return empty results with no error message. Check the Paid Features tab in AMC, or talk to your AdTech account executive. Regional availability varies.
Sandbox doesn't carry repeat-SnS signals. sns_subscription_id and repeatSnSOrder rows are not populated in AMC Sandbox. Run this against production, or you'll see a lift ratio of 1.0x and assume SnS is doing nothing.
Three-month minimum window. SnS cycles run on 1, 2, 3, or 6-month schedules. Anything shorter than 90 days will under-represent recurring orders. Six months is better if you have the data depth.
Household-level inflation. AMC translates household purchases to user-level purchases by crediting the household event to each linked user. For total-sales analyses (like this one), be aware that subscriber totals may be slightly inflated when a single subscription serves a multi-person household. Adjust at the user level if precision matters.
Don't end the query on a comment line. AMC's query editor will reject any submission whose last line is a -- comment. Strip trailing annotations before running.

The household-inflation footnote is the kind of thing that takes most operators a year of using AMC to discover. Atlas had it indexed from the start.

What happens next

The lift number is the input to a series of decisions, not the output of the analysis. The agent's next step - and the next guide in this series - is to take the high-lift ASINs identified here and build an AMC audience of non-subscribed buyers of those ASINs, then activate it as a Subscribe & Save promotion campaign in Amazon demand-side platform (DSP). That workflow uses the same conversions_all_for_audiences table variant pattern we covered in the cart-abandoner audience guide, with a different filter and a different activation playbook.

The point is that no single query closes the loop. The agent runs the lift analysis, surfaces the high-lift ASINs, builds the audience, and pushes it to DSP - each step grounded in a different playbook, each playbook indexed and retrievable at the moment of need.

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings the AMC and DSP signals, the Selling Partner MCP can add catalog and inventory context, Atlas grounds the signal list, and Skills keep the analysis and follow-up audience refresh on schedule.

Why this matters

The Subscribe & Save lift question is a perfect case for retrieval-grounded agents because the answer literally did not exist in most models' training data. Amazon added the repeatSnSOrder signal in February 2024. Models with knowledge cutoffs before that - which is most of them, even now, for the depth of detail required - will produce queries that compile, run, return data, and quietly undercount SnS revenue by the majority of its actual contribution. The operator gets a number. The number is wrong. There's no error to debug.

An agent grounded in Atlas doesn't have this problem. It doesn't know SnS analysis from training data - it reads Amazon's own current IQ template and adapts it. When Amazon updates the playbook again (and they will), the corpus updates, and the agent gets the new answer without anyone retraining a model.

If your agents are giving you confident SnS numbers that don't include repeatSnSOrder, they're giving you the wrong numbers.

Part of an ongoing series on how agents grounded in Amazon Agent Atlas approach real AMC workflows. Next: turning a high-lift ASIN list into a DSP-activated audience of non-subscribed buyers - the activation half of the workflow this post leaves open.

Turn AMC Workflows into Agent Skills

2026-05-09T00:00:00Z

The operator question was practical: "We keep asking for the same AMC analyses. Can the agent remember the workflow instead of improvising every time?"

Yes, but the reusable unit should be a Skill, not a prompt snippet. A prompt remembers wording. A Skill remembers the steps: retrieve the right Amazon Marketing Cloud (AMC) playbook, choose the table, run the privacy or size check, produce the artifact, route the decision, and log what happened.

What a model without Atlas gets wrong

That is how a helpful demo becomes an unreviewable production process.

What Atlas retrieves

The agent starts by pulling the relevant Amazon Marketing Cloud playbooks from Amazon Agent Atlas. For an audience workflow, it retrieves:

The audience-source rule that decides whether the Skill can use an audience-safe table.
The sizing pattern that tells the operator whether the seed can activate.
The activation timing and companion measurement guidance that belong beside the output.
The AMC synthetic data playbook context when the Skill needs a safe test surface before it touches production workflows.

For a measurement workflow, it retrieves the attribution table, lookback rule, and caveats that belong in the output.

The Amazon Ads MCP gives the Skill live access to the Ads and AMC surfaces. Atlas tells it what the current playbook says before it acts.

The agent's working output

The useful output is a workflow contract:

{
  "skill": "amc_audience_workflow",
  "mode": "read_then_approve",
  "steps": [
    "retrieve_atlas_playbook",
    "resolve_table_window_filters",
    "run_privacy_and_seed_checks",
    "produce_sql_or_payload",
    "request_approval_for_writes",
    "write_run_log"
  ],
  "writeBoundary": "approval_required_before_dsp_activation"
}

That contract is deliberately more boring than an open-ended chat. Boring is what makes it repeatable.

The footnotes the agent surfaces

Those details are the difference between "the agent said so" and "we can audit the workflow."

What happens next

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP brings AMC and demand-side platform (DSP) campaign signals, the Selling Partner MCP can add catalog context, Atlas grounds the operating procedure, and Skills turn the workflow into a reviewed recurring automation.

Once the Skill exists, the same workflow can run from chat, code, or an automation tool. The interface changes; the source rules and approval gates do not.

The point

A Skill is how an agent stops improvising an operating procedure.

Next: use durable run logs to make every Skill execution reviewable after the fact.

Why MCP Needs Run Logs

2026-05-08T00:00:00Z

The operator question was not about a single Amazon workflow: "If an MCP-connected agent calls tools for us, how do we know what happened afterward?"

The answer is a run log. Model Context Protocol (MCP) gives agents a clean way to call tools. Production teams need the durable record around those calls: who asked, which tool ran, what parameters were passed, what policy checks fired, what changed, and who approved the change.

What a model without Atlas gets wrong

That makes the agent hard to trust even when the output is correct.

What Atlas retrieves

Atlas is one of the sources a run log must name. If an agent uses Amazon Agent Atlas to ground an Amazon Marketing Cloud (AMC) query, listing patch, or decision rule, the run log should capture:

The Atlas corpus version used for the answer.
The chunk identifiers that grounded the rule.
The tool inputs, outputs, and policy checks from the MCP server.

The same principle applies to live data called through an MCP server: capture the tool, inputs, outputs, and policy checks in the same run.

For Amazon workflows, the Amazon Ads MCP and Selling Partner MCP provide the live data surfaces. The run log is the connective record that explains why the agent used them.

The agent's working output

A production run log should answer five questions:

{
  "event": "mcp_tool_run",
  "riskTier": "write",
  "initiator": {"user": "required", "workspace": "required"},
  "execution": {"skillId": "required", "skillVersion": "required"},
  "toolCall": {"server": "required", "tool": "required", "parametersHash": "required"},
  "grounding": {"atlasCorpusVersion": "required", "chunkIds": ["required"]},
  "controls": {"checks": ["privacy", "permission", "approval"], "approvalState": "required"},
  "result": {"artifactHash": "required", "destination": "required", "rollbackContext": "required"}
}

If a field cannot be logged, the agent should treat that as a product gap before write access expands.

The footnotes the agent surfaces

Those details are mundane until something goes wrong. Then they are the product.

What happens next

The full workflow runs through the Amazon Agent Data layer: Amazon Ads MCP and Selling Partner MCP supply live Amazon context, Atlas grounds the answer, and Skills make the tool sequence repeatable. The run log records every step so a human can review the decision after the agent acts.

When a workflow graduates from analysis to activation, the run log becomes the audit surface for approval, debugging, and customer trust.

The point

If a tool call cannot be reconstructed, it should not be trusted in production.

Next: use the AMC Skill workflow pattern to decide which tool calls need approval before they write.

Human Approval for AMC Activation

2026-05-07T00:00:00Z

Run the read-only half of an AMC workflow hands-off, and stop in one place: audience activation waits inside a Skill until a human approves the exact creation payload. The Amazon Ads MCP runs the sizing reads automatically and holds the gated submission, while Amazon Agent Atlas supplies the rules the approver checks against: the 2000-user rule-based floor, the 500 to 500,000 lookalike seed band, the 24-to-36-hour DSP lag. The policy answers a Slack message from our media lead: "If the agent builds an Amazon Marketing Cloud audience and the SQL compiles, does it push it into the demand-side platform (DSP) on its own, or does one of us sign off first?" Our agent could do either. It stops.

Why not paste the audience SQL into ChatGPT or Claude for review? A plain chat hits three walls here. No access to your data: it cannot run a sizing query against your AMC instance. No way to take action: it cannot submit or watch anything on Amazon; you do every step by hand. Generic knowledge, not Amazon's: it does not carry the activation thresholds. That is disconnected, generic, manual work that ships silent mistakes. The MCP closes the first two walls, Atlas the third; the Skill makes the gate repeatable.

An AMC audience query returns nothing you can review, so the gate must come before the POST

One line of shared playbook boilerplate settles where the gate goes: "Unlike standard AMC 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." A rule-based audience query selects user_id values and nothing else; once submitted, there is no artifact left to inspect. Review after submission is not late, it is impossible.

Activation queries even run on their own table surface: the _for_audiences variants, conversions_for_audiences, conversions_all_for_audiences, dsp_impressions_for_audiences, sponsored_ads_traffic_for_audiences, amazon_attributed_events_by_traffic_time_for_audiences. That suffix in a FROM clause is a machine-checkable signal that a query is an activation, not an analysis. One nuance: conversions_all_for_audiences is the audience copy of conversions_all, and the high-value-segments query built on it lists a Flexible Amazon shopping insights subscription as a requirement, so the runnable seed below stays on conversions_for_audiences.

Cost lands on the same line. The Off-Amazon Conversions Playbook is explicit: "Submitting an audience to be created is not charged. There is no cost until the audience is activated in Amazon DSP." In the console the write is a paste into the Audiences query editor; through the Amazon Ads MCP it is the POST method of the AMC rule-based Audience API, which the Skill refuses to send unsigned.

Approval is a numbers check: 2000 distinct user_ids for a rule-based audience, a 500 to 500,000 seed for a lookalike

Two thresholds decide approvability, and they never blend. For rule-based audiences the Off-Amazon Conversions Playbook states that "the minimum is 2000 distinct user_ids for a rules-based audience to be activated in the market," a floor the Programmatic Audience Framework Playbook repeats. Lookalikes answer to a different band: Introduction to AMC Lookalike Audiences requires a seed of between 500 and 500,000 user_ids, warns that refresh "will fail if the size falls below 500 or goes above 500k," and recommends 1,000 to 450,000 as the working range. A correct approval card names the one threshold that applies and puts the measured number beside it.

Measurement runs automatically. Before submission, the agent wraps the seed in the corpus's companion pattern, SELECT COUNT(user_id) AS user_count FROM (seed query) GROUP BY 1, run as an ordinary measurement query. Sizing needs no approval because it changes nothing.

The seed we gated most recently, purchasers from the standard audience table, built with the same query shape the cart-abandoner workflow assembles upstream:

SELECT
  user_id
FROM
  conversions_for_audiences
WHERE
  event_subtype = 'order'

That seed's companion COUNT came back at 12,480 distinct user_ids: above the 2000 floor with room to decay across weekly refreshes. On a lookalike, the same COUNT places the seed inside the 500 to 500,000 band; DSP's expansion tiers then run from roughly 300K to 1M members (most similar) up to 900K to 10M (most broad), region-dependent and subject to change. The corpus suggests starting balanced; a seed pinned to a tier's edge should be revised, not shipped.

The approver signs the JSON that ships: audienceName, advertiserId, the flattened query, the window, and refreshRateDays

In front of the human sits the creation payload itself, not a summary. The fields match the promotional-events lookalike playbook's example: audienceName, audienceDescription, advertiserId, the seed SQL flattened into query, timeWindowStart, timeWindowEnd, timeWindowRelative, and refreshRateDays; lookalike submissions add lookalikeAudienceExpectedReach, "BALANCED" in the corpus example. The same playbook scopes two recommendations to its pattern: refreshRateDays: 7 "to ensure optimal performance," and timeWindowRelative: FALSE to keep each refresh looking at individuals from the previous event.

Shipped text is not drafted text. Introduction to AMC Lookalike Audiences recommends removing all comment lines from the query before pushing to audience creation, and the seed gets flattened into the JSON regardless, so what a human eyeballed in an editor is not automatically what ships. The Skill closes that gap by hashing the flattened, comment-stripped query and binding the approval to the hash: change query by one character and the gate reopens.

{
  "artifact": "audience_definition",
  "workflow": "amc-activation-approval",
  "requiresApproval": true,
  "activation": {
    "audienceName": "AMC_Purchasers_Weekly_2026Q3",
    "audienceDescription": "Purchasers, June 2026 order window",
    "advertiserId": "123456789",
    "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
  },
  "checks": {
    "seedCount": {
      "measured": 12480,
      "threshold": "2000 distinct user_ids rule-based activation floor"
    },
    "tableVariant": "FROM uses _for_audiences tables only",
    "destination": {
      "advertiserId": "123456789",
      "instanceId": "amcinstance01"
    },
    "querySha256": "5b3c9f1e0a4b2d83c56a1908d7e5bc2a4f8e6d0b1a9c8e7f5d3b2a1c0e9f8d7b",
    "atlasChunks": [
      "6e39ff4c3e1ed64b",
      "3592514e4137c936",
      "9e1e29903178da48",
      "9fadd181160a41e4"
    ]
  },
  "decision": "approve | revise | cancel",
  "records": {
    "audienceExecutionId": null,
    "status": null,
    "statusReason": null,
    "audienceCount": null,
    "dspAudienceId": null,
    "lastRefreshedTime": null,
    "approvedBy": null,
    "approvedAt": null
  }
}

Two fields deserve more attention than the SQL. advertiserId is the destination: the DSP seat the audience lands in, confirmed, not assumed. And refreshRateDays makes activation a standing write, not a one-off: the query re-runs on cadence under this single approval, so the human is approving a recurring behavior, which is why the hash check stays live after the yes.

"Successful" in AMC is not "active" in DSP: allow 24 to 36 hours and keep your own run log

The clock after the approved POST belongs to Amazon. The Programmatic Audience Framework Playbook is precise: "Once an audience creation status is returned as 'successful' in the AMC API, it can take between 24 and 36 hours to be 'active' and ready for use in Amazon DSP." I nearly resubmitted after one quiet day; the playbook says that quiet day is the system working.

Amazon also leaves a hole in the audit trail. The same playbook admits there is currently "no unique id field that is common for both the AMC endpoint and Amazon DSP endpoint"; the only mapping for now is "by name and by the approximate creation date." The monitoring output does include dspAudienceId and dspCanonicalId columns, but by the playbook's own statement those values cannot join the two systems, so lean on neither. Copy its working practice instead: filter the DSP audience list by audienceName prefix, category "Custom-built," subCategory "AMC," which only works if the naming convention was enforced at approval time.

So the run log is the join key, not bookkeeping. Per audience, the agent logs what it watches by audienceExecutionId: status, statusReason, audienceCount, lastRefreshedTime, the query, and the window, next to the approval record itself, the same argument that makes run logs non-negotiable for MCP writes.

What happens next

Approval closes the gate once; the Skill keeps watching. It expects the DSP entry inside the 24-to-36-hour window and logs execution metadata on every refresh, keeping the name-plus-creation-date mapping current. When an audience stops refreshing, the playbook's diagnosis is blunt: "it is most likely the audience size has dropped below 2,000 unique users," flagged after a one-day buffer past refreshRateDays. After several failed refreshes the instruction turns operational: decrease or stop spending on that line item, because it keeps targeting the same users as they move down the funnel. Each refresh is also the moment to re-measure overlap against segments already live in Amazon DSP (via conversions_all), at launch and mid-campaign, since affinity and size metrics do not necessarily indicate overlap.

The loop runs on the Amazon Agent Data layer: the Amazon Ads MCP carries the AMC sizing reads, the gated submission, and the refresh monitoring, and the Selling Partner MCP joins when audience logic depends on catalog facts, like which ASINs a promotion actually covers. That is the whole pattern: reads run free, the one write stops at a person, and the approval binds to the exact artifact 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.

Everyone in Your Category Has the Same AI Now

2026-05-06T00:00:00Z

If you sell on Amazon, something quietly changed underneath you in the last two years, and most of your competitors haven't noticed what it actually means.

Every seller in your category now has access to the same frontier AI you do. The same models, the same chat window, the same "analyze this search term report" prompt. The tools got extraordinary, and they got extraordinary for everyone at exactly the same moment. When the most powerful tool in your business is also sitting on your competitor's desk, the tool stops being the difference.

So what is the difference?

The model knows about Amazon. You know Amazon.

Ask a frontier model how to structure a Sponsored Products campaign and it will give you a competent answer. It will give your competitor the same competent answer. It has read everything ever written about Amazon: the help docs, the blog posts, the courses, the conference talks, the prompt packs. But that's the tell. It knows about Amazon the way someone who read a book about swimming knows about water. That knowledge is now the floor: table stakes, priced at twenty dollars a month.

Because Amazon doesn't run on what's written down. It runs on unwritten rules, and those were never in anyone's training data. The gap between what Seller Central says and what Amazon actually does. What genuinely gets a suppressed listing reinstated, versus the case wording that earns you another canned bot reply. Why your attribute update silently loses to an upstream contribution, and which "errors" you can safely ignore. How the algorithm really behaves after a price move, how enforcement really works, how long things really take. The internals, the quirks, the behaviors, the operational know-how you only earn by running the machine for years and paying tuition every time it surprises you.

The layer that's only yours

And stacked on top of that sits the layer that's exclusively yours: the size-chart rewrite that cut your bestseller's return rate 40%, the fifty thousand dollars of wasted spend encoded in your negative keyword lists, why you never run deals on that one ASIN in Q3, the campaign structure you arrived at after three years of expensive lessons.

That's your DNA. Some people call it tribal knowledge. It's the reason a customer chose you over the four identical-looking listings above and below you, and in the most literal sense, it's your IP. In a marketplace as brutally commoditized as Amazon, it may be the only IP you have that can't be copied, undercut, or bought.

We're not the only ones who see it this way. In late June 2026, Alex Karp's Palantir posted a nine-point manifesto on AI sovereignty: data as treasure, knowledge as the asset that compounds, ownership as the precondition for having a future at all. He argues it from the world of defense and statecraft. We didn't need the confirmation, but we'll take it: it's the same signal we built Kuudo on. If it's existential for nations, believe that it's existential for a business fighting for the buy box.

Why are Amazon sellers walking into this trap faster than anyone?

The path of least resistance on a busy afternoon is to paste it all into a public chatbot. The search term report. The business report. The P&L. The strategy doc for your Q4 push. Every hard-won correction, typed into a tool you don't control.

Do that long enough and your edge stops being yours. It gets absorbed into the same model your competitor opens tomorrow morning. The advantage that took years to earn doesn't fade. It gets donated.

Read the pitches yourself

And you don't have to squint to see the machine, because a whole product category now advertises it right on the homepage. Look at the wave of AI listing-optimization tools and read their pitches carefully:

ListingOptimization.ai leads with AI "trained on thousands of winning listings" and a template library for cloning A/B test winners. Whose winning listings? Who paid for the losing variants?

Pixii grades your listing against a database of 100,000 top-performing listings and offers proven templates drawn from high-converting ones. Somebody earned those conversions.

Nozam sells review mining on any ASIN, yours or your competitor's, to surface exactly what customers hate about them.

Clicco promises visuals and copy that learn from top competitors. And Selluna says it plainest of all: upload any competitor's image and it recreates the style with your product: "Their inspiration, your listing."

None of this is hidden. It's the value proposition. These are redistribution engines: they harvest what worked (the winning image, the converting layout, the review insight) and hand the distillation to the next subscriber for a monthly fee.

Every one of those "winning listings" in the training data was some seller's tuition: the photoshoots, the failed variants, the split tests, the years of learning what actually converts in one category. That edge is now a template, available to the four listings above and below yours for a monthly fee.

The flywheel only spins one way

Here's the part to sit with: the flywheel only spins one way. They learn from you, and they offer that learning to the next user. Today you're the customer. The day your listing starts winning, you're the inventory. One of these tools even answers "Is my data private?" in its FAQ with yes, for paid plans. Privacy as an upsell. That's the market telling you, in writing, what your knowledge is worth to them.

But don't stop at the upsell, because a privacy line, even a sincere one, answers a narrower question than the one that matters. Several of these tools do promise they won't sell your data, and that promise can be entirely true while the flywheel spins anyway.

The thing that compounds isn't your file. It's the learning stacked on top of it: which of the six generated main images you shipped, which template you cloned, which headline you kept and which you threw away, which "winner" you took into your split test. That's your operator judgment, years of expensive lessons, compressed into clicks, and it's exactly the signal a system like this needs to get smarter for the next subscriber in your category.

Read the pitches again: a grader scored against "100,000 top-performing listings," AI "trained on thousands of winning listings," libraries of "proven templates from high-converting listings." Proven by whom? Somebody's photoshoots, somebody's failed variants, somebody's tuition. The learning travels even when your name doesn't. They anonymize you. They don't anonymize what they learned from you. That's the product.

This isn't new. It's just faster now

Sellers should recognize the pattern, because the Amazon software industry ran this play long before AI: tools that pooled your data into "category benchmarks" and sold the aggregate back to you and everyone you compete with.

The new crowd is faster and slicker, but the business model is identical: build the product on top of your knowledge until your knowledge becomes the thing they sell. Take it to its end and they don't need you at all. The next seller just pays for access to the expertise you handed over. That isn't being out-competed. It's commoditizing yourself, one upload at a time.

The brands still donating their edge to someone else's flywheel will look up one day and find they no longer have one.

The answer isn't less AI. It's AI in a private place.

This is the conviction Kuudo is built on, and it's worth saying plainly: when everyone runs the same models, your advantage is the private knowledge only you have, and keeping it yours is no longer a matter of discipline. It's a choice.

The wrong response to the leak is abstinence. Refusing to use frontier AI while your category compounds with it isn't protecting your edge; it's forfeiting the game to protect the ball. The right response is to give AI your knowledge and a private place to do the work, where your years of order history, campaign judgment, and catalog-specific wisdom accelerate the business instead of leaking out of it.

That's what Kuudo is

A private place for AI to work on what only you know. It runs in your cloud, not ours. Nothing inside it trains anyone else's model: Google, Meta, Anthropic, and OpenAI can't learn from what you never gave them. There's no fine print about what counts as "your data," because in your own cloud the definition is total: the inputs, the outputs, the choices, and everything the system learns from them are yours, the learning included. And if you ever walk away, what you built stays yours, because it lives in your cloud.

Private. Trusted. Owned. In that order, always together.

And because you supply what no vendor can (your choices, your judgment, the calls only your team would make), no two Kuudo deployments look alike. It isn't a finished product you rent. It's the ingredients: the data layer, with Amazon Ads MCP steering spend and Selling Partner MCP touching your catalog; the Amazon Agent Atlas grounding, and the tools and skills your agents run. You keep the IP. You own the means of production.

Why Amazon first

We start with Amazon deliberately, because it's where some of the densest, most defensible operator knowledge in the world already lives, and where the stakes of giving it away are highest. Millions of sellers, one search results page, and a customer who can't tell you apart until something tells them to. That something was never the model.

It was never the clever prompt. It was the unwritten rules, the hard-won know-how, the accumulated judgment about how the machine actually behaves and what actually works, earned by you, running your business, one expensive lesson at a time.

Everyone has the same AI now. Your edge is what it doesn't know.

Keep it that way. Build your moat, and let your competition give theirs away.

For how this plays out in practice (an agent doing real listing work with your knowledge staying yours), start with how a suppressed listing gets diagnosed and fixed.

Kuudo — Run real Amazon work from any AI client

Launch a DSP Campaign Without Half-Built Entities

Create every entity paused and read each write back before anything depends on it

Zero eligible tactics is a goal-KPI mismatch, not an outage

The ad group renames the inventory type the campaign just used

Activate parent-first, or the ad groups fail against a campaign Amazon cannot see

Confirm delivery in the DSP tables, not in the create response

What happens next

The Data-Mode Router That Stops Bad ACoS Math

The router tags every dataset ads, organic, or mixed before a metric runs

ACoS in organic mode isn't a style nitpick, it's priority #1 forbidden

Mixed data doesn't get blended into one number, it gets split into two

Organic mode routes to Conversion Performance Index, not ACoS

What happens next

Auditing FBA Reimbursements: What Amazon Owes You

A loss or damage event isn't one claim, it's three claim types with three different windows

Eligibility isn't a spectrum, it's seven gates that all have to hold

Valuation depends on when the loss happened, not what the item is worth

Reimbursement isn't a one-shot event, it's a loop most sellers never run

What happens next

The ARA Report and Metric Glossary for Vendors

Every ARA dashboard has a mirrored SP-API report type, so naming the dashboard is only half the job

ARA and ABA are different products gated by different rules, so "I can't find my dashboard" means two different problems

Amazon's own ARA docs define "Conversion" two different ways on the same overview page

Four recurring distortions make an ARA number look complete when it isn't

What happens next

Listing Suppression Diagnosis: Stranded or Buyable

BUYABLE and DISCOVERABLE separate suppression from stranding

The suppression reason chooses the repair

The stranded reason chooses relist, restore, or removal

A repair is complete only when status returns

What happens next

The Agent Bidding Rulebook That Prevents Bid Thrash

Thin data gets a hold, not a bid change

Scale and pull-back fire at fixed distances from target

Every lever is clamped before it ships

Precedence decides which rule wins

What happens next

Recover Featured Offer Eligibility Without Guessing

Eligibility is a gate, not proof of placement

PRICING_HEALTH isolates a price-driven ineligibility

Eligible offers still compete on price, shipping, and experience

The recovery artifact should recommend, not silently reprice

What happens next

FBA Inventory Health After the 2024 Fee Change

Separate the fee policy from the inventory decision

Measure capacity in cubic feet, not units

Review monthly storage separately

Catch aged inventory before the fifteenth-day snapshot

What happens next

Find ASIN Margin Leakage with Net PPM

The Net PPM dashboard identifies products driving profitability up or down

Net PPM separates revenue, PCOGS, CCOGS, and sales-discount pressure

A rate-leakage proxy ranks material ASIN deterioration before investigation

Manufacturing-view access and Warehouse Deals exclusions define the report boundary

What happens next

Brand Registry: Fix 'Trademark Already Enrolled'

"Trademark is already enrolled" means an Administrator already exists, and the fix is becoming an additional user

Request an invitation from a known Administrator, or continue to apply and share your contact information

An inactive Administrator opens two escalation paths: the "use this form" appeal and an "Update brand ownership" support case

Once you reapply, the clock is Amazon's: 10 business days of review, a 3-day completion deadline, a 10-day reply window

What happens next

Dispute a PO On-Time Accuracy Chargeback

The first dispute is a 30-day evidence deadline, not a support case

The evidence must contradict the exact PO on-time data point

A useful dispute letter names one error and one contrary record

Smart Aggregation separates previews, confirmed charges, and reversals

What happens next

Measure Off-Amazon Conversions in AMC

Events Manager data reaches AMC only after the event is linked to a DSP order

Purchase sales and non-purchase conversion value are different measurements

The canonical Total Impact query joins campaign delivery to conversion outcomes

Events Manager history is complete only from October 20, 2023 onward

What happens next

Rebuild Your Listing Images From Your Own Photos

Seeding from your own product photos turns a photographer-studio-designer-upload chain into one conversation

When cost-per-image and effort-per-listing crater, the math flips: every listing gets brought up to standard, not just the heroes

Every generated image is graded against Amazon's image rules before it can publish, and a human approves the final set

What happens next

Amazon FBM Orders Reports: What to Request and Why

`BUYABLE` and `DISCOVERABLE` separate suppression from stranding

`PRICING_HEALTH` isolates a price-driven ineligibility