ANALYTICS & REPORTING

Honest traffic drop diagnosis

Use when traffic has fallen and you need a ranked list of causes rather than a guess.

traffic-drop-honest-diagnosis.md

Download .md

Act as a skeptical analyst investigating a traffic drop. Your job is to find the cause, not to reassure me.

Drop: {{METRIC}} fell from {{BEFORE}} to {{AFTER}} between {{DATE_A}} and {{DATE_B}}.
Segment breakdown available: {{SEGMENT_DATA}}
Site and stack: {{SITE_CONTEXT}}

Produce a table: Hypothesis | What we would see if true | What we would see if false | Data source to check | Time to check | Prior likelihood (High/Medium/Low).

Cover at minimum: tracking or tagging change, bot or referrer spam removal, algorithm update, seasonality, a competitor or SERP layout change, site change or deployment, paid spend change, a single high-traffic page or template breaking, and consent banner or measurement change.

Rules:
- Order by prior likelihood, then by how quickly the check can be done.
- Discriminating evidence matters more than plausibility. If a hypothesis cannot be distinguished from another with the data listed, say so.
- Do not state a cause as fact. Every conclusion is a hypothesis until a check confirms it.
- If the drop pattern looks like a measurement artefact rather than real lost demand, say that first and loudly.
- End with the single check to run first and what result would rule out half the list.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{METRIC}}
{{BEFORE}}
{{AFTER}}
{{DATE_A}}
{{DATE_B}}
{{SEGMENT_DATA}}
{{SITE_CONTEXT}}

Getting a better result

Give it a day-by-day series, not just two totals - a cliff and a slope have different causes.
Say whether the drop appears in server logs as well as the analytics tool; that alone splits the list in two.
Keep the output and tick off hypotheses as you disprove them so you do not re-litigate the same theory.

Questions about this prompt

When do I use this rather than checking my favourite cause first?

When you have a drop and a theory you already like. The prompt widens the list before you commit a week to one hypothesis, and it pushes measurement artefacts to the front where they belong. If you already know a deploy broke the tag, just fix it. If you are guessing, run this before touching anything.

What do I need in front of me?

A day by day series rather than two totals, because a cliff and a slope have different causes. Add the segment breakdown, the site and stack, and whether the fall shows in server logs as well as the analytics tool. That last detail alone splits the hypothesis list roughly in half.

What comes back, and which column matters?

A hypothesis table with what you would see if true, what you would see if false, the data source, time to check and prior likelihood. The if false column is the useful one, since it is what separates two equally plausible causes. It closes with the single check to run first and what that check rules out.

What is the mistake that costs me here?

Re-litigating a hypothesis you already disproved because a new stakeholder walks in with it. Keep the table and tick rows off as you eliminate them. The other is reporting a cause as fact once one check comes back suggestive. Everything here stays a hypothesis until a check confirms it, and the prompt holds that line.