How to find broken or leaky funnels with Segment, PostHog

You find where a funnel leaks by building it in PostHog from the events Segment sends there, then checking every weak step to see whether the drop is real before you try to fix it. A funnel in PostHog is a sequence of events, such as a pricing page view, a "Signup Started" event, and an "Account Created" event, and it counts how many people complete each one in order. The step where the count falls hardest looks like your leak.

With Segment in the middle, that step might not be a leak at all. Your site or app sends each event to Segment, and Segment forwards it to PostHog through the PostHog destination. Segment page calls arrive in PostHog as pageviews, track calls keep the event name you gave them, and identify calls tie an anonymous visitor to a known user. A break at any point in that chain produces a drop that looks exactly like people leaving. A developer renames "Signed Up" to "Account Created" in a release. A destination filter stops one event from reaching PostHog. Your app stops calling identify at signup, so the visitor who started signing up and the user who finished look like two different people. PostHog's own snippet and Segment both send pageviews, so the top of the funnel is counted twice and every later step looks weaker than it is.

Each tool shows its own half of the picture. Segment's event delivery view for a destination shows how many events were delivered and how many failed, and its debugger shows events arriving from a source. PostHog's data management pages list every event definition with when it was last seen, and its funnels show conversion between steps. But nothing in either tool connects a sudden drop in your funnel to the rename, the filter, or the missing identify call that caused it. That's the real work in this job.

A good result is a funnel where every step is measured correctly, a short list of the tracking faults that were distorting it, and the real leaks ranked by how many people they lose. Kite does that work for you. It checks the pipe in Segment, checks what arrived in PostHog, separates broken steps from leaky ones, and then works out why people leave the steps that are really losing them.

Start by telling Kite which funnel worries you:

"Our signup funnel in PostHog fell off a cliff this month. We send everything through Segment. Find out whether it's real or broken."

Kite is an AI marketer. It researches your business, builds a growth strategy, and ships the work that brings you new customers. By the time you ask, it already knows your product, how people sign up or buy, and what a good customer looks like, so it can propose the funnel's steps and the date range to study without a long brief. Confirm the steps or adjust them, and Kite starts. You can ask in the Kite web app or in Slack.

You'll need to connect two accounts. Connect PostHog through OAuth and choose the project your Segment events land in. Connect your Segment workspace so Kite can read the source that collects your events and the PostHog destination it sends them to. Tell Kite which source and destination to check if your workspace has several.

Most of this job is reading. Kite reads both tools as often as it needs to, and it saves the funnels, labels, and chart notes it creates in PostHog so your team sees the same numbers. Anything that changes what your users see, such as an edit to a page or a new experiment, waits for your approval.

Kite starts by deciding which steps matter and which PostHog events represent them. It reads the event definitions, properties, and actions in your PostHog project, along with the insights and dashboards your team has already saved. If someone built a signup funnel last quarter, Kite reruns it instead of starting from scratch.

It then matches each step to an event. For a self-serve product, the steps might be a pricing page view, a "Signup Started" event, an "Account Created" event, and a "Project Created" event. Kite runs the funnel over a recent period with your test accounts filtered out and with a conversion window that suits each journey, then compares it with the previous period. The step that got worse, or the one that was always weak, becomes the first suspect.

Kite checks the pipe before it trusts any step. It reads the configuration of your PostHog destination in Segment and the delivery summary for that destination, which shows how many events were delivered and how many failed over the period, day by day. A failure spike that starts on the same day as your funnel drop means the events never arrived, and no page change will bring them back.

Kite also reads your source's schema settings, which decide whether events that aren't in your Segment tracking plan get blocked, and the daily count of calls each source sent. If the source's volume fell on the drop date, your site or app stopped sending the event. If the source's volume held steady but PostHog received less, the events were lost or blocked between Segment and PostHog.

Kite checks each step's daily event volume in PostHog to see whether a drop is gradual or happened overnight. People rarely stop converting all at once. An event whose count fell to zero on a Tuesday, while the step before it held steady, usually means a release changed the tracking. Kite then looks for the event's replacement. A new event with a similar name that appeared on the same day, such as "account_created" taking over from "Account Created", is the usual culprit, and Kite reports both names and the date the switch happened.

It also checks for double counting. Every PostHog event records which library sent it, so Kite can see whether pageviews arrive both from Segment and from PostHog's own snippet on your site. When they do, the top of your funnel is inflated and every later step looks worse than it is.

Kite checks identity, because a funnel can only count someone as converting if PostHog knows the person at each step is the same person. With Segment, an anonymous visitor carries Segment's anonymous ID until your app calls identify with their user ID, and PostHog uses that call to merge the anonymous activity into the known user's profile.

When that call is missing or arrives late, the funnel loses people right at signup. Kite pulls the people who completed a later step and reads their PostHog profiles and distinct IDs. If people who clearly signed up have no earlier anonymous activity attached to them, the drop at signup is an identity fault rather than a conversion problem. Kite also looks for the opposite fault, where a shared ID such as a placeholder value merges many different visitors into one person.

Kite separates the steps it has proven are measured correctly from the ones that aren't, and it diagnoses only the real leaks. For a tracking fault, the job is to fix the tracking. For a real leak, the job is to find out who leaves and why.

For each real leak, Kite breaks the funnel down to see whether the loss is concentrated in one group. It compares:

• device type
• browser
• country
• UTM source
• new and returning visitors

It ranks the leaks by how many people reach the step, how close the step is to revenue, and how sharply one group underperforms. Then it pulls the list of people who dropped off at the worst step, with their session recordings where PostHog captured them, and reads the paths they took after leaving. A signup form that loses phone visitors who then bounce to your pricing page points to a very different fix than one that loses everyone to a JavaScript error.

Kite posts its findings in the conversation where you asked, with each weak step labeled as a tracking fault or a real leak and the evidence behind the label. Several fixes land in PostHog right away:

• A corrected funnel. Kite saves the funnel as a PostHog insight on a dashboard, using the right event for each step. When an event was renamed, it can define a PostHog action that matches both the old and new names, so the funnel reads correctly across the change.
• Notes on your charts. Kite adds an annotation to your PostHog charts marking the date tracking broke, so nobody later mistakes the gap for a real drop.
• Cleaner event definitions. Kite can add a description to the event your team should use, mark it as verified, and hide the one that was replaced.

The tracking itself lives in your code. Kite writes the exact fix for your developers: which call is missing or renamed, which event name and properties it should send, and where in the signup flow it belongs. If Kite already works on your website from an imported GitHub repository, it can make the change there, and it opens a pull request when your main branch is protected.

For real leaks, Kite proposes the change it would make, such as rewriting a confusing page, shortening a form on phones, or testing a new version through a PostHog experiment. Once you approve, it builds the change, and afterward it reruns the same funnel to measure whether more people got through.

When Kite finishes, you have a funnel you can trust and a clear split between what to fix in your tracking and what to fix for your users.