Skip to content
Nosey Parkers
Knowledge Centre
AI Automation2 min read

AI automation: marketing anomaly alerts that explain themselves

How to combine simple statistical detection with an LLM explanation layer so your team hears about problems — with context — before the platforms bill you for them.

Most marketing disasters are quiet: a consent banner update silently blocks conversions, a feed error pauses your best products, CPCs drift up 40% over three weeks. Nobody notices until month-end. An anomaly alerting system notices on day one — and the AI layer means the alert arrives already explained.

Layer 1: boring, reliable detection

Don't start with machine learning. Start with statistics a finance director would trust:

def is_anomalous(today: float, history: list[float], threshold: float = 3.0) -> bool:
    """Flag if today's value sits > threshold MADs from the median.
    MAD (median absolute deviation) shrugs off the odd weird day
    that would wreck a standard-deviation approach."""
    median = statistics.median(history)
    mad = statistics.median([abs(x - median) for x in history])
    if mad == 0:
        return today != median
    return abs(today - median) / (1.4826 * mad) > threshold

Run it daily over each metric that matters — spend, conversions, CPA, revenue — segmented by channel. Compare like-for-like weekdays (Tuesdays with Tuesdays) to sidestep weekly seasonality.

Layer 2: the AI explanation

A raw alert says "Meta conversions -62% vs expected." Useful, but now someone must investigate. The LLM layer does the first pass of that investigation automatically. Feed it a structured bundle of facts:

  • the anomalous metric and its history
  • what didn't change (spend flat? traffic flat?)
  • recent deploy and campaign-change logs if you have them

Because conversions fell while spend and traffic held steady, the model can reason toward "measurement breakage, not performance collapse" and say so:

⚠️ Meta conversions dropped 62% on 12 May. Spend and landing-page sessions are normal, which points to a tracking failure rather than a real performance drop. The pixel may have been affected by yesterday's website deploy. Suggested first check: Events Manager → purchase event volume, browser vs server.

The model never computes numbers — detection already did that. It converts verified facts into a triage note.

Delivery and discipline

  • Send to Slack/Teams, where the team already lives. Alerts in an unwatched inbox don't exist.
  • Tune thresholds until alerts are rare. One ignored false alarm per week kills the whole system's credibility.
  • Log every alert and its resolution — after three months you have a priceless dataset of what actually goes wrong in your stack, and how fast you catch it.

Clients typically catch their first "silent disaster" within the first six weeks. That one catch usually pays for the build.

Related guides

Ready to see what your data has been trying to tell you?

Book a free discovery call. We'll look at your current setup, tell you what's broken, and show you exactly what better looks like — no obligation, no fluff.