Amazon ads note · Reading trap

Reading trap: AMC says 100% of your ad buyers are new customers

Privacy masking blanks small cells, and returning customers live in small cells, so fine-grained new-customer shares come out too high.

1

The claim

“I ran a new-to-brand query in Amazon Marketing Cloud by keyword. This term shows 100% new customers. Pure acquisition. Scale it.”

When I saw a result like that on one of my own products, it felt wrong. The feeling was right. Nothing about the query was exotic; the problem was in how the output gets read.

2

The usual reading

AMC is the most granular, user-level source an advertiser has. If it says every buyer from a keyword or campaign was new to the brand, that's taken as close to ground truth — more trustworthy than the standard reports, not less.

3

Premises, laid out

Every conclusion below rests on these. Reject one and you can see which conclusions fall with it.

  • ✅AMC works from user-level purchase history. That's why the question can be asked at all.
  • ❌The rows you get back are the whole population. They aren't. AMC applies privacy protection to every output row. In my experience, a row with too few distinct users keeps its count, but its dimension values — the keyword, the campaign, the recency bucket — come back blank.
  • ❌Blank rows are noise you can drop or de-duplicate. They are real, distinct groups of people. Dropping them removes real buyers. Merging them collapses many separate groups into one.
  • ⚠️Any error would be random. It isn't. It runs in one direction.
4

How we take it apart

Free: conclusion + one screen

Conclusion: the masking bias is one-sided, and it inflates new-customer share. Take your new-customer share from the undivided level, not from the fine-grained rows.

Figure placeholderFor one product-week, three bars — buyers in visible keyword rows, buyers in blanked rows, and the undivided total — with the new-customer share computed on visible rows only vs on the total.

The full step-by-step decomposition, including how AI joins the reports, is in the course.

5

Evidence

Free: one example

Experience (mechanism), with illustrative numbers

I hit this on my own data and fixed it; I'm not publishing figures from those query results, so here is a made-up example. Illustrative numbers, not from a real account: one product, one week, split by keyword × recency bucket. The visible rows hold 60 buyers, none of them returning; the blanked rows hold 40, of which 25 are returning. Read the visible rows only, and the keyword view says 100% new. Reconcile to the undivided total of 100, and it's 75%.

6

What would prove this wrong

Free: one sentence

Disproof condition. If the split rows added up to the undivided total with no blank rows, masking wouldn't be the explanation, and a 100% would deserve to be taken at face value.

7

How you run it

Course only
In the course

Reproduce this on your own account

  • Step-by-step operations, including the AI prompts used to join reports
  • Query templates and the exact fields to pull
  • A checklist to rule out the common reading traps
  • The full disproof conditions and the failed cases
See what the course includes
8

Ledger status

Status: reading trap, confirmed on my accounts. Privacy masking hides small cells, and returning customers live in small cells, so fine-grained new-customer shares come out too high. Never drop blank rows; reconcile every split against an undivided total, and take new-customer shares from the coarsest level.

Verdict Reading trap
TypeExperience
Last updated2026-10-12

Type, in detail: Experience (mechanism observed on my own data; numbers shown are illustrative).

Have data that says otherwise? Share a case. Reversals are published.

Get the notes by email

New notes and ledger reversals, nothing else.

Prototype: email service not connected