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](https://kb.trackiq.com/kb-assets/kbvideo-dry-run-explainer-9164d6d0.mp4)

*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](/kb-assets/shot-b26-dry-view-651d68.png)

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](/kb-assets/shot-b26-dry-low-042649.png)

## **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**](https://kb.trackiq.com/hc/knowledge-base/articles/rule-scheduling-and-run-history).

## **Related**

- [**Building a Rule from Scratch**](https://kb.trackiq.com/hc/knowledge-base/articles/building-a-rule-from-scratch) — the branches this preview exercises.
- [**Guardrails to Set Before You Automate Anything**](https://kb.trackiq.com/hc/knowledge-base/articles/guardrails-before-you-automate) — the caps that bound what a run can do.
- [**Scheduling: Last Run, Next Run and Run History**](https://kb.trackiq.com/hc/knowledge-base/articles/rule-scheduling-and-run-history) — where dry runs are recorded.
- [**The Change Log**](https://kb.trackiq.com/hc/knowledge-base/articles/the-change-log) — what actually got applied, account-wide.