Marketing Anomaly Detection: Catch Campaign Problems With an AI Agent on Rails

Who this is for: marketing-operations leads, email owners and data engineers. Choose a threshold or a statistical method per metric, write one pause rule with limits, and measure alert precision. The method is part of AI agent rails: one job, one data scope, one approver, one audit trail.

Before: the manual workflow

Manual campaign monitoring means dashboards that nobody watches at 2 a.m. An email bounce rate spike that starts overnight can run for hours before anyone opens a report. When an alert does exist, it says a number moved and rarely says what launched, what changed or whether the data is even fresh. So the first hour goes on working out whether the problem is real, and campaign anomaly detection exists to shorten that hour.

What rules do and what the model does

Statistics and fixed thresholds detect anomalies, and the model only explains them. A model's judgement never fires an alert or a pause. Hard limits set by someone else suit thresholds, while metrics with a rhythm suit statistical baselines.

Provider limits are published, so use them as ceilings for your own rule, and set a spam rate alert well before the first limit. The table was checked on 1 November 2026.

Three details change how you build on the SES figures. SES counts only hard bounces to non-verified domains, and only complaints from providers that send feedback. It measures over a "representative volume", not a fixed window, so you cannot recompute the rate from send statistics 2. Read the Reputation.BounceRate and Reputation.ComplaintRate metrics instead, and treat a single send's rate as an early signal, not the SES rate. One AWS page, on pausing a configuration set, still gives 10% and 0.5% as the review levels 4. The FAQ and the account-level page agree on 5% and 0.1% 23, so we use those.

The model adds context: what launched, what changed and which related metrics moved. It writes causes as hypotheses with evidence links.

After: the job on rails, step by step

The job runs on two separate paths, because explaining an alert and acting on one carry different risks.

Explanation path

1. Metrics flow to the detector, which checks data freshness first.
2. An alert fires from a statistical method or a threshold rule.
3. The agent gathers the campaign calendar, recent changes and related metrics.
4. It posts an explanation with hypotheses and evidence links to the owner's queue.
5. A person triages and decides what to do.

Pause path

1. A threshold rule reads numeric values only, and no model runs on this path.
2. If every condition holds, the execution service pauses that one send.
3. The owner is told at once, and the ledger writer records the event.
4. Only a person resumes, with a reason.

The pause rule: the one L4 action

To automatically pause an email campaign safely, the rule must meet all of these conditions, and each sits outside the model.

• A pre-approved threshold is written on the rail card, with a version number.
• Numeric inputs only. No free text enters this path, so the path never reads untrusted input and the Rule of Two holds 1.
• A pause, never a cancel. The action must be reversible.
• No resume by the agent. Only a person resumes, and the tool list has no resume call.
• A minimum send volume before the rule can fire, so a few early bounces cannot stop a send.
• An exempt list for time-critical sends.
• Transactional mail excluded, by keeping it on a separate stream.
• A cap on pauses per day. Beyond the cap, the rule alerts and stops acting.
• The owner is told immediately.

An illustrative rule looks like this. The values are invented, so set your own from provider limits and your baseline.

rule_id: pause-promo-bounce
version: 3
applies_to: marketing stream, bulk promotional sends
fire_when: hard_bounce_rate >= 1.5% and attempted_sends >= 5000
require: metrics fresher than 10 minutes
action: pause_send (one send)
exempt: list time-critical
cap: 3 pauses per day, then alert only
never: cancel, resume, transactional mail
notify: email owner on call

AWS documents the precedent. You can pause SES sending automatically per configuration set or per account, using a CloudWatch alarm, an SNS topic and a Lambda function 34. A configuration-set pause applies in one Region and leaves other account sending alone 4. So keep marketing mail in its own configuration set. The same API call also re-enables sending, so hard-code the function to disable only, limit its role as AWS suggests, and alert on any re-enable 4. SES can also pause your whole account itself. It emits no EventBridge event for that, so poll the EnforcementStatus field rather than SendingEnabled 2.

Other platforms differ. The Klaviyo and Braze pages we opened describe no pause on bounce or complaint rates that a customer can set 111213. If your platform has no pause API, the rule cannot act there, so alert a person instead.

Is a false pause worse than a missed spike?

A false pause is usually cheaper than a missed spike, because a pause is reversible and reputation damage is slow to repair. The answer changes with the send type, so decide per type.

Transactional mail is outside the rule altogether. For mailbox-provider signals across a whole stream, a sister rail, the Deliverability Watcher, holds a similar pause. Give each stream one owner, so two rules do not fight.

The rail card

The rail card fixes what the Anomaly Watcher may do at each rail level, and the rail card guide explains the fields.

What the ledger shows for one pause

One pause leaves one record, written by the execution service and ledger writer, never by the agent. The record below is illustrative, with example value values.

{
  "record_id": "aud_001204",
  "event": "send.paused",
  "rail": "anomaly-watcher@v2",
  "rule": {"id": "pause-promo-bounce", "version": 3, "approved_by": "marketing_ops_lead"},
  "metrics": {"hard_bounce_rate": 0.021, "attempted_sends": 8400, "fresh_at": "<timestamp>"},
  "send": {"ref": "snd_5521", "stream": "marketing"},
  "paused_at": "<timestamp>",
  "owner_notified": true,
  "resume": {"by": "email_owner_02", "at": "<timestamp>", "reason": "bad import removed"},
  "ledger": {"prev_hash": "9ac0...", "hash": "1fd7..."}
}

Three ways it fails, and the control for each

Anomaly detection fails more often through noise and bad data than through a missed spike, and the controls below sit outside the model.

Ratio traps cause a quieter kind of error. A rate can move because its denominator did, so show counts beside every rate. Baselines must also include promotions and holidays, or every sale looks like an anomaly.

Metrics that are honest

Honest anomaly metrics count false alarms and misses as well as catches. Baseline them against the definitions in the AI marketing operations roadmap.

• Alert precision: real issues as a share of alerts.
• Time to detect, from the first bad value to the alert.
• Time to contain, from the alert or pause to a stopped problem.
• False pauses: pauses a person judged unnecessary.
• Incidents missed, as found in post-mortems. A detector cannot report what it missed.

Baseline length is a starting point, not a rule. Improvado's guide suggests 4 to 8 weeks 6, while Amplitude's agile mode trains on 120 days of daily data 8 and GA4 on 90 days 10.

How vendor tools compare

Most tools detect and alert, and the pause is usually built separately. The table reflects pages we opened on 1 November 2026, and features may exist that these pages do not describe.

A model is optional here. If you run one sending platform and a few metrics, a CloudWatch alarm and a small function need no model at all, and that is a good answer. Add the agent when the time goes on working out why an alert fired. PrivyCDP's product page describes AI-assisted review of unusual events, with limits on data access and an immutable audit ledger. For authentication failures behind a spike, see email authentication in 2026.

Checklist

• ☐ Each metric has a named method: threshold or statistical baseline.
• ☐ Data freshness is checked before any alert or pause.
• ☐ The pause rule is written, versioned and approved in advance.
• ☐ The pause path takes numeric inputs only.
• ☐ The agent has no resume or cancel tool.
• ☐ Minimum volume, exempt list and daily cap are set.
• ☐ Transactional mail runs on a separate stream and cannot be paused by this rule.
• ☐ Thresholds sit below provider review levels.
• ☐ Past incidents and quiet periods have been replayed against the rule.
• ☐ A person has drilled the resume and the kill switch.

To see where this job sits among the others, read AI agents for marketing operations, or return to the AI agent rails hub. To write your own pause rule and card, download the rail card template.