A step-by-step way to work
Confirm the drop is real first
Before diagnosing, use AI to draft the query that verifies the drop isn't a tracking artefact (and sanity-check it).
Quantify and segment
Ask for queries that size the drop and break it by segment — device, source, cohort — to localise where it's happening.
Generate hypotheses once localised
With the drop isolated, ask for candidate causes, internal and external, to test.
Draft the test for each hypothesis
Have it propose the query or experiment that would confirm or kill each cause.
Reason to the cause yourself
AI proposes; you weigh the evidence and decide what's actually causing the drop.
Real prompts, and what good output looks like
Checkout completion dropped from 68% to 54% over two weeks. I've confirmed the tracking is fine and it's concentrated on mobile. Give me candidate causes to test, internal and external.
Internal: a recent mobile checkout release (regression?); a new required field added; payment provider change; slower mobile load after an asset change.
External: a payment outage; a seasonal shift in traffic mix toward lower-intent mobile users; an app-store or OS update affecting the webview.
Test order: check the deploy log against the drop's start date first — timing correlation is the cheapest signal.
These are hypotheses; the deploy-timing check will likely rule several in or out fast.
Write a query to break mobile checkout completion by app version for the last 14 days, so I can check the regression hypothesis. Events table has user_id, event_name, app_version, created_at.
SELECT app_version,
COUNT(DISTINCT CASE WHEN event_name='checkout_complete' THEN user_id END) * 1.0
/ NULLIF(COUNT(DISTINCT CASE WHEN event_name='checkout_start' THEN user_id END),0) AS completion_rate,
COUNT(DISTINCT CASE WHEN event_name='checkout_start' THEN user_id END) AS starts
FROM events
WHERE created_at >= CURRENT_DATE - INTERVAL '14 days'
AND platform = 'mobile'
GROUP BY app_version
ORDER BY app_version;A prompt you can reuse
Fill in the highlighted parts and paste it into your AI tool of choice. Edit the output — it's a starting point, not a finished answer.
Help me diagnose a funnel drop-off. Keep to the discipline: confirm it's real, segment, then hypothesise. The drop: [metric, from X% to Y%, over what period] What I've already confirmed: [e.g. tracking is fine; concentrated on which segment] My data: [tables and key columns] Please: 1. If not yet confirmed, give me the query to check the drop isn't a tracking artefact. 2. Give queries to quantify and segment the drop (by device, source, cohort, version). 3. Once I tell you where it's localised, list internal and external candidate causes. 4. For each cause, propose the cheapest query or test to confirm or rule it out. Explain each query so I can verify it.
What AI gets wrong here
Jumping to a confident cause
AI will name a likely cause persuasively — which is the same error as guessing yourself.
Skipping the integrity check
Diagnosing a drop that's actually a tracking bug wastes everyone's time.
Correlation as causation
A deploy that coincides with the drop isn't proof.
The diagnostic discipline is unchanged by AI: verify the drop is real, segment to localise it, then test hypotheses. AI accelerates every step — and will just as fluently hand you a wrong cause. It's a generator of queries and hypotheses; the verdict on what's actually causing the drop is reasoned by you from the evidence.