Rule-Based Optimization

Rule-Based Optimization: Automating Bids and Budgets

If your morning starts by opening campaigns to nudge bids and budgets, that is the job Automations exists to take off you. You describe the condition once, TrackIQ applies it on a schedule you set, and it records every change it makes. Watch the Automations walkthrough Prefer to watch? Seventy seconds on the screen and how to start safely. What you get out of it Three things, in order of how much they matter: 1. Speed of response. A rule that runs daily reacts to a keyword going bad in a day. You react when you next look, which might be Thursday. 2. Consistency. The rule applies the same logic to the four-hundredth target as the first. Attention does not. 3. A record. Every change is logged, so a bid change is something you can look up rather than something you have to remember. What it does not do is think. A rule applies your judgement at scale — so the judgement has to be right before you scale it. The Automations Screen Open Automations in the sidebar. The Automations toolbar with its two tabs Two tabs: - Rules — individual conditions. - Rule Groups — one rule applied across many campaigns at once. Build the logic once, point it at a portfolio. And two buttons top right: Change log, and + Create Rule. Reading the rules table The rules table | Column | Why it matters | |---|---| | Name | see the naming convention below — it is doing real work | | Groups | which campaigns this rule touches | | Rule Type | Targeting, Campaign, and what it acts on | | Status | Active or Paused | | Created | | | Last Run / Next Run | the two columns people forget, and the first place to look when a rule “did nothing” | | Run History / Changed | what it has actually been doing | The naming convention is worth copying Live rules are named like “MGO 925 — 14D LB — 1D Adjust”. That encodes the two settings you will otherwise have to open the rule to check: - 14D LB — a 14-day look-back. Judge performance on two weeks of data. - 1D Adjust — adjust daily. Getting that pair right matters more than the thresholds. Too short a look-back and you react to noise; too long and you react to something that stopped being true a week ago. Two weeks of data with a daily adjustment is a sensible default for most catalogues. Creating a rule Opening the Create Rule dialog + Create Rule asks what should this rule manage? Available now: - Targeting — adjusts bids or pauses keywords and product targets based on performance. - Campaign — adjusts budgets or pauses whole campaigns. Listed but not yet available (marked with a dot): Placement, Adgroup and Audience under Advertising; Harvest Keywords, Harvest Product Targetings and Negative Targeting under Harvest. Every rule type shows a plain-English Example of what it will do, such as: Every day at 09:00 — if ACOS > 40% and clicks ≥ 10, lower the bid 15%. Read that line before anything else. If it does not describe what you want, change the settings until it does. The nine Targeting recipes This is the part worth knowing about. Rather than building from scratch, Quick Start offers nine ready-made strategies. Expand one to see its recipe, then apply it. | Recipe | What it does | Reach for it when | |---|---|---| | Hit my Target ACoS | Scales each bid by how far its actual ACoS sits from your target, trims proven non-converters, scales what runs under target. | You have one number you manage to. The closest thing to a default. | | Bid autopilot (scale + trim) | Raises efficient winners, eases off high-ACoS targets, holds the rest. | You want one hands-off rule doing the whole job. | | Cut wasted ad spend | Trims bids on targets that have taken real clicks but produced no order. | Spend is up and orders are not. | | Rein in high ACoS | Steps bids down in tiers — hard when far over target, gently when only slightly over. | Blunt cuts have hurt you before. | | Boost profitable winners | Raises bids on targets already converting below your ACoS target. | You have headroom and want volume. | | Rescue impression-starved winners | Pushes bids up on targets that convert well but barely get shown. | Something converts brilliantly on tiny volume. | | Trim low-relevance keywords | Eases bids where impressions are high and clicks are not. | The ad is not resonating on those searches. | | Pause dead keywords | Pauses targets that have spent enough clicks to prove they will not convert — the classic 25-click cutoff. | Housekeeping. | | Reward high converters | Nudges bids up where conversion rate is strong. | You want to win more of the auctions you are good at. | Or Start blank Targeting Rule and build your own. Which to pick first: if you manage to a target ACoS, start with Hit my Target ACoS. If you are cleaning up an account you have inherited, start with Cut wasted ad spend — it is the one with an immediate, measurable saving. Scheduling Rules run on a schedule, and the table shows Last Run and Next Run for each. Timing matters more than people expect. A rule running at 09:00 judges yesterday as a complete day. One running at 15:00 is partly reacting to a day still in progress, and Amazon's data for the last day or two is still settling. If a rule appears to have done nothing, check Last Run first. Nine times in ten it has not run yet, or it ran and no target met the condition. The Change Log Change log, top right, is the record of every change every rule has made. This is the feature that makes automation safe to use. When a bid is not what you expect, the change log tells you which rule changed it, when, and from what. Without it you are trusting a black box; with it you are supervising a process. Start paused The single most useful habit: 1. Create the rule and leave it paused. 2. Read the Example line. Does it describe your intent in plain English? 3. Activate it, then check the change log after the first run. Look at what it actually touched. 4. Widen it. Once one rule behaves, apply it across a portfolio with a Rule Group. A rule you have verified once is worth far more than one you trusted immediately — and step 3 takes two minutes. Related - Guardrails to Set Before You Automate Anything — read this before enabling anything. - Dry-Run Preview: Seeing What a Rule Would Change — see what a rule would change, before it does. - Rule Types Coming Soon: Placement, Ad Group, Audience and Harvest — the rule types visible but not yet available. - The Bleeder Reports — the checks most worth automating first. - Bid Optimisation: Six Rules — the manual version, and which parts are safe to automate.

The Automations Screen: Rules, Rule Groups and the Change Log

Automations is where TrackIQ stops reporting and starts acting. Everything on this screen either defines a change, groups the campaigns it applies to, or records a change that has already happened. Three controls do all of it: two tabs, and the Change log button. Watch the walkthrough Prefer to watch? Sixty-three seconds on the two tabs, the change log, and naming rules properly. The Rules tab The Rules tab, one row per rule One row per rule, with the columns that answer the questions you actually have: | Column | Tells you | |---|---| | Name | what it does, if you name it well — see below | | Groups | which rule group it applies to | | Rule type | Targeting or Campaign, and what it acts on | | Status | ACTIVE or not | | Created | when you set it up | | Last run | when it last executed | | Next run | when it will execute again | Last run and Next run are the two worth glancing at. A rule with an old Last run, or a Next run that never arrives, is a rule that is not doing anything — and a silent rule looks exactly like a working one from every other column. Naming rules so the list stays readable The convention in a well-run account puts the settings in the name: Northwind Goods — MGO 925 — 14D LB — 1D Adjust Brand, the product or group it covers, the look-back window (14 days of data), and the adjustment frequency (acts once a day). Those two settings are what make two otherwise identical rules behave differently, and they are not columns — so putting them in the name is the difference between a list you can read and eleven rows called “Bid rule”. Do this from the first rule. Renaming later is a chore nobody does. The Rule Groups tab Rule groups, with a campaign count each A rule group is a named set of campaigns. Each row shows a name, an optional description, and a campaign count. Groups exist so a rule targets a set rather than one campaign. One rule pointed at a group of 31 campaigns is one thing to maintain; 31 rules is not. Use the description field. It is empty by default and it is the only place to record why a group exists — which matters when somebody inherits the account. + New Group creates one. Change log The button at the top right opens a record of every change automation has made on this account, newest first. This is the feature that makes the rest safe to use, because it turns automation from something that happens to your account into something you can audit. See The Change Log: Auditing What a Rule Changed. Create Rule The rule type chooser + Create Rule opens the type chooser. Two types are live today: - Targeting Rule — adjusts bids or pauses keywords and product targets. - Campaign Rule — adjusts budgets or pauses whole campaigns. Others are listed and marked as not yet available: Placement, Adgroup, Audience, and a Harvest family — Harvest Keywords, Harvest Product Targetings and Negative Targeting. They are visible so you can see where this is going, not because you can use them. Each live type offers a set of Quick Start recipes — pre-built rules you expand, review and apply — or a blank rule if you would rather build the conditions yourself. What to do first 1. Read the Change log before creating anything, if rules already exist. Knowing what is currently happening to your account beats guessing. 2. Create a rule group for the campaigns you want to govern together. 3. Start from a recipe rather than a blank rule. See Targeting Rules and Campaign Rules. 4. Check Last run tomorrow, then check the Change log the day after. Two small checks that turn a rule you hope is working into one you know is. Before you automate anything, it is worth ten minutes on Guardrails to Set Before You Automate Anything — the mistakes are all avoidable and all annoying. Related - Dry-Run Preview: Seeing What a Rule Would Change — the row-menu action worth knowing. - Scheduling: Last Run, Next Run and Run History — last run, next run, history.

Targeting Rules: Adjusting Bids and Pausing Targets

A Targeting Rule adjusts bids or pauses keywords and product targets based on performance. It is the workhorse of the rule engine, because bids are where most Amazon advertising money is won or lost. Nine ready-made recipes come with it. Each is a real rule you expand, review and apply — not a template you have to finish. Watch the walkthrough Prefer to watch? Seventy-five seconds on the nine recipes and how they group. Two actions The Targeting Rule chooser, with its recipes Every targeting rule does one of two things: Bid — raise or lower the bid by a percentage. Pause targeting — stop the keyword or product target entirely. The screen shows the shape a rule takes: Every day at 09:00 — if ACOS > 40% and clicks ≥ 10, lower the bid 15%. Read that carefully, because every recipe below is a variation on it: a schedule, a condition, a threshold that proves the condition, and an action. The clicks part is the one people skip. “ACoS above 40%” on a target with three clicks is noise — three clicks cannot tell you anything about ACoS. The clicks ≥ 10 is what stops the rule acting on randomness. The nine recipes Start here Hit my Target ACOS — the professional playbook in one number. Scales each bid by how far its actual ACoS sits from your target, trims proven non-converters, and scales what runs under target. If you only ever use one rule, use this one. You supply a single number — your target ACoS — and it does the proportional work in both directions. Bid autopilot (scale + trim) — a hands-off bid manager in one rule. Raises efficient winners, eases off high-ACoS targets, holds the rest. Similar territory, less dependent on you having a defensible target number. Cutting waste Cut wasted ad spend — trims bids on targets that have taken real clicks but still have not produced an order. Rein in high ACOS — steps bids down in tiers: hard when ACoS is far over target, gently when it is only slightly over. The tiering matters. A flat “cut 20% if over target” treats 31% and 90% the same, and they are not the same problem. Trim low-relevance keywords — eases bids on targets racking up impressions but almost no clicks. The ad is not resonating there. Pause dead keywords — pauses targets that have spent enough clicks to prove they will not convert. The classic 25-click cutoff. Scaling what works Boost profitable winners — raises bids on targets already converting below your ACoS target, with a couple of orders to build on. Rescue impression-starved winners — pushes bids up on targets that convert well but barely get shown. Buys them visibility. This is the most under-used of the nine. A target converting brilliantly on forty impressions is not a small win, it is a capped one — and nothing in a normal report makes it stand out, because its totals are tiny. Reward high converters — nudges bids up on targets with a strong conversion rate so they win more of the auctions they are good at. Choosing between them | If you want to | Use | |---|---| | Manage everything from one target number | Hit my Target ACOS | | Stop obvious bleeding, nothing else | Cut wasted ad spend or Pause dead keywords | | Respond proportionally to overspend | Rein in high ACOS | | Grow what is already working | Boost profitable winners | | Find capped winners | Rescue impression-starved winners | | Set it and leave it | Bid autopilot | Do not run overlapping recipes on the same group. Two rules that both adjust bids on the same targets will fight, and the Change log will show you a bid moving up and down on alternate days. Pick one, or scope them to different groups. Building one from scratch Start blank Targeting Rule gives you the conditions without a preset. Worth it when your logic is genuinely yours — a margin threshold nobody else shares, or a seasonal rule. Two settings do most of the work, and neither is obvious: Look-back window — how much history the rule judges on. Short windows react fast and chase noise; long windows are stable and slow. 14D is a sensible default for bids, because it clears the Sponsored Products attribution window with room to spare. Adjustment frequency — how often it acts. 1D is once a day. More often is rarely better, because each change needs time to produce data before the next judgement. That is what 14D LB — 1D Adjust in a rule name means, and why it belongs in the name. Before you switch one on Read Guardrails to Set Before You Automate Anything, then check The Change Log the day after your first run. A rule that has done something visible and sensible on day one is a rule you can leave alone. Related - Campaign Rules: Adjusting Budgets and Pausing Campaigns — the other rule type. - Building a Rule from Scratch: Conditions and Thresholds — when no recipe fits. - Look-back Windows and Adjustment Frequency — how much evidence each run sees.

Campaign Rules: Adjusting Budgets and Pausing Campaigns

A Campaign Rule adjusts budgets or pauses whole campaigns based on performance. Where a Targeting Rule tunes individual bids, this one moves money between campaigns — or stops one outright. Six recipes come with it, and one of them does something none of the others do: it moves budget from losers to winners in a single rule. Watch the walkthrough Prefer to watch? Sixty-three seconds on the six recipes, and the one that finds capped campaigns. Two actions The Campaign Rule chooser, with its recipes Budget — grow or cut the daily budget by a percentage. Pause campaign — stop the whole campaign. The example on the screen shows the shape: Every day at 09:00 — if ROAS > 3 over the last 30 days, grow the budget 10%. Note it uses ROAS rather than ACoS. Both appear across these recipes, and they are the same relationship from opposite ends — ROAS above 3 is ACoS below 33%. Use whichever your team thinks in, but be consistent inside one account or the rules become hard to read. The six recipes Budget autopilot (scale + trim) — a hands-off budget manager. Feeds campaigns returning strong ROAS, starves the ones bleeding at high ACoS. Defend margins (tiered budget) — pulls budget from campaigns bleeding at high ACoS and pushes it toward efficient scalers, in one rule. That second one is the interesting one. Most budget rules only push in one direction, so you end up running a “grow winners” rule and a “cut losers” rule and hoping they balance. This does both sides in a single decision, which is what an experienced manager actually does when budget is finite. Growing Uncap profitable campaigns — gives budget room to small, highly profitable campaigns that may be capping out too early. Worth naming what this catches. A campaign hitting its daily budget by lunchtime is invisible in every performance report, because its numbers look fine — it is simply not spending what it could. This is the rule that finds them. Scale winning campaigns — more budget to campaigns returning strong ROAS on real order volume. The “on real order volume” is the guard. Scaling a campaign with three orders and a flattering ROAS is how you turn a fluke into a spend problem. Cutting Trim over-spenders — cuts budget on campaigns spending real money whose ACoS has drifted past your ceiling. Pause bleeding campaigns — pauses campaigns that have spent heavily across many clicks with zero sales. Pause is the only irreversible-feeling action here, so it is the one to be most careful with. A campaign paused by a rule stays paused until somebody notices — and a paused campaign disappears from the default view of every table, because tables show enabled entities by default. Choosing between them | If you want to | Use | |---|---| | One rule that manages budget both ways | Budget autopilot or Defend margins | | Find campaigns capping out too early | Uncap profitable campaigns | | Grow proven performers | Scale winning campaigns | | Rein in drift | Trim over-spenders | | Stop clear waste | Pause bleeding campaigns | Campaign rules and targeting rules do different jobs Run both. They are not alternatives: | | Targeting Rule | Campaign Rule | |---|---|---| | Acts on | keywords and product targets | whole campaigns | | Changes | bids | budgets | | Answers | am I paying the right price? | is this campaign worth funding? | A campaign can be efficient at the keyword level and still be the wrong place for your money — and no amount of bid tuning fixes that. Equally, a well-funded campaign full of bad keywords just spends the budget faster. Where they can conflict is on pausing. A targeting rule pausing every keyword in a campaign leaves an active campaign with nothing to run. Check the Change log after your first week of running both. The settings that matter Look-back window — longer than for bids. The example uses 30 days, and that is reasonable: budget is a bigger, slower decision than a bid, and you want it made on settled data. Adjustment frequency — once a day is plenty. A budget changed more often than the data can respond is just noise with consequences. Before you switch one on Budget rules move real money faster than bid rules do, so read Guardrails to Set Before You Automate Anything first, and check The Change Log after the first run. Related - Targeting Rules: Adjusting Bids and Pausing Targets — the other rule type. - Prepare for Prime Day: Budget Rules and Inventory Cover — budget rules under load.

The Change Log: Auditing What a Rule Changed

The Change log records every change automation has made on this account, newest first. It is the feature that makes the rest of the rule engine safe to use, because it turns automation from something that happens to your account into something you can check. Watch the walkthrough Prefer to watch? Seventy-three seconds on reading a row, and the check to run the day after. Finding it Automations → Change log, top right of the Rules screen. Back to Rules returns. The Change log, one row per change The header names its scope — Change log — All campaigns — with a date range control beside it. Default is the last week. Reading a row Each row is one change, to one thing, at one moment. | Column | What it gives you | |---|---| | Date | when, to the minute | | Rule | which rule did it — a link to the rule | | Run | which execution — a link, e.g. #259 | | Campaign | where it happened | | Target | the keyword or product target affected | | Type | Keyword, or product target | | Ad type | SP, SB or SD | | Action | what was done — Set Bid, a pause, a budget change | The Run number is the column people miss. Every change from a single execution shares one run number, so clicking it shows you everything that rule did in that pass rather than one row of it. That is the difference between “this bid changed” and “this rule touched 40 keywords this morning, and here they are.” The three questions it answers “Why did this bid change?” Search the target. The row names the rule and the run. “What did my rules do last night?” Set the range to yesterday. If the list is empty, nothing ran — which is itself worth knowing. “Is this rule doing anything?” Filter to it. A rule that is ACTIVE with a recent Last run but no change-log rows is evaluating and deciding not to act. That is usually correct behaviour, not a fault — but it is also how a badly-scoped rule looks, so it is worth a glance at the conditions. The check worth doing The day after you switch on a new rule, open the Change log and read what it actually did. That single habit is the whole safety story. Rules are easy to reason about wrongly — a threshold that seemed obviously safe turns out to catch forty targets you did not have in mind. You find that out in one minute here, or in a month on your spend chart. Three things to look for: Volume. Did it change five things or five hundred? A rule touching far more than you expected is scoped wider than you meant. Direction. Are the changes going the way you intended? A “trim waste” rule raising bids means a condition is inverted. Repetition. Is the same target changing every day? That usually means two rules are fighting over it, or the look-back window is too short and the rule is chasing noise. See Targeting Rules. Exporting it Export produces a file of the current view, respecting your filters and date range. Two occasions where that is genuinely useful: explaining a spend change to somebody who does not use TrackIQ, and keeping a record before a big change so you can compare before and after. What it does not cover The Change log records what automation did. Changes you make by hand, or in Amazon's own console, are not rule actions and will not appear here. So a bid that changed with no matching row was changed by a person or by Amazon — which is a useful answer in itself, because it tells you to stop looking at your rules. Related - The Automations Screen — where rules and groups live. - Targeting Rules and Campaign Rules — what can appear in this log. - Guardrails to Set Before You Automate Anything — how to need this log less.

Guardrails to Set Before You Automate Anything

Automation does not fail loudly. A badly-scoped rule does not error — it works exactly as written, on far more of your account than you meant, every day, until somebody looks. None of what follows is difficult. All of it is easier before the first run than after. Watch the walkthrough Prefer to watch? Sixty-seven seconds on scope, proof, and the mistake that catches everyone. 1. Know what is already running If rules exist on the account, read the Change log before adding anything. You are not designing in an empty room, and the most common cause of a bid bouncing up and down every day is two rules that were each individually sensible. See The Change Log: Auditing What a Rule Changed. 2. Scope before you act Rule groups, each with a campaign count Create a rule group and check its campaign count before pointing a rule at it. That number is your blast radius, and it is right there in the table. Start narrow. One product line, or one group of campaigns you understand well. A rule that works on 6 campaigns will work on 31; a rule that misfires on 31 costs five times as much to notice and undo. 3. Require proof before acting The single most valuable habit: every condition needs a volume threshold attached. if ACOS > 40% and clicks ≥ 10, lower the bid 15% Without the second clause, that rule acts on targets with two clicks — where ACoS is not a measurement, it is a coin toss. The recipes ship with these thresholds for exactly this reason. If you build from blank, put them in yourself. The same applies to scaling. “High ROAS” on three orders is a fluke, and funding it is how a rule turns randomness into spend. 4. Set the look-back window long enough A look-back shorter than the attribution window makes a rule judge sales that have not been credited yet. | Ad type | Attribution | Minimum sensible look-back | |---|---|---| | Sponsored Products | 7 days | 14 days | | Sponsored Brands / Display | 14 days | 21 days or more | A 7-day look-back on Sponsored Brands sees roughly half the sales that target will eventually be credited with, concludes it is failing, and cuts the bid. The rule is not wrong; the window is. See Why SP, SB and SD Numbers Don't Add Up. 5. Do not act more often than the data can answer 1D Adjust — once a day — is right for almost everything. A bid changed this morning has not yet produced the clicks that would justify changing it again tonight. Frequent adjustment feels responsive and behaves like noise. 6. Change one thing at a time Do not switch on five rules on Monday. When spend moves on Friday you will not know which one did it, and you will end up turning all five off. One rule, one week, one look at the Change log. Then the next. 7. Be careful with pause Pause is the action that keeps acting after you stop paying attention. A paused campaign or keyword vanishes from the default view of every table, because tables show enabled entities by default. So the thing your rule paused is now the thing you cannot see. See My Ad Data Is Missing or Looks Wrong. Set pause thresholds high enough to be unambiguous — the classic 25-click cutoff exists because that is roughly where “no orders” stops being bad luck. 8. Decide what each campaign is for, first A rule enforces one definition of good across everything in its group. But campaigns do different jobs: - Defending a keyword you own — a higher ACoS is the price of holding ground. - Launching — ACoS is expected to be poor; you are buying rank and history. - Harvesting — here the target genuinely applies. Put those in different rule groups. A single target ACoS across all three will strangle your launches and under-defend your best keywords — and it will look like it is working, because the average will improve. 9. Name rules so the settings are visible Northwind Goods — MGO 925 — 14D LB — 1D Adjust Look-back and frequency are not columns in the rules table, and they are exactly what makes two similar rules behave differently. Put them in the name from the start. 10. Check on the days that matter Day one after the first run — open the Change log. Volume, direction, repetition. End of week one — is spend where you expected? After anything unusual — a stockout, a price change, a promotion, Prime Day. Rules keep running through events they know nothing about, and a rule that scales winners will happily pour budget into a product that is about to run out. See Inventory Forecasting. The one that catches everyone A rule does not know your stock. A product about to go out of stock is often a product performing well, which is precisely what a scaling rule funds. Pairing a stock alert with a pause rule on low-cover products is usually the highest-value automation in the whole account, because it saves money on a day you are already losing sales. Related - Dry-Run Preview: Seeing What a Rule Would Change — the other thing to do before enabling. - A Rule Didn't Run — when nothing happens. - The Bleeder Reports — the thresholds to trust before you let a rule act on them.

Rule Groups: Applying One Rule Across Many Campaigns

A rule group is a named set of campaigns. Rules point at groups, not at individual campaigns — which is what makes automation maintainable instead of a list of near-identical rules. It is also your safety control, because a group's campaign count is the blast radius of every rule attached to it. Watch the walkthrough Prefer to watch? Sixty-eight seconds on blast radius, and grouping by intent. The screen The Rule Groups tab, with a campaign count per group Automations → Rule Groups. One row per group: | Column | | |---|---| | Name | what it covers | | Description | why it exists — empty by default | | Campaigns | how many are in it | | Created | when | + New Group creates one. Each row has a menu. Why groups instead of campaigns One rule pointed at a group of 31 campaigns is one thing to maintain. Thirty-one rules is thirty-one things to keep in step, and they will drift. Groups also mean a new campaign inherits your automation by being added to the right group, rather than by someone remembering to build it a rule. Group by intent, not by convenience This is the decision that determines whether your automation helps or quietly harms, and it is easy to get wrong because the wrong way looks tidier. A rule enforces one definition of good across everything in its group. But campaigns do different jobs: | Job | What good looks like | |---|---| | Defending a keyword you own | a higher ACoS is the price of holding ground | | Launching | ACoS is expected to be poor — you are buying rank | | Harvesting | the efficiency target genuinely applies | Put all three in one group under a single target ACoS and the rule will strangle your launches and under-defend your best keywords — while the group average improves, which is what makes it hard to spot. Group by what the campaigns are for. The naming in a well-run account shows this: separate groups for a product line, and separate ones again for its Single KW / Must Win campaigns, which are defended rather than optimised. Sizing a group Start small. A rule that behaves on 6 campaigns will behave on 31. A rule that misfires on 31 costs five times as much to notice and undo. Check the count before attaching a rule. It is right there in the table, and it is the number that tells you how much of your account a mistake would reach. Watch for a group that keeps growing. A group that started as “our hero product” and now holds 40 campaigns has probably stopped being one intent. Use the description field It is empty by default, and it is the only place to record why a group exists. “Defended brand terms — higher ACoS is intentional. Do not attach efficiency rules.” That sentence is worth more than it looks. Six months on, or when somebody inherits the account, the group name alone will not stop a well-meaning colleague attaching a target-ACoS rule to campaigns that are supposed to run hot. One group, one rule — usually Two rules that both adjust bids on the same group will fight, and the Change Log will show a bid moving up on Monday and down on Tuesday. If you want both scaling and trimming, prefer a recipe that does both in one decision — Hit my Target ACOS for bids, or Defend margins for budgets — over two opposing rules. See Targeting Rules and Campaign Rules. Running one targeting rule and one campaign rule on the same group is fine. They act on different things. Checking it worked After attaching a rule to a group, read the Change Log the next day and check the volume. A rule touching far more than the group's campaign count suggests is a sign the group is wider than you thought. See The Change Log: Auditing What a Rule Changed and Guardrails to Set Before You Automate Anything. Related - The Automations Screen: Rules, Rule Groups and the Change Log — where groups are managed. - Set a Target ACoS Across a Whole Portfolio — the playbook that uses them.

Building a Rule from Scratch: Conditions and Thresholds

The quick-start recipes cover the common cases. When none of them fits — because your margin maths is unusual, or you want several behaviours in one rule — you build the logic yourself. The builder is a branch list, not a single condition. Understanding that one fact is most of understanding the screen. Watch the walkthrough Prefer to watch? Eighty-six seconds on branches, order, and where thresholds go wrong. Start blank + Create Rule opens the chooser. Pick Targeting or Campaign, then scroll past the recipes to Start blank. The rule chooser, with recipes above and Start blank below The two live rule types differ in what they act on: | | Targeting Rule | Campaign Rule | |---|---|---| | Acts on | keywords & product targets | whole campaigns | | Can do | Bid · Pause targeting | Budget · Pause campaign | | Example given | if ACOS > 40% and clicks ≥ 10, lower the bid 15% | if ROAS > 3 over the last 30 days, grow the budget 10% | Everything below applies to both. A rule is a list of branches, walked in order IF, then ELSE IF — each with its own conditions and action Section 4 of the form says it plainly: Branches are walked in order. Only the first matching branch fires per entity. This is the single most important behaviour in the builder. Each keyword, target or campaign is tested against IF · 1 first. If it matches, that branch's action fires and the entity is done — no later branch is evaluated for it. So branch order is not cosmetic. It is the logic. Put the most specific branch first. A branch that pauses dead targets must sit above a branch that raises bids on low-click targets, or the bid-raise will catch them first and you will spend more on things that never convert. Put the catch-all last. The general "nudge everything toward target" branch belongs at the bottom, where it picks up whatever the specific branches did not claim. The ↑ ↓ controls on each branch header reorder them, and the effect on outcomes is immediate. Building a condition Each branch has a WHEN side and a THEN side. On the WHEN side, choose how conditions combine: - ALL conditions (AND) — every condition must be true. Use this for the specific branches. - ANY condition (OR) — one is enough. Use this when several different symptoms deserve the same treatment. Then add conditions, each a metric · operator · value triple: Clicks · Greater than · 50 Orders · Equal to · 0 Together, with AND, that is the classic definition of dead weight: enough traffic to have proved itself, and nothing to show for it. Operators include Greater than, Greater than or equal, Less than, Less than or equal and Equal to. Money metrics show a $ marker so you know the unit you are typing in. Choosing thresholds This is where rules go wrong, and the failure is almost always the same one: a threshold low enough to fire on noise. Require enough evidence before acting. A target with 4 clicks and no orders has not failed — it has barely been tested. Conversion rates in the low single digits mean 25–50 clicks is the honest floor for concluding "this does not convert". That is why the built-in recipe uses clicks ≥ 25 rather than 5. Prefer spend to clicks when click values differ wildly. Spend ≥ $50 and Orders = 0 is more consistent across a mixed catalog than a click count, because a $0.20 click and a $5.00 click are not the same evidence. Set the threshold where you would act by hand. If you would not personally pause a target at 25 clicks and no orders, do not let the rule do it either. The rule is not braver than you are; it is only faster. Write down the reason. Use the Description field. "25 clicks is roughly 3× our typical order rate" is what stops a future you from halving it on a hunch. Choosing the action The THEN side offers a percentage nudge, a pause, or a goal-seeking bid. Increase / decrease bid by % moves the bid a fixed step. Predictable, and slow by design. Set bid to hit Target ACOS is different, and better for anything mature: The goal-seeking action, with its formula shown new bid = current bid × (Target ACOS ÷ actual ACOS) It scales the bid toward the goal in one move rather than nudging by a fixed percentage — so a target at 100% ACoS against a 50% goal halves, while one at 55% barely moves. The size of the correction matches the size of the problem. The Target ACOS itself is set once, under Guardrails, and every branch that uses this action reads it. Guardrails still cap the change, so the formula can never move a bid further than your max-change-per-run allows. A worked shape A four-branch rule that covers most of a mature account: | # | When | Then | |---|---|---| | IF 1 | Clicks > 50 and Orders = 0 | Pause targeting | | ELSE IF 2 | Spend ≥ $50 and Orders = 0 | Pause targeting | | ELSE IF 3 | Orders > 1 | Set bid to hit Target ACOS | | ELSE IF 4 | Clicks < 50 or Orders ≤ 1 | Increase bid by 15% | Read it as a decision list. Kill what has proved it does not work, on two different measures of "proved". Steer what has proved it does. Give everything else a little more room, because it has not been tested yet. Branch 4 sits last deliberately — it is the widest condition in the rule, and anywhere higher it would swallow the entities the branches above it are meant to catch. Before you save Read the plain-English summary at the top of the form. It renders your whole rule as a sentence, and reading it aloud catches inverted operators faster than re-reading the fields. Run a dry run. The rule's ⋮ menu offers Dry-run preview, which computes every change and applies none of them. See Dry-Run Preview: Seeing What a Rule Would Change. Related - Look-back Windows and Adjustment Frequency — the two settings that decide how much evidence each run sees. - Guardrails to Set Before You Automate Anything — the caps that bound every branch. - Dry-Run Preview — check the logic before it touches anything. - Targeting Rules: Adjusting Bids and Pausing Targets — the recipes this replaces.

Look-back Windows and Adjustment Frequency

Two settings decide how much evidence a rule sees and how often it acts on it. They sit next to each other under Cadence & Guardrails, they interact, and getting the pair wrong is the most common reason a well-written rule behaves badly. They are important enough that most accounts put them in the rule's own name — 14D LB · 1D Adjust means a fourteen-day look-back adjusting daily. Watch the walkthrough Prefer to watch? Eighty-eight seconds on the window, the attribution lag, and why overlap compounds. The look-back window Look-back window, attribution lag, and the runs they produce Look-back window (days) is how far back each run reads. Metrics aggregated over the last N days. It is a trade between evidence and freshness: | Window | Sees | Costs you | |---|---|---| | 7 days | recent behaviour, reacts fast | thin data; weekday/weekend skew | | 14 days | two full weeks, both weekends | a fortnight to notice a change | | 30 days | stable, well-evidenced | very slow to react; averages away a real shift | 14 days is the sensible default for bid rules, and it is what the demo account uses throughout. It contains two complete weekly cycles, which matters more than it sounds: a 7-day window that happens to start on a Wednesday weights the weekend differently from one that starts on a Monday, and your rule inherits that wobble. Go to 30 days for low-traffic targets where 14 days produces single-digit click counts. Go to 7 days only when you are actively managing a launch and want the rule to keep up. Ignore most recent — the setting people miss Ignore most recent (attribution lag) drops the freshest N days from the window. The helper text says why: Fresh days under-report sales while Amazon attribution settles. This is not a cosmetic option. Amazon attributes a sale to the click that led to it, and that click may have happened up to 7 days earlier for Sponsored Products, or 14 for Sponsored Brands, Sponsored Display and DSP. Yesterday's spend is complete; yesterday's sales are not. A rule reading right up to yesterday therefore sees the newest days as spend with no orders attached — and a rule whose job is to pause things with no orders will happily pause a target that is converting perfectly well. It just has not been credited yet. Set this to at least 1 day. For rules that pause on zero orders, 2 days is safer. The cost is a day of latency; the alternative is a rule that systematically punishes recency. The Next 3 runs panel shows the resolved effect, so you never have to work it out: Each run reads data from Aug 12 to Aug 26 (last 14d, ignoring the 1 freshest) Adjustment frequency Recurrence — Daily, Weekly or Monthly — with Repeat every N, plus a Time and an optional Start date. Four presets cover the usual choices: Daily · 9 AM, Mon–Fri · 9 AM, Weekly · Mon 9 AM, Monthly · 1st 9 AM. Times run in your marketplace's timezone, not yours. The preview is shown in your local time, so the two can look different by design — trust the label, not the clock on your wall. How the two interact This is the part worth getting right, and it has a simple rule of thumb: A daily rule on a 14-day window re-reads 13 days it has already acted on. Each run sees almost exactly what the last run saw, plus one new day. So the same evidence drives an adjustment again, and again, and again. Over a fortnight a 15% daily nudge compounds into something far larger than 15% — not because the data changed, but because you kept counting it. That is why Max change per run exists, and why it should be modest when adjustment is frequent: | Frequency | Window | Max change per run | |---|---|---| | Daily | 14 days | 10–15% | | Weekly | 14 days | 20–25% | | Weekly | 30 days | 25–30% | The principle: the more the windows overlap, the smaller each step should be. A weekly rule on a 7-day window sees fresh data every time and can afford a bigger move; a daily rule on a 30-day window is mostly re-reacting to old news and should barely move at all. Pausing is the exception. A pause is not cumulative — it happens once — so pause branches are safe to run daily as long as their thresholds require real evidence. See Building a Rule from Scratch. Picking a pair Bid rules on a mature account — 14-day window, ignore 1 day, daily, 10–15% cap. Steady, and it will not chase noise. Budget rules — 14 or 30 days, weekly. Budgets move real money in larger steps and rarely need daily attention. Launches — 7-day window, daily. You are deliberately trading stability for responsiveness, and you should be watching it. Low-traffic long tail — 30-day window, weekly. Anything faster fires on noise. What not to do Do not run daily on a 30-day window with a large cap. Every run re-reacts to the same month of data, and the changes compound on evidence that has not moved. Do not set the look-back shorter than the conversion cycle. If shoppers typically take five days to buy, a 7-day window with 1 day ignored leaves six days of signal — barely one cycle. Do not change both settings at once. When a rule misbehaves, move one, watch a week, then move the other. See Scheduling: Last Run, Next Run and Run History for reading what actually happened. Related - Building a Rule from Scratch — the branches these settings feed. - Guardrails to Set Before You Automate Anything — the change cap and bid bounds. - Scheduling: Last Run, Next Run and Run History — confirming when a rule ran and what it did. - Why SP, SB and SD Numbers Don't Add Up — the attribution behaviour behind the lag setting.

Scheduling: Last Run, Next Run and Run History

An automation you cannot audit is an automation you cannot trust. TrackIQ records every run of every rule — when it fired, what it matched, what it changed, and whether the change was applied — and keeps it as a browsable history. This is the screen to open when a bid is not what you expected, or when someone asks what the rules have been doing. Watch the walkthrough Prefer to watch? Eighty-five seconds on matched, changed, applied — and the rule that changes nothing. Last Run and Next Run, on the rules list Last Run, Next Run, Run History and Changed on the rules table Scroll the Rules table right and four columns answer the day-to-day questions without opening anything: | Column | Answers | |---|---| | Last Run | did it fire, and when? | | Next Run | when will it fire again? | | Run History | the icon that opens the full log | | Changed | how many entities the last run touched | Changed is the column to scan. Across a set of rules on the same schedule you will see numbers like 101, 13, 521, 8, 5, 162 — and the outliers are the story: - A rule changing hundreds of entities every day is either managing a very large scope or has thresholds loose enough to catch everything. Check which. - A rule changing nothing, run after run, is not protecting you. Its conditions never match, and it is giving you false confidence. - A rule whose Changed count jumps is reacting to something that moved — a price change, a stock-out, a competitor. That jump is a signal about the account, not just the rule. Last Run not matching Next Run's cadence is the first thing to check when a rule seems inactive. A rule showing a Last Run several days stale on a daily schedule did not run, and that is a different problem from a rule that ran and changed nothing. The run history The Run History icon opens every run that rule has ever made. Every run, with its trigger, and what it matched, changed and applied Every run this rule has made. Click View to open a run and see exactly what it changed and why. | Column | What it tells you | |---|---| | Run | the run number, ascending over the rule's life | | When | date and time it fired | | Status | Completed, or otherwise | | Trigger | Scheduled · Auto Apply or Manual · Dry Run | | Matched | entities in scope that the rule evaluated | | Changed | entities a branch decided to act on | | Applied | changes actually written to Amazon | Reading the three counts The relationship between Matched, Changed and Applied is where the useful information lives. Matched is your scope. It should be roughly stable run to run — 266, 267, 268, 269. A drift means campaigns are entering or leaving the rule group. A sharp fall means something in scope was paused or removed. Changed ÷ Matched is how aggressive the rule is. 133 of 266 means the rule is touching half of everything it looks at, every single day. On a daily schedule that is usually a sign the thresholds are too loose, or that the change cap is doing all the real work of keeping it safe. Applied should equal Changed on a scheduled run. When it does not, changes were computed but not written — check Status, and check whether the Amazon connection is healthy. See Checking When Your Data Last Synced. Applied is blank on a dry run, shown as a dash. That is the definition of a dry run rather than a fault. Trigger tells you who did it The Trigger column separates the rule's own schedule from human intervention: - Scheduled · Auto Apply — the rule fired on its cadence and wrote its changes. - Manual · Dry Run — somebody previewed it. Nothing was written. A Run Now from the rule's ⋮ menu also appears here, which matters during an incident: if a bid changed at an odd hour, the run history says whether the schedule did it or a person did. Opening a run View opens the run and lists every entity it touched — campaign, ad group, target, which branch fired, and the value before and after. That branch number is the part worth using. It ties the change back to a specific rule of yours, so "why did this bid drop?" resolves to "branch 3 matched, because orders were above 1 and ACoS was over target" rather than a guess. See Building a Rule from Scratch for how branch order decides which one wins. The audit habit worth having Weekly: scan the Changed column across all rules. Anything at zero or in the hundreds deserves a look. After any threshold edit: open the next run and check Changed moved the way you intended. This is the fastest feedback loop the product offers. When a number looks wrong: open the run covering that date before assuming the rule is broken. Most surprises turn out to be a branch you forgot was there, firing exactly as written. Before pausing a rule: check what it has been changing. A rule you no longer remember writing may be the only thing holding an account's ACoS down. Related - The Change Log: Auditing What a Rule Changed — the account-wide view across every rule. - Dry-Run Preview — producing a run that changes nothing. - Look-back Windows and Adjustment Frequency — what sets the cadence you are reading here. - A Rule Didn't Run — when Last Run is stale.

Dry-Run Preview: Seeing What a Rule Would Change

A rule that reads well can still be wrong. An operator inverted, a branch in the wrong order, a threshold an order of magnitude out — none of these look like mistakes on the form, and all of them look obvious the moment you see what the rule would actually do. Dry-run preview runs the rule for real against live data, computes every change, and writes none of them. Watch the walkthrough Prefer to watch? Eighty-three seconds on running a rule for real and applying none of it. Running one Open the ⋮ menu on any rule and choose Dry-run preview. It takes a few seconds and opens the result directly. There is nothing to undo and nothing to clean up. A dry run touches Amazon not at all — it is safe on a live rule managing a live account, at any time of day. Reading the result A dry run: 263 matched, 101 changed, 0 applied The header carries the DRY badge and four counters: | Counter | Meaning | |---|---| | Matched | entities in scope the rule evaluated | | Changed | entities a branch decided to act on | | Applied | zero, always — this is what makes it a dry run | | Failed | entities the rule could not process | 263 matched, 101 changed, 0 applied reads as: the rule looked at 263 keywords and targets, decided to act on 101 of them, and did nothing. Those 101 rows are the preview. The row detail is the point Every changed entity is listed with its campaign, ad group, target (with its match type), whether it is a Keyword or a Target, the branch that fired, and the previous value beside the new one. The Branch column is what makes this a debugging tool rather than a summary. It tells you which of your own rules claimed each entity — and because branches are walked in order and only the first match fires, that number is the answer to almost every "why did this happen?" 101 rows of changes, none of them applied What to look for Is the Changed count plausible? Against 263 matched, a hundred changes is aggressive for a daily rule. Against 263 matched, zero changes means your thresholds never fire and the rule is decoration. Both are worth knowing before the rule runs on its own. Is the branch distribution what you expected? If every row says branch 4, branches 1 to 3 are unreachable — almost always because a broader branch sits above narrower ones and is claiming everything. Reorder with the ↑ ↓ controls and preview again. Are the previous values sensible? A pause branch listing targets whose bids are $5.39 — your top performers — is the moment to stop and re-read the condition, not after it has run. Is anything in scope that should not be? The campaign and ad group columns show exactly what the rule group resolved to. Branded campaigns turning up in a rule you wrote for generic terms is a scope problem, not a logic one. Sort and filter. The preview is a normal TrackIQ table — Search, Filters, Manage Columns and Export all work. Exporting a dry run gives you the whole change set as a spreadsheet, which is the easiest way to have somebody else check your reasoning. When to run one Before the first scheduled run of any new rule. Always. This is the cheapest safety step in the product. After changing a threshold. Preview, compare the Changed count to the last one, and confirm the change moved things the way you intended. After reordering branches. Order changes outcomes, and the preview is the only place you see that before it happens. Before turning a rule loose on a larger scope. Attaching a second rule group can multiply the entity count. Preview first. When someone asks what a rule does. A dry run answers with 101 concrete rows rather than a description. It is a preview, not a promise A dry run reads the same data the scheduled run will, but it reads it now. By tomorrow morning the look-back window has moved by a day and the numbers will differ slightly. The counts are therefore indicative; the logic is what you are checking. If branch order and scope are right today, they will be right tomorrow. Note too that a dry run appears in the rule's run history, tagged Manual · Dry Run with a dash in the Applied column. That is deliberate — it keeps the audit trail complete, and it lets you compare a preview against the scheduled run that followed it. See Scheduling: Last Run, Next Run and Run History. Related - Building a Rule from Scratch — the branches this preview exercises. - Guardrails to Set Before You Automate Anything — the caps that bound what a run can do. - Scheduling: Last Run, Next Run and Run History — where dry runs are recorded. - The Change Log — what actually got applied, account-wide.

Rule Types Coming Soon: Placement, Ad Group, Audience and Harvest

The rule chooser lists eight rule types. Two are live — Targeting and Campaign. The other six carry a COMING SOON badge and a dot in the sidebar, and clicking one shows what it will do rather than letting you build it. They are listed here because knowing what is coming changes how you structure things now, and because a visible-but-unavailable option is worth explaining rather than leaving as a puzzle. Watch the walkthrough Prefer to watch? Seventy-eight seconds on the two live types, the six on the roadmap, and what to do meanwhile. What is live today The chooser — two live types, six on the roadmap | Type | Acts on | Actions | |---|---|---| | Targeting Rule | keywords & product targets | Bid · Pause targeting | | Campaign Rule | whole campaigns | Budget · Pause campaign | Between them they cover the two levers that matter most: what you pay per click, and how much a campaign may spend in a day. See Targeting Rules and Campaign Rules. What is on the roadmap Selecting any of the six shows its description and the note "This rule type is on the roadmap — it will appear here as soon as it ships." A coming-soon type, with its description and planned actions Under Advertising: | Type | What it will do | Planned actions | |---|---|---| | Placement Rule | Adjust placement bid modifiers (top-of-search, product pages) by performance. | Placement | | Adgroup Rule | Adjust default bids or pause entire ad groups. | Default bid · Pause adgroups | | Audience Rule | Manage audience bid adjustments on campaigns. | Audience | Under Harvest: | Type | What it will do | Planned actions | |---|---|---| | Harvest Keywords Rule | Promote converting search terms into exact keywords automatically. | Add keywords | | Harvest Product Targetings Rule | Promote converting ASINs into product targets automatically. | Add PATs | | Negative Targeting Rule | Add negative keywords/targets for search terms that waste spend. | Add negative | No dates are given, here or in the product. The badge is the only commitment. Why the Harvest group is the significant one The three Advertising types extend automation to levers you already manage by hand. The Harvest group does something categorically different: today every rule adjusts things that already exist. A harvest rule would create them. That is the loop most accounts run manually every week: 1. Read the search-terms report. 2. Find terms that converted but are not bid on as keywords. 3. Add them as exact-match keywords in a dedicated campaign. 4. Find terms that spent and never converted. 5. Add them as negatives. Steps 2–3 are Harvest Keywords. Steps 4–5 are Negative Targeting. The ASIN equivalent is Harvest Product Targetings. Together they would close the loop between discovery and structure — the part of Amazon advertising that is still mostly hand work. What to do in the meantime Do the harvest manually, on a schedule. The data is all there. Search Terms with the Aggregated toggle finds converting terms you are not bidding on; SQP Recommended Actions flags the same thing with a money figure attached. Weekly is enough for most accounts. See Find converting search queries you aren't bidding on. Use campaign structure instead of placement rules. Placement modifiers are set in the Amazon console. Until a rule can manage them, the practical substitute is separating campaigns whose placement performance differs, so a Campaign Rule can act on them independently. Do not build workarounds you will have to unpick. A tangle of narrow campaigns created purely to stand in for ad-group rules is harder to dismantle later than it is to build now. Structure for the rules you will want. Rule groups are the unit every rule type will use, so groups you build today for Targeting rules will be reusable when the others ship. See Rule Groups. Watching for changes The chooser is the authoritative list. When a badge disappears, that type is live — there is no separate announcement inside the product, and the sidebar dot is the same signal. It is worth a look whenever you next open + Create Rule, rather than something to check on a schedule. Related - Targeting Rules: Adjusting Bids and Pausing Targets — live today. - Campaign Rules: Adjusting Budgets and Pausing Campaigns — live today. - Rule Groups — the scoping unit every future type will share. - Search Terms and Aggregated Search Terms — where manual harvesting starts.