A search term is costing you money, so you block it. Two weeks later the term is still in your search term report, still taking clicks, still on the same product. Nothing is broken, and the negative did exactly what it was asked to do. It was simply asked to do far less than you thought.
A negative keyword belongs to one ad group. It has no opinion about the rest of your account.
The unit is the ad group, not the product
Amazon attaches a negative to the ad group — or the campaign — you created it in. Most sellers reason about their account in products: this ASIN should not show for that query. Amazon does not store that thought anywhere. It stores a rule about one container.
A single ASIN typically runs in several ad groups at once. An exact-match campaign, a broad research campaign, an auto campaign that discovers new terms, maybe a competitor-targeting campaign. Block a query in one of them and the other three carry on:
| Where this ASIN runs | Negative present | Clicks, 30 days | Orders |
|---|---|---|---|
| Exact — core terms | Yes, added here | 0 | 0 |
| Broad — research | No | 64 | 1 |
| Auto — discovery | No | 88 | 0 |
| Competitor targeting | No | 31 | 0 |
You blocked 0 clicks and left 183 running. The report looks like the negative failed. It did not fail — it was applied to a container holding a fraction of the exposure.
Why this survives so long
Because the feedback is delayed and ambiguous. Spend on the query drops a little, so the change looks like it worked. The remaining spend is spread across ad groups you were not looking at when you made the decision, and by the time you next read that report you are reading a total, not a per-ad-group breakdown. Nothing tells you the block only ever covered one of four places.
The reflex fix — block it everywhere, in every ad group, immediately — is worse than the problem when the term is genuinely earning somewhere. Which is common: a query that loses money against one product in a research campaign can be the query that converts on the exact-match campaign where the bid and the landing product are right.
Read wide, write narrow
These are two different questions, and treating them as one is the actual mistake:
- How much evidence am I allowed to use? One ASIN often does not run a query enough times to settle anything. Reading the term across that ASIN and its variations as one body of evidence gets you a decision that is worth making — especially when the variations differ mainly by pack size and share the same shopper.
- Where does the block land? In the ad group you assigned, and nowhere else. The evidence being wide does not make the write wide.
In Vendlen those are separate settings on purpose. Evidence is read at Individual ASIN or Product Group scope, and the negative is still created only in the ad group the Negation rule is assigned to. Nothing about choosing denser evidence quietly widens the blast radius.
Blacklist is the deliberate wide write
When a term should be blocked for an ASIN regardless of performance, add it to that ASIN's Blacklist. On the next run, Vendlen checks the entry against every eligible ad group advertising that ASIN inside an Objective with Blacklist enabled. It creates each missing negative without waiting for the search term to appear and without relying on an Import rule.
That reach is why Whitelist wins when the same term appears on both lists. It is also why a large Blacklist should be added in batches and read in Preview Changes before the Objective is enabled.
The part almost nobody sets up: taking a block back
Negatives accumulate. Every one of them was correct on the day it was made, against the evidence that existed then — a term with four clicks and no orders, a query that read as irrelevant, a seasonal product out of season. None of that stays true.
The reason a block is safe to make automatically is that removing one is also automatic.
Unnegation is the same machinery in reverse: it looks for terms that are blocked here and still earning where they run, and proposes lifting the block. That is why negation is configured as a two-way rule rather than a one-way one. A tool that can only ever add negatives builds an account that slowly stops being able to find new demand, and nobody notices because the loss is invisible — it is revenue that never happened.
Two controls before automatic negation
One safeguard reads order history. The other records the terms you choose to protect:
Standing safeguards
365 days. A term that produced an order anywhere in the last year, at the scope you chose, is protected from negation. It is on by default, and turning it off has to be a deliberate act rather than a side effect of a setting you were changing for another reason.
Whitelist. A protected term is not negated by Negation, Negation word or Blacklist. A Negation rule can bypass that protection only when you explicitly switch on Ignore the Whitelist.
What to do with this
- Before you conclude a negative failed, check every ad group that ASIN runs in, not the query total. The number you want is per-ad-group.
- Decide the evidence scope and the write scope separately. Ask "do I have enough evidence?" and "where should this land?" as two questions.
- Set up the reverse direction at the same time you set up the block. A negation rule without an unnegation rule is a ratchet.
- Look at what your existing negatives are blocking today. Some of them were right in March and are costing you orders now.