A judge that moves money every night is as dangerous as it is useful if you feed it broken data. The difference between serious automation and a time bomb lies in what it refuses to do. This lesson closes the module with the safety engineering: anomalies, currencies, limits and auditing the judge itself.
The data that fools you
| Anomaly | What it looks like | What it is | How you spot it |
|---|---|---|---|
| A one-day CPA at 20× | A campaign running wild | Today's expensive clicks whose conversions will land tomorrow (latency) | An isolated day, with no conversions yet, outside the latency window |
| Conversions at zero with normal clicks | A campaign that stopped working | Broken measurement | The action flagged "no recent conversions"; diagnosis |
| A one-day conversion spike | A brilliant campaign | A massive offline upload (a batch from the CRM), duplicates, spam | Conversions by conversion date vs click date; the batch in the upload sheet |
| Spend halved overnight | An impossible target | Budget changed by another user, an account spending limit, a disapproval | Change history; ad status |
| An actual CPA far from what you expected in a new account in the MCC | A bad campaign | A different currency (pesos, krona) with thresholds designed in euros | The account's currency |
Thresholds that scale with the currency
A real case from the Suite: an anti-anomaly threshold of "CPA > 1,000 = broken data" worked in euros and reset CPAs to zero in an account in Colombian pesos, where 1,000 COP is small change and a normal CPA runs into the tens of thousands. The lesson: every absolute threshold must scale with a currency factor (an approximate rate to EUR or USD), and any judge operating in an MCC with several currencies must read each account's currency when it starts its run. What applies to scripts applies to any sheet of rules.
"If it fails, it touches nothing" design
The engineering rules of a safe judge:
- Read everything before writing: if any piece of data is missing (conversions, IS, status), nothing is decided for that campaign.
- One transaction per campaign: a failed write on one campaign does not leave another half done; and the one that failed is left as it was.
- Verify afterwards: after writing, read back and confirm the value is what you expected; if not, raise a warning.
- TEST mode as the default state of every new campaign in the system: weeks of verdicts recorded without being applied.
- No decisions during learning, nor inside the waiting period after the last move.
- A record of everything, including what was not done and why ("anomaly", "no data", "waiting").
Absolute limits
Even if the matrix says otherwise:
- Budget per campaign between a minimum and a maximum set by the plan (see the planning lesson).
- Target between a floor and a ceiling per campaign (never a €1 tCPA off the back of a chain of steps).
- A maximum number of campaigns moved per night (if the judge wants to move 30 out of 30, something is wrong with the data, not with the campaigns).
- A maximum cumulative move per month (±40% on budget, for example).
They are firebreaks: they rarely fire; when they do, they prevent a disaster.
Other people's changes
The judge is not alone: other users, automated rules, applied recommendations and third-party scripts all touch the account. Before each decision, check the campaign's change history for the window: if there was an external budget or target change, the judge abstains and raises a warning. Two systems pulling the same lever is the recipe for eternal learning.
The monthly audit of the judge itself
Once a month, with the record in front of you:
- Accuracy: of the moves from 3-4 weeks ago, how many improved compliance? How many had to be reverted?
- False positives: anomalies flagged that turned out to be real, and decisions taken on data that later turned out to be broken.
- Bands and steps: too twitchy (lots of small moves) or too slow (long stretches of missing the target with no action)? Adjust.
- Limits: did any firebreak trip? Why?
- Coverage: chronically "no data" campaigns → restructure.
A judge that audits itself improves; one that does not accumulates biases.
💡 Ninja trick: most of these safeguards were born from real incidents in the Suite — the currency threshold, "if it fails, it touches nothing", the check after writing, abstaining in the face of external changes. None of them is elegant; all of them are cheap compared with a Monday of reset budgets. If you build your own judge, copy the list before you copy the matrix.
What you should remember
- Typical anomalies: latency, broken measurement, offline batches, external changes, currency.
- Thresholds that scale with the currency, and a judge that reads each account's currency.
- "If it fails, it touches nothing": read everything, one transaction per campaign, verification, TEST mode, a record of what was not done.
- Absolute limits as firebreaks; abstain when others have made changes; a monthly audit of the judge.
That is the end of Module 4. Module 5 moves on to ad fraud: site farms, apps, bots, IPs — and how an account defends itself.