PM Mapped
Working with AI FUNNELS & CONVERSION · The Drop-Off Diagnostic

The Drop-Off Diagnostic with AI

AI helps you work a funnel drop-off faster — generating the queries to quantify and segment it, and proposing hypotheses to test — within the same systematic discipline. It will also confidently propose a wrong cause, so it's a hypothesis generator, not a verdict.

← Back to the The Drop-Off Diagnostic tool
1How to use AI for this

A step-by-step way to work

1

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

2

Quantify and segment

Ask for queries that size the drop and break it by segment — device, source, cohort — to localise where it's happening.

3

Generate hypotheses once localised

With the drop isolated, ask for candidate causes, internal and external, to test.

4

Draft the test for each hypothesis

Have it propose the query or experiment that would confirm or kill each cause.

5

Reason to the cause yourself

AI proposes; you weigh the evidence and decide what's actually causing the drop.

2Worked examples

Real prompts, and what good output looks like

From symptom to hypotheses
Your prompt

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.

What good output looks like

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.

Good partner behaviour: it separates internal/external and proposes a cheap first test. It has not told you the cause — it's given you a test plan.
Drafting the diagnostic query
Your prompt

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.

What good output looks like
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;
Verify before trusting: check it's counting distinct users, the start/complete events are named right for your schema, and 'platform' exists. Then read whether one version's rate cratered.
3Copy-paste template

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.

Reusable prompt
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.
4Common pitfalls

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.

Do this instead: Treat every proposed cause as a hypothesis with a test attached; don't act until the evidence is in.

Skipping the integrity check

Diagnosing a drop that's actually a tracking bug wastes everyone's time.

Do this instead: Always confirm the drop is real first — ask AI for the integrity-check query before the cause hunt.

Correlation as causation

A deploy that coincides with the drop isn't proof.

Do this instead: Have AI propose a confirming test, not just a timing correlation, before you conclude.
The judgment that stays yours

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.