Automation

Rules you can read back.

Objectives, criteria, and rules stay visible, and each run records what it decided, rule by rule.

Workspace
Automation, in the App
Scope
Assigned per ad group and product
Access
Editing and applying live are separate permissions

Every kind of decision is named.

A rule states which decision it makes. Criteria decide which targets it reads. Nothing is hidden behind a single optimization switch.

AutomationSeller profile: Northwind HomeSample data
OverviewRulesDaypartingMemoryObjectivesASINsAssignmentsRuns
Rule type: BiddingTrigger mode: Momentum GuardPreview changes
RuleCriteriaConditionsPriorityStatus
Protect target ACOSStandard CriteriaEvery threshold passes in the Data Window10Enabled
Limit economic lossLoss Budget GuardSpend above allowance, constrained by Orders band20Enabled
Recover lost momentumMomentum Guard90-day baseline, 60 / 30 / 14-day order pace30Enabled
The Rules workspace in Automation, scoped to bidding rules, with the criteria and conditions each rule reads. Values shown are sample values, not customer data.

An objective sets what an ad group is working toward, and rules are assigned to the ad groups and products that should follow it. Because the parts are separate, a change in strategy does not require rebuilding every rule.

Objective strategies available today

  • Standard Bidding
  • Top of Search
  • Product Pages
  • Audience Boost
  • Combined Boosts
  • Dynamic Bidding
  • BiddingTarget ACOS, fixed and percentage moves, loss-budget and momentum guards, plus bid boundaries.
  • ImportPromote converting search terms into keyword targeting with deduplication and controlled initial bids.
  • Negation + unnegateBuild two-way rules that create or remove exact and phrase negatives inside the scope you define.
  • Negation wordFind repeated losing words across queries and protect terms held in product memory.
  • DaypartingSchedule both bid changes and enable or pause states by hour, with criteria and assignments kept separate.
  • StatusEnable or pause targets only when the configured criteria and safeguards pass.
  • Placement + budgetControl campaign placement adjustments and budget decisions inside their own limits.

The workspace is the audit trail.

Assignments show what is currently automated. Runs show what happened. Memory keeps the per-product history a rule relies on between runs, so a decision can be traced back to the state that produced it.

  • Preview before commitmentRule output can be inspected before it is treated as work to apply.
  • Runs stay on the recordA run keeps what it decided and what it delivered, rule by rule.

Nothing reaches the account without passing the gates.

Rule output is staged by default. Delivering it to a live Amazon Ads account passes apply gates the platform operator controls, separately from the permission to edit a rule.

Apply gates decide whether live delivery is possible at all, and a permission decides who may apply inside a seller profile. With auto-apply switched on, a scheduled run delivers its own decisions and the run record is what you read afterwards. With it off, the run stops at staged output and waits for a person.

Where applied changes are reviewed

SignalPerformance and search terms

Advertising data lands in the seller profile it belongs to.

ProposalA change is prepared

Suggestions and rule output are staged with the evidence behind them.

GateApply gates and permissions

Live application passes operator-controlled gates, and permission decides who may apply.

DeliveryA person applies it, or an enabled run delivers it

Staged work waits for a decision. With auto-apply switched on, the run delivers to the account itself.

RecordRuns and change history

The run keeps what it decided, and the account change is recorded with its type and source.

The path a rule-driven change follows. Schematic, not a product screenshot.

Automate the part you can explain.

Set an objective, assign the rules that serve it, and keep every run readable in the same workspace.