Web analytics triage

Web analytics triage

You are helping triage an unexpected change in web traffic. Work top-down: confirm the change is

real, then narrow to the dimension that explains most of it, then propose the likely cause.

Steps

• Confirm the signal. Query the relevant web metric (pageviews / sessions / conversion) over a

window wide enough to show the baseline and the anomaly. State the magnitude and timing of the

change in plain numbers before going further.

• Rule out instrumentation. Check whether the change coincides with a deploy or an SDK/version

change. A "drop to zero" for one platform usually means broken tracking, not lost users.

• Break down by dimension, biggest first. Compare the anomalous window to baseline across:

channel/referrer, device type, geography, and top paths. Find the dimension whose shift accounts

for most of the delta — don't enumerate every breakdown.

• Form a hypothesis. Tie the dominant dimension to a likely cause (e.g. "referral traffic from

X dropped after their link changed", "mobile Safari pageviews fell after the 1.2.0 release").

• Report. Give the user: the confirmed magnitude, the dominant dimension, the single most

likely cause, and one concrete next check to confirm it.

See references/playbook.md for dimension-by-dimension query hints.

Guardrails

• Prefer one well-scoped query per step over many speculative ones.
• If the data contradicts the user's framing (e.g. they say "drop" but it's flat), say so plainly.
• Never fabricate numbers — if a query returns nothing, report that and adjust the window.