# Amazon PPC Bidding Rules That Prevent Bid Thrash

Canonical page: https://www.kuudo.com/guides/rules-agent-bidding-rulebook/

Set Amazon PPC bidding rules around data sufficiency, an ACoS deadband, and a daily bid clamp so an agent changes bids only when all three agree.

Author: Thomas Spicer
Updated: Oct 19, 2026

## Summary

A sane bidding rulebook moves a bid only when three gates agree: the n-gram clears data sufficiency (1-grams need `IMP_g >= 50` and either `CLK_g >= 10` or `ORD_g >= 2`), ACoS sits outside a deadband of 0.9x to 1.1x target, and the change fits a daily clamp of plus or minus 20%. Top-of-Search multipliers cap at 1.50, every action carries a 5-day review window on Ads, and when two rules collide a fixed precedence ladder decides, with pull-back beating scale on ties unless credible intervals say otherwise.


Amazon PPC bidding rules stop 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](/features/ai-clients/), which runs it as a [Skill](/features/skills/) over the [Amazon Ads MCP](/features/amazon-ads-mcp/), grounded by [Amazon Agent Atlas](/features/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.

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

### Apply the bidding rules to live account state

The [Amazon Ads MCP](/features/amazon-ads-mcp/) supplies live campaign state and authorized actions, [Skills](/features/skills/) enforce your decision rules on every run, [Amazon Agent Atlas](/features/agent-atlas/) supplies Amazon-specific guidance, and approval controls keep material changes in your hands.

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

> **The AI is shared. The moat is yours.**
> - **Your account, as it is right now.** It cannot see impression counts per n-gram, so it cannot tell a 4,000-impression term from a 40-impression one. Paste a top-50 rows sample and it will confidently rank terms that have no statistical business being ranked. And your search-term data is now sitting in someone else's chat log.
> - **Your call, before anything changes.** Even when it correctly says "this needs more data," it cannot set a hold, record a cooldown, or stop a downstream job. Nothing enforces the wait except you remembering.
> - **Your judgment, running every time.** Ask for a minimum impression threshold and you get a plausible round number. The real gates are versioned per n-gram length in the corpus playbook, and they are not the numbers a public model guesses.

## Scale and pull-back fire at fixed distances from target

The fixed distances are 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 |

> **The AI is shared. The moat is yours.**
> - **Your account, as it is right now.** It does not know your `TARGET_ACOS`, so it cannot compute a deadband around it. Tell it your target and it will still evaluate against the single number rather than a band, which is the behavior that thrashes.
> - **Your call, before anything changes.** It can describe a +8% bid increase. It cannot apply one. If you retype that change into Campaign Manager yourself, nothing records that the entity is now in a 5-day review window, so next week you may well move it again.
> - **Your judgment, running every time.** The Skill preserves the playbook's 0.9 and 1.1 multipliers, +5 to 10% magnitudes, and 5-day re-evaluation. The shared AI alone has no reason to produce those particular numbers consistently.

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

```json
{
  "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 }
}
```

> **The AI is shared. The moat is yours.**
> - **Your account, as it is right now.** It cannot see what the bid was yesterday, so it cannot tell you whether a proposed change is inside the daily clamp. Apply its suggestion by hand two days running and you can move a bid 40% without noticing.
> - **Your call, before anything changes.** Placement multipliers are a good example: it can tell you to raise Top-of-Search by 10%, but it cannot read the current multiplier, so neither of you knows whether that crosses the 1.50 cap until you are in the console.
> - **Your judgment, running every time.** Ask for safe bid-change bounds and you get advice, not a contract. The clamp here is a field on the decision record, which means a downstream job can reject anything that violates it.

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

> **The AI is shared. The moat is yours.**
> - **Your account, as it is right now.** With no click and order counts it cannot compute a credible interval at all, so the one mechanism that resolves a scale-versus-pull-back tie is unavailable to it.
> - **Your call, before anything changes.** Ask it to arbitrate two conflicting recommendations and it will pick one in prose. Nothing stops both from reaching the account if you work through its list by hand and apply each item as you read it.
> - **Your judgment, running every time.** The Skill enforces the seven-level precedence ladder and documented tiebreak on every run. The shared AI alone can produce a reasonable-sounding ordering that differs from the one your rulebook actually uses, which is worse than no ordering because it looks authoritative.

## What happens next: review the decision plan before anything reaches the account {#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](/guides/human-approval-for-amc-activation/) on [Amazon Marketing Cloud](/features/amc/) 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](/features/amazon-agent-flow/), 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](/features/amazon-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.

### Review the other levers that move ACoS

Bids are one lever among several. Negatives, placements and the listings behind the ads move ACoS too, and [how to reduce ACoS on Amazon](/guides/how-to-reduce-acos-on-amazon/) takes them in the order that protects sales.

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


## Frequently asked questions

### What is bid thrash?

Bid thrash is a bidder raising and lowering the same bid across consecutive runs because it reacts to noise instead of signal. The deadband between 0.9x and 1.1x target ACoS is what stops it: inside that band no rule fires at all.

### How much data does an n-gram need before a bid can move?

For 1-grams, `IMP_g >= 50` and either `CLK_g >= 10` or `ORD_g >= 2`. 2-grams need `IMP_g >= 100` and 3-grams need `IMP_g >= 150`, with the same click-or-order condition.

### How much can a bid change in a single day?

Plus or minus 20%. The daily bid change clamp is a global control, so no single rule run can move a bid further than that regardless of how far off target the n-gram is.

### What happens when a scale rule and a pull-back rule both match?

Pull-back wins. The precedence ladder runs invalid computations, thin data, safety negatives, pull back, scale, mining, then creative and ops. Scale only beats pull-back when credible intervals support it with high confidence.

### Why does my bidder recommend no action on a keyword that is clearly losing money?

It is almost always the starvation guard. When `CLK_l30d < 50` and `ORD_l30d < 5`, the rulebook emits `hold_thin_data` and stops rather than acting on a sample too small to trust.

### How high can a Top-of-Search placement multiplier go?

1.50 is the cap as a global control. A scale rule that raises Top-of-Search by 10% still cannot push the multiplier past that ceiling.

### How long before a rule re-evaluates the same entity?

The standard review window is 5 days for Ads and 7 to 14 days for Organic and Ops actions. Every decision record also carries its own `cooldown_days`, defaulting to 5 to 14 depending on action type.


## Sources

- [Amazon Ads API documentation](https://advertising.amazon.com/API/docs/en-us/)

- [Credible interval (Bayesian interval estimate)](https://en.wikipedia.org/wiki/Credible_interval)

- [n-gram](https://en.wikipedia.org/wiki/N-gram)

- [Efficient n-gram, Skipgram and Flexgram Modelling with Colibri Core](https://www.researchgate.net/publication/305803357_Efficient_n-gram_Skipgram_and_Flexgram_Modelling_with_Colibri_Core)

- [Amazon Ads help center](https://advertising.amazon.com/help)