Ask your data where people give up

What it is and why it matters

People download your app, and then what? Some reach the first real use, some get lost along the way. Where, you usually don't know: you open your analytics, look at ten charts and close it without having changed anything.

If you use PostHog for analytics, you can connect it to Claude Code through its MCP server. MCP is the standard way Claude Code talks to an outside service: once it's connected, Claude queries your data on its own, with PostHog's tools for funnels, queries, insights, feature flags and experiments. And since it's the same session that has your code, it goes straight from the number to the screen.

The full loop: funnel, the step where you lose the most people, the code of that screen, one change shown to half your users, the result a few days later. Connecting to the MCP server is free and PostHog has a generous free tier on every product, no credit card required. Only some tools that use PostHog's own AI can be billed separately.

1. Connect PostHog to Claude Code

PostHog's MCP server is hosted by them, at https://mcp.posthog.com/mcp. In the terminal, outside Claude Code, run:

claude mcp add --transport http posthog https://mcp.posthog.com/mcp -s user

-s user means “for me, in every project”. Without it, the server only works in the project you're in, which is the default scope. Then open Claude Code, type /mcp, pick posthog and sign in: the browser opens, you log in to PostHog and authorize. No keys to copy, and PostHog routes you to the right region, US or EU, based on your account.

With Claude Code the server exposes a single tool, exec, which Claude uses to find and call the others when needed: you save context. First, check the project:

Use PostHog: tell me which organization and which project you're connected to, and give me the 20 most frequent events of the last 30 days, with the number of unique people for each. Don't create or change anything.

If at first you want Claude to only be able to read, use this instead of the earlier command, with ?readonly=true at the end of the address: the tools that create, change or delete disappear. For the flag part, remove it with claude mcp remove posthog and add the normal one back. And as PostHog itself says, read every call before you approve it.

claude mcp add --transport http posthog "https://mcp.posthog.com/mcp?readonly=true" -s user

2. The funnel, from install to first real use

A funnel is a row of steps in order, with how many people reach each one. You decide what the first real use is: the first finished workout, the first saved note. Not “opened the app”, but the moment they got what they downloaded it for. In phone apps, PostHog's SDKs can record the Application Installed event on their own: check that it's on.

Use PostHog. Build a funnel for the last 30 days from install to the first real use of my app: [Application Installed] → [sign-up completed] → [onboarding finished] → [first workout completed]. First check that these events really exist and tell me if any are missing, without making them up. Then give me, for each step, how many people reach it, the percentage relative to the previous step and how long they usually take.

Put your own event names in place of the ones in square brackets: if you don't know them, take them from the earlier list. And ask for the percentage relative to the previous step: PostHog's documentation explains that it's the one that shows where there's most to gain.

3. Find where they give up

In the funnel, which step loses me the most people? Give me the number and the percentage. Then break that step down by operating system, app version and country, and tell me whether the drop is the same for everyone or concentrated in one group. Finally, find the screen in the code where that step happens and show me the file.

The breakdown matters: if the drop is all on one version or one system, it may be a bug, not a design problem. And if you record sessions with PostHog, ask Claude to list a few people who stopped right there and watch their recordings: it's often the fastest way to understand why.

4. One change, for half your users

Now ask for a proposal, not a fix:

Open the code for the [step] screen and tell me the 3 most likely reasons people stop there, based on what you see in the code and in the data. For each one, propose a single small change. Don't write any code until I pick one.

Pick one. To test it you need a feature flag, a switch the app reads while it runs (I cover it in the INTERRUTTORE guide, strikt.fit/interruttore). To measure, the cleanest way is a PostHog experiment: it creates the flag with two variants, control (as it is now) and test (the change), splits people at random, keeps track of who sees what and does the statistics for you.

Use PostHog. Create an experiment called [shorter-onboarding] with two variants, control and test, split 50/50, with the funnel from [step] to [first workout completed] as the primary metric. Then put the chosen change behind its flag: with control the user sees the current screen, with test the new one. Only include people reaching that screen for the first time, and if the flag can't be read, show the current version. Before launching it, tell me how many people are needed and how many days it takes with my traffic.

“For the first time”, because PostHog recommends including only the people affected by the change. “If it can't be read”, so a network problem doesn't show everyone something half-done. “How many people are needed”, because PostHog's calculator tells you before you start. And on iPhone the change has to be in the published version already: the flag only switches on code that's there.

Before the 50/50 split, PostHog suggests a trial run on a small share of users, for example 5%, for a few days: you check that the events come in and that there are no crashes. If the experiment launches broken and you relaunch it, the results are no longer reliable, because many people have already seen the change.

5. Read the result

When the days the calculator gave you have passed, for example a week:

Use PostHog. Give me the results of the [shorter-onboarding] experiment: how many people per variant, the conversion for control and for test, and whether the difference is statistically significant. Tell me whether we reached the number of people we needed. If it isn't significant or we're short, say so plainly and don't declare a winner.

If test wins, roll it out to everyone and clean up: PostHog itself says that at the end of an experiment you keep the winning variant's code and delete the losing one's. If there's no difference, that's a result too: go back to the list of 3 reasons and try the second.

Test won the [shorter-onboarding] experiment. End it in PostHog by rolling test out to everyone, then remove the flag and the old version from the code, run the tests and tell me what you changed.

6. How not to fool yourself

• Decide the duration up front. Checking the results every day and stopping at the first nice number is what PostHog calls the peeking problem: peek often enough and sooner or later something looks like a winner by chance.
• Enough people. With few users, a difference is often just chance. To give you an idea, in the example in PostHog's documentation, with a 10% conversion rate and a 20% change to detect, you need about 3,600 people per variant. If you have far fewer, test bigger changes.
• One change at a time. If you change the copy, the color and the number of steps together, you'll never know what worked.
• Also look at what gets worse. A shorter screen can get more people to the next step and fewer people coming back the next day. Pick a second metric to keep an eye on beforehand.

Common mistakes

• Letting Claude guess the event names. Get the list first, then build the funnel.
• Working on the wrong project. A connection has one account and one active project: check which before creating anything.
• Turning the change on for everyone. Without a group that sees the old version, you have nothing to compare against.
• Stopping the experiment on the first good day. Wait for the duration you decided up front.
• Leaving the flag in the code after the decision. Remove the flag and the losing variant.

Checklist

• PostHog MCP server added and signed in from /mcp.
• Right project checked, event list in hand.
• Funnel up to the first real use, with step-by-step percentages.
• Worst step broken down by group and screen found in the code.
• A single change, behind a 50/50 experiment, tried first on a few users.
• Duration and number of people decided before starting.
• Result read with its significance, flag removed when the experiment ends.

Frequently asked questions