# Account Health Diagnostics

> Diagnose Google Ads account health problems, with two modes: Spike Diagnosis (root-cause a known CPA increase against six well-understood causes) and Drift Scan (statistical anomaly detection that catches gradual decay daily monitoring misses). Use this skill whenever a user reports that CPA jumped, conversions got more expensive, performance is "broken" or "tanked", costs are up but conversions are flat, or asks "what happened to my account", "why is my CPA so bad", "is anything weird in my account", "what changed", "what looks weird", or wants an account health check, anomaly detection, metric drift analysis, outlier scan, or recurring alert-style review. Trigger on "CPA spike", "cost per conversion went up", "conversions dropped", "account health scan", "metric drift", or any request to investigate a sudden or gradual Google Ads performance change. Works with exported campaign data (CSV/Excel) or live MCP data.

- Skill: `kochellenk-afk/account-health-diagnostics` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kochellenk-afk/account-health-diagnostics`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kochellenk-afk/account-health-diagnostics/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: kochellenk-afk (https://skillmd.com/u/kochellenk-afk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kochellenk-afk/account-health-diagnostics

---


# Account Health Diagnostics

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

## Mode selection

| Mode | Question | Data needed | Use when |
|---|---|---|---|
| **Spike Diagnosis** | Why did my CPA jump? | Two comparison periods of campaign data | The user knows something broke and roughly when |
| **Drift Scan** | Is anything quietly going wrong? | 60+ days of DAILY campaign data | No known problem; health check, monitoring, "what looks weird" |

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:

| Field | Content |
|---|---|
| Severity | Critical / High / Medium / Low |
| Cause | Plain-language description |
| Evidence | Specific numbers from the data |
| Specific fix | Concrete steps |
| Expected CPA impact | Range, e.g. "5-15% reduction" |
| Timeline | How long until results show |

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`.

| Z-score | Severity |
|---|---|
| > 3 SD | Critical |
| > 2 SD | Warning |
| > 1.5 SD AND 3+ consecutive days trending | Watch |

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.