How do you find where users drop off in a PostHog funnel?
You find where users drop off by listing the steps someone takes toward the conversion you care about, in order, and counting how many people complete each one. The step where the count falls hardest is your leak. But the number alone won't tell you what to fix. You also need to know who left, what they saw, and where they went instead.
PostHog holds all of that when your site or product sends its events there. Kite, an AI marketer, does the analysis inside your PostHog project. It finds the step worth fixing first, works out why people leave it, and then ships the fix and measures whether it worked.
How to get started
Start by telling Kite what's bothering you. The request can be as loose as this:
Trial signups feel flat. Use PostHog to find where people are dropping out and tell me what to fix.
Kite already knows your product, your pricing, and what a good customer looks like for you, so you don't need to hand it a funnel spec. It looks through your PostHog project first, then comes back in the thread with the funnel it wants to build, the date range it will use, and the groups it plans to compare. Most of the time, you just reply "go." If your PostHog organization has separate projects for your marketing site and your product, tell Kite which one to start in. It can switch between them when the question spans both.
You connect your own PostHog account to Kite. Kite sends a connect link in Slack, you sign in to PostHog and authorize access, and Kite works with the projects that account can see. If Kite already works on your website from an imported GitHub repository and finds PostHog in the code, it asks you to connect.
This connection is separate from the analytics Kite builds into the websites it hosts. A site Kite hosts sends its events to Kite's own analytics, which has its own funnels. Use this playbook for sites and products that already send their events to PostHog.
How PostHog fits into the job
PostHog is where your users' behavior is recorded, so it's where the diagnosis happens. Every pageview, button click, signup, and in-product action arrives there as an event tied to a person. That lets Kite answer more than "what percentage converted?" It can list the people who stopped at a specific step and then look at what each of them did before and after.
Here's what that looks like. A conversion rate tells you that most people who view your pricing page never click "Start free trial." PostHog can also show that most of the phone visitors among them never scrolled far enough to reach the plan comparison, and that many who left went straight to your docs. That's the difference between knowing where the leak is and knowing what to change.
PostHog is also where several of the fixes live. Kite can run a PostHog experiment, put a short survey in front of the people who stalled, or send them an email through a PostHog workflow. It saves its funnel to a dashboard and marks the day a change shipped on your charts, so your team sees the same numbers Kite reports. Changes to the pages themselves happen on your website, through a connected Webflow site or another supported CMS, or in an imported GitHub repository.
Step-by-step
Read what your PostHog project already tracks
Kite starts by taking stock of your project, because a funnel can only use events that exist. It reads your event and property definitions, the actions your team has defined, and the insights and dashboards already saved. If someone built a signup funnel last quarter, Kite reruns it rather than starting from scratch.
This is also where tracking gaps show up. Say your funnel's last step is "project created," but that event stopped arriving three weeks ago when the app was redesigned. The funnel would show almost nobody finishing. That looks like a conversion problem, but it's really a broken event. Kite checks each step's recent volume before it trusts the step. When a step has no event at all, such as a click on your "Start free trial" button, Kite can define a PostHog action that matches the click, so the funnel measures the conversion you actually care about.
Build the funnel that matches how you sell
Kite proposes the funnel's steps from what it knows about your business. A self-serve software product might get these steps:
- viewed the pricing page
- clicked "Start free trial"
- created an account
- created a first project
- invited a teammate
A company that sells through demos might get a different funnel, running from a landing page view to a started demo form, a submitted form, and a booked meeting.
Kite runs the funnel over a recent period and leaves out your internal test accounts. It also sets a conversion window that fits each journey. Someone might sign up within an hour of seeing your pricing page, but take a week to invite a teammate. The result shows how many people reached each step and what share of them moved on to the next one.
Find the drop-off worth fixing first
The step with the lowest conversion rate isn't always the one to fix first. Kite weighs three things before it picks:
- how many people reach the step, because a small leak on a busy step can cost you more than a big leak on a quiet one
- how close the step is to revenue, because losing people after they've created an account usually hurts more than losing casual pricing-page visitors
- whether the drop is concentrated in one group of people
That last check often finds the answer. Kite breaks the funnel down by properties such as device type, browser, country, and UTM source, and by cohorts such as new and returning visitors. Say 64% of desktop visitors who click "Start free trial" go on to create an account, but only 29% of phone visitors do. Your signup form isn't the problem. Your signup form on phones is.
Kite also compares the funnel with the previous period and looks at how each step's conversion rate has moved over time. That tells it whether a step has always been weak or broke on a specific date, which points to very different fixes.
Work out why people leave
Once Kite knows which step loses people, it looks at what those people did. It pulls the list of people who dropped off at that step, along with their session recordings when PostHog captured them, and collects the most telling ones in a playlist your team can watch. It can also ask PostHog to review a set of those recordings against a specific question, such as why visitors abandoned the signup form.
Kite then checks the rest of the evidence:
- the paths people took after leaving the step, to see whether they went to your security page, your docs, or nowhere at all
- click, rage-click, and scroll-depth heatmaps for the page, compared between phones and desktops
- the errors PostHog recorded on that page and the people they affected
Each source answers a different question, and together they usually point to one explanation. Rage clicks on a "Continue" button plus a JavaScript error in Safari point to a bug. A path that runs from the signup form to your security page and then off the site points to a missing answer about how you handle customer data. When the evidence still doesn't settle it, Kite asks. It writes a one-question PostHog survey for people who reached the step without finishing it.
Build the fix and bring it to Slack
Kite turns the strongest explanation into a specific change and builds it. Where the change lands depends on the step:
- A page on your website. Kite rewrites the copy, shortens the form, moves the call to action, or adds the missing answer. It makes the change on your connected Webflow site or other supported CMS, or in your imported GitHub repository, where it merges into your main branch or opens a pull request if that branch is protected.
- A test inside your site or product. Kite estimates how long a test needs to run with your current traffic. Then it sets up a PostHog experiment with its feature flag, its variants, and the funnel step as the goal. Your site or product decides which version to show by checking that flag, so your developers connect the new version to it unless Kite is already working in that code.
- A nudge to the people who stalled. Some drop-offs happen after signup, such as people who create an account but never start a first project. If your team sends email through PostHog workflows, Kite writes the email and builds the workflow that sends it to people who stop at that step.
Kite posts the finished change in the Slack thread with the evidence behind it and the number it expects to move. Kite proposes work by default. A team approves it with a reply in the Slack thread or the Approve button on a proposed plan. Teams that want Kite to act first can turn that on. Once you approve, Kite publishes the page, launches the experiment or survey, or turns on the workflow.
Measure whether more people get through
Kite measures the result with the same funnel it used to find the problem, so the before and after are directly comparable. When the change goes live, Kite adds an annotation to your PostHog charts that marks the date, and it saves the funnel to a dashboard your team can open anytime.
For a website change, Kite compares the step's conversion rate over a comparable period before and after the change. For an experiment, it reads the results for each version and recommends a winner once there's enough data. After you agree, it ships the winning version to everyone.
Then the loop keeps going. If the phone signup rate climbs toward the desktop rate, Kite moves on to the next weakest step. If it doesn't, Kite goes back to the recordings and paths with a sharper question.
What the finished work contains
A funnel saved in PostHog
The steps, date range, conversion window, and breakdowns Kite used, saved as an insight on a dashboard so anyone on your team can rerun it.
A ranked list of drop-offs
Each step's conversion rate, how many people it loses, which groups it loses them from, and why Kite chose the step it did.
An explanation with evidence
The recordings, paths, heatmap patterns, errors, and survey answers behind the diagnosis, with links back to the matching views in PostHog.
A shipped change
The updated page, the running experiment, or the live email workflow, posted in Slack once you approve it.
A before-and-after result
The step's conversion rate on each side of the change, or the results for each experiment version, plus the step Kite plans to work on next.
Common questions
Why does my PostHog funnel show a big drop right at signup?
A sharp drop at the signup step is often an identity problem rather than a conversion problem. If your app doesn't tell PostHog who a person is when they create an account, the anonymous visitor who clicked "Sign up" and the new user who finished signing up can look like two different people. The funnel then counts the visitor as lost. Kite checks whether the people completing later steps carry their earlier anonymous activity on their PostHog profiles. When they don't, it treats the step as a tracking fix before it touches the page.
Do I need session replay turned on?
No, but it makes the diagnosis much stronger. Kite can find the weak step from events alone, along with the paths and errors around it. Recordings and heatmaps show what people actually did on the page, so turn them on for the pages in your funnel if you can. PostHog keeps heatmap data for 90 days, so Kite reads heatmaps within that window.
Will Kite tell me if the step gets worse again?
Yes. Kite can set a PostHog alert on the saved funnel, so the people you choose hear about it when the conversion rate falls below a level you agree on or moves unusually. It can also rerun the funnel on a weekly schedule and report in Slack when a step slips.
Can Kite show which drop-offs cost us revenue?
Yes, when you connect Stripe and your tracking gives both tools a shared identifier, such as the user's email address or account ID. Kite can then compare what paying customers did in your product with what everyone else did, and rank drop-offs by the revenue behind them.