/traffic-change-diagnosis

name: traffic-change-diagnosis
description: Diagnose why website traffic changed. Use when the user asks "why did traffic drop/spike", investigates an anomaly, or wants to separate tracking regressions from real behaviour changes. Walks a hypothesis tree (measurement → time-shape → channel → cohort → content), recognises common fingerprints (bot spike, tracking regression, deploy-correlated drop, SEO decay, campaign ramp), and applies sample-size discipline.
when_to_use: Triggered by questions like "why did traffic drop last week", "what's causing this spike", "traffic is down, what happened", or when an alert fires on pageviews/visitors/sessions. Assumes you have also loaded analytics-diagnostic-method. When two fingerprints match with similar confidence, or the change date is contested, also load anomaly-detection-time-series for STL / Bayesian changepoint detection. Auto-loaded when Clamp MCP's traffic_overview, traffic_timeseries, or traffic_breakdown returns a series spanning a suspected change window.

Traffic change diagnosis

The specialist version of the diagnostic method, applied to one question: why did traffic (sessions, pageviews, unique visitors) move?

Read `analytics-diagnostic-method` first if you haven't. This skill assumes you already know MECE, triangulation, sample size, and Pyramid presentation. It adds the traffic-specific fingerprints and drill paths.

Opening moves

1. Read `analytics-profile.md` if present. The profile tells you the expected monthly traffic range and known measurement gaps. Both matter: a "spike" from 200 to 400 sessions/day on a <1k/month site is plausibly random; the same shape on a 1M/month site is an event. 2. Restate the question precisely. "Traffic dropped" is not a question. "Daily sessions fell from ~1,400 to ~900 starting April 18, with no corresponding drop in pageviews" is. 3. Decide: is this a real change at all? Apply the sample-size rule from `analytics-diagnostic-method`. Below ~300 observations per bucket, most "changes" are noise.

The hypothesis tree for traffic

Walk in this order. Cheap checks first.

Traffic change
├── 1. Measurement  (check first, always)
│   ├── Tracking regression (script missing, container unpublished, CSP block)
│   ├── Bot filter toggle (inclusion/exclusion changed)
│   └── Attribution shift (referrer policy, cookie policy, cross-domain)
├── 2. Time shape  (what does the curve look like?)
│   ├── Cliff (single hour/day step)           → discrete event
│   ├── Ramp (gradual over days/weeks)         → campaign / SEO / decay
│   ├── Spike (single-day anomaly)             → bot burst, viral, outage resolved
│   └── Cyclic (weekly/monthly pattern change) → seasonality, campaign cadence
├── 3. Channel
│   ├── One channel moved                       → campaign / algo / platform change
│   ├── All channels moved proportionally       → measurement or site-wide issue
│   └── One channel grew, another shrank        → mix shift (use Simpson's check)
├── 4. Cohort
│   ├── New users changed, returning didn't     → acquisition-side change
│   ├── Returning changed, new didn't           → retention / email / loyalty change
│   └── Both changed                            → site-wide or measurement
└── 5. Content / page
    ├── One page moved                          → deploy, SEO page, content change
    ├── Many pages moved proportionally         → site-wide (nav, header, domain)
    └── Entry pages moved, deep pages didn't    → acquisition landing change

Fingerprints: common patterns and what they usually mean

Real diagnostic work is pattern recognition. These are the fingerprints you'll see most often. Recognising the shape narrows the tree in one glance.

F1. Tracking regression

**Shape**: cliff, single channel-agnostic, usually correlated with a deploy or config change.

**Signals**:

• Sessions drop ~X% but server logs / database row counts are roughly flat.
• The drop appears instantly at a specific time (correlates with a deploy).
• Events linked to the same page still fire at ~prior volume relative to sessions (if the event tag is different from the page tag that broke).
• Realtime dashboard shows fewer sessions than you'd expect at the current hour.

**Fix path**: check recent deploys, CSP/script-src headers, tag manager container version, and adblock-block-rate if your tool exposes it.

**When to suspect it first**: if the drop is >20% and happened in a single hour, measurement regression is the single most likely cause.

F2. Bot spike (incoming)

**Shape**: spike, usually short (hours to days), often concentrated in one country/ASN/referrer.

**Signals**:

• Traffic up, but engagement rate and conversion rate down proportionally.
• Pages-per-session collapses to 1.0 (they land and leave).
• Most "users" from a single country or data-center IP range.
• User-agent concentration (many sessions from identical or generic UAs).
• A weird referrer is top of list (e.g. `semalt.com`, `darodar.com`, obvious fake domains).
• Session duration ~0 seconds.

**Context**: Imperva's 2023 Bad Bot Report found 27.7% of all 2022 web traffic was bad bots. Roughly another 17% was good bots (search crawlers). So ~45% of raw traffic is non-human by default; your filters shape what you see.

**Fix path**: don't treat bot traffic as a "drop in quality". Filter it out, then re-examine. If the filter just changed (you turned bot exclusion on or off recently), the "change" is entirely a filter event.

F3. Deploy-correlated drop

**Shape**: cliff at deploy time, usually affects one section of the site.

**Signals**:

• Drop starts within minutes of a recent deploy.
• One or two URL paths account for most of the delta.
• The pages in question either 404, 500, or changed URL structure without redirects.
• Entry-page metric for those paths collapses.

**Fix path**: check the deploy log, check the affected URLs for status-code changes, check for missing redirects from old paths. Fast to confirm, fast t