# Amazon New to Brand Metrics: Count Customers in AMC

Canonical page: https://www.kuudo.com/guides/amc-ntb-customers/

Amazon new to brand metrics in AMC: count distinct customers from conversion-time events, without confusing users, purchases, or attribution drift.

Author: Thomas Spicer
Updated: Oct 19, 2026

## Summary

New-to-brand (NTB) customer counts come from `amazon_attributed_events_by_conversion_time` filtered to `purchases > 0` and split by the `new_to_brand` boolean. Use the conversion-time table (not by_traffic_time) for any recurring workflow. NTB lookback is 365 days, Amazon-managed.


Amazon new to brand metrics separate customers from orders. In Amazon Marketing Cloud (AMC), count distinct customers from the conversion-time view, then separate that customer count from purchases, units, and revenue. This workflow identifies the correct NTB signal, prevents traffic-time attribution drift, and returns a comparable campaign metric without pretending every conversion row represents a new person.

## 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, and the Amazon Ads console gives a partial number that excludes Amazon's demand-side platform (DSP). Broadly available AI can hand back a SQL query that compiles and counts the wrong table. The right answer lives in three [Amazon Marketing Cloud](/features/amc/) (AMC) instructional queries plus a schema document, joined to the authorized instance through the [Amazon Ads MCP](/features/amazon-ads-mcp/).

[ChatGPT, Claude, Perplexity, Microsoft Copilot, and whatever comes next](/features/ai-clients/) know nothing about your business out of the box. Your competitors use those tools too. Kuudo gives those same tools your edge: **your data**, **your rules**, and **the way your business operates**. That means **your account as it is right now**, **your judgment running every time**, and **your call before anything changes**.

### Preserve the customer-counting method

The MCP supplies live account context and authorized tools, [Skills](/features/skills/) preserve the measurement method, [Amazon Agent Atlas](/features/agent-atlas/) applies Amazon-specific guidance, and approval controls keep the reporting decision yours.

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

## The AI is shared. Atlas changes the measurement decision

> **Four failure modes I watched in a single un-grounded draft of this query**
> 1. 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.
> 2. It forgot `purchases > 0` and counted every user the campaign reached, not just buyers. The denominator was wrong and so was the percentage.
> 3. 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.
> 4. 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](/features/amazon-ads-mcp/), so the agent could resolve the column without resorting to a live web fetch via [Amazon Agent Crawl](/features/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:

```sql
-- 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**
> 1. 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.
> 2. 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).
> 3. 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](/guides/amc-custom-attribution-models/) is sharper here than the IQ doc admits.
> 4. 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.
> 5. 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](/features/skills/) 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](/features/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](/features/amazon-agent-flow/): Amazon Ads MCP brings campaign and AMC signals, the [Selling Partner MCP](/features/amazon-selling-partner-mcp/) can add catalog context, Atlas grounds the table choice, and Skills turn the query into a reviewed recurring automation.

### Use the NTB readout to review campaign allocation

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: [map paths across DSP and sponsored ads](/guides/amc-path-to-conversion-sankey/) to see the campaign sequences that precede a conversion.*


## Frequently asked questions

### Why does the NTB count from this AMC query differ from the Amazon Ads console NTB number?

The Ads console reports NTB for sponsored ads only. The AMC IQ reports NTB across every ad source in the AMC instance, including DSP. The two are not reconcilable line by line; they answer different questions.

### What is the difference between new-to-brand customers and new-to-brand purchases?

Customers are distinct users; purchases are distinct orders. A single NTB customer with three orders counts as one NTB customer and three NTB purchases. The `New to brand customers` IQ uses the customer count; the adjacent `New to brand purchases` IQ uses the order count.

### Why does AMC block user_id in my final SELECT?

`user_id` carries an aggregation threshold under AMC privacy safeguards. It is legal inside a CTE that aggregates it away (`COUNT(DISTINCT user_id)`) but cannot appear as a column in the query's final output.

### Can I use amazon_attributed_events_by_traffic_time instead?

The query will run, but the traffic-time table extends the conversion window by up to 30 days after the query date range, so a recurring NTB report pinned to it produces a different number each run. Use conversion-time for any workflow you intend to run more than once.

### What is the NTB lookback period in this IQ?

365 days. The lookback is Amazon-managed and not a parameter you can pass in. For a custom lookback (e.g. 1095 days), switch to the `amazon_retail_purchases` NTB gateway IQ, which requires retail-purchase data rather than ad-attributed data.

### How do I count NTB customers if I only have pixel conversions?

This IQ requires promoted ASINs that resulted in ad-attributed purchases. Pixel-only advertisers should switch to the `amazon_retail_purchases` NTB gateway IQ or to the custom-attribution `conversions` data source.

### Should NTB% be near 100% on a new product launch?

Usually yes. A brand-new product with no existing customer base will produce close to 100% NTB in the first month. A launch returning 30% NTB typically means existing brand customers are browsing the new ASIN — the brand-halo effect, not a failure.


## Sources

- [AMC Instructional Query — New-to-brand customers](https://advertising.amazon.com/marketing-cloud/instructional-queries/1d572ebe8ca7baab0d45003ced0eb34114b565eca699a17dc6463371e0e2dbc2)

- [amazon_attributed_events_by_conversion_time schema reference](https://advertising.amazon.com/API/docs/en-us/guides/amazon-marketing-cloud/datasources/amazon_attributed_events_by_conversion_time)

- [AMC Instructional Query — New-to-brand purchases](https://advertising.amazon.com/marketing-cloud/instructional-queries/246acd1e54dc46d5c1216bee80337856b97f548785163579894e46fa9627319e)

- [AMC Instructional Query — New-to-brand gateway ASINs](https://advertising.amazon.com/marketing-cloud/instructional-queries/942cc659aff502110d0ca5f42f6db934df1275fb31e3e54daee94a3901678177)

- [Amazon Marketing Cloud — Data aggregation thresholds](https://advertising.amazon.com/marketing-cloud/help)