Account Health Diagnostics

Account Health Diagnostics

Two modes for one job: figuring out what's wrong with a Google Ads account.

Mode selection

Selection heuristics:

• User names a specific symptom with a timeframe ("CPA went from $40 to $65 this month") → Spike Diagnosis
• User wants a general scan, alert-style review, or asks "what changed" with no specific symptom → Drift Scan
• Drift Scan finds a serious anomaly → offer to run Spike Diagnosis on it as the follow-up. This chain is the ideal workflow: Scan finds it, Diagnosis explains it.

State which mode you're running at the top of the response.

Shared cause library (both modes reference this)

CPA problems have six well-understood causes. Spike Diagnosis checks all six formally; Drift Scan uses them as hypotheses when cross-referencing anomalies.

1. Bid strategy changes: automated bidding shifted targets or learning reset. Signature: CPC rose sharply with stable conversion rate. Learning period spikes are normal for 7-14 days after a strategy switch.
2. Search term drift: new irrelevant queries entered the auction. Signature: new high-spend zero-conversion terms in the recent period, CTR often drops. (Fixing it is the negative-keyword-engine skill's job.)
3. Quality Score drops: lower QS → higher CPC → higher CPA. In play if campaign avg QS dropped 1+ points. NEVER claim this cause without QS data; it's the most common scapegoat and often wrong.
4. Competitor activity: "IS lost to rank" up, absolute top impression share down. Auction insights data nails this.
5. Landing page issues: conversion rate dropped while CTR held steady. People click but don't convert. Check by device; mobile conv. rate drops often mean a speed or layout regression.
6. Audience shifts: demographic, geographic, or device mix changed. New geos receiving spend, or mobile share growing in a desktop-heavy account.

Cross-reference signatures (used by both modes):

• CPA spike + CPC spike + IS lost to rank up → competitor entry (cause 4)
• CPA spike + conv. rate drop + CTR stable → landing page (cause 5)
• CPA spike + CTR drop + new search terms → search term drift (cause 2)
• Spend spike with no conversion spike → bid strategy or budget (cause 1)
• CPC up + conv. rate stable + no IS change → bidding (cause 1)

These are hypotheses to surface, not proof. Always use "possible cause" framing.

MODE 1: Spike Diagnosis

Required inputs (ask before proceeding if missing)

1. The spike quantified: "CPA went from $X to $Y over [period]." Don't accept "CPA is bad."
2. A baseline period: typically the 30 days before the spike. No baseline, no diagnosis.
3. Campaign data for both periods with the columns below.
4. Known recent changes: new campaigns, bid strategy switches, creative updates, budget shifts, landing page edits. Ask; even small changes can be the cause.

If the user just said "my CPA spiked," reply with one message:

Before I diagnose, I need:

1. The spike numbers: CPA before and after, over what dates?
2. Campaign performance data for both periods: CSV/Excel with spend, conversions, CPA, impression share, and Quality Score columns (or live via your Google Ads MCP)
3. Any recent changes: new campaigns, bidding, creative, budgets, landing pages?

Required data columns (or close equivalents)

Per campaign, per period: Campaign name; Spend; Impressions, Clicks, CTR; Conversions, CPA, Conv. rate. For cause 4: impression share (overall, lost to budget, lost to rank) and top/absolute-top %. For cause 3: average Quality Score. Search terms and keyword-level QS are bonus.

If a cause's data is missing, say so explicitly ("I can't evaluate competitor activity without impression share columns; re-export with those") rather than extrapolating.

Workflow

Step 1: Compare periods. For each campaign compute deltas: ΔCPA, ΔSpend, ΔConv, ΔConv. rate, ΔCTR, ΔCPC, ΔIS. Sort by absolute spend impact (ΔSpend × ΔCPA / baseline CPA) so the biggest offenders surface first.

Step 2: Run the six checks from the shared cause library against the deltas. Note: bid strategy and competitor causes often produce smaller, harder-to-spot signals than search term drift but are more often the real culprit. Don't blame the most dramatic-looking metric by default.

Step 3: Ranked diagnosis output. For each cause with evidence:

Severity rubric: Critical = explains most of the spike and is actively bleeding budget; High = major contributor with clear evidence; Medium = contributing factor or strong hypothesis needing one more data point; Low = present but minor.

Sort by severity, then expected impact. End with a most likely cause verdict (one cause, or two if clearly multi-factor) and the first action to take this week.

Spike Diagnosis must NOT

• Diagnose without a baseline.
• Recommend pausing campaigns reflexively; most spikes are fixable without nuking volume.
• Claim QS is the cause without QS data.
• Extrapolate causes from missing data.

MODE 2: Drift Scan

Required input

Daily campaign metrics for the last 60 days minimum. Weekly data is too coarse for statistical baselines. If only weekly/monthly data is available:

"Anomaly detection needs daily-level data for at least 60 days. Weekly data is too coarse for statistical baselines. Please re-export at daily granularity."

Columns per campaign x day: Date, Campaign name, Spend, Impressions, Clicks, CTR, CPC, Conversions, CPA, Conv. rate, Search impression share.

Why this catches what monitoring misses

A 5% daily change feels small, but 5% drift sustained over 30 days compounds and is often invisible until it has bled budget for 7-14 days. Statistical baselines catch what eyeballing doesn't.

Workflow

Step 1: Build the baseline. For each campaign x metric, use days 1-30 (the OLDER half) as baseline: compute mean and standard deviation. Days 31-60 (recent) are what you're testing. The split prevents recent anomalies from contaminating the baseline. Filter out zero-spend and paused-day rows first; they distort SDs. Skip campaigns with <14 days of baseline data.

Step 2: Flag spike anomalies. For each recent day x campaign x metric: z = (value - baseline_mean) / baseline_std.

Only flag the LAST 7 days for spike alerts; older spikes are historical, not actionable. Where data allows, use day-of-week-adjusted baselines: Sunday CPA legitimately differs from Tuesday in many B2B accounts. Don't flag known weekly cycles.

Step 3: Detect trend drift. Compare recent-14-day avg to prior-14-day avg within the recent 30: drift = (recent14 - prior14) / prior14 x 100. Flag if |drift| > 5%. Classify direction: drift UP is bad for CPA, CPC, IS lost to budget/rank, and spend (if budget-flat); drift DOWN is bad for conversions, conv. rate, CTR, revenue, ROAS, and IS.

Step 4: Cross-reference. For each anomaly, check co-moving metrics on the same days against the shared cause library signatures. Surface hypotheses, not verdicts.

Step 5: Alert dashboard output.

# Anomaly Detection Report: [Date Range]

## Critical (>3 SD)
- **[Campaign]**: [Metric] [direction] [magnitude] on [date(s)]
  - Current: [value], baseline avg: [value], deviation: [Z] SD
  - Possible cause: [hypothesis from the cause library]
  - Recommended action: [specific step]

## Warning (>2 SD)
[same structure]

## Watch (sustained drift)
[same structure]

## All Clear
- Campaigns within normal bounds: [list]

ALWAYS include the All Clear section; stakeholders want to see what was checked, not just what failed. If the user is setting up a recurring scan for email/Slack, format with bullets and short lines, no wide tables.

End Critical/Warning findings with an offer: "Want me to run a full spike diagnosis on [campaign]? I'd compare the anomaly window against the prior baseline and check all six causes."

Drift Scan must NOT

• Run on weekly data.
• Flag every movement; apply the SD thresholds. False positives erode trust.
• Claim certainty on causes.
• Include zero-spend days in baselines.

Implementation note (both modes)

Do the math with pandas in the code environment; don't estimate z-scores or deltas by eyeballing tables. Show the thresholds used at the top of every report so the user can challenge them.