Onboarding path analysis across 4 publishers

Define an ordered sequence of product events within a time limit, then inspect which step loses the most users on the path to first value.

Each step relies on specific counting behaviors that shape the results.

1. Define the ordered journey. A funnel analysis counts how many users complete a defined sequence of events, in order, within a time limit you set, and shows you which step loses the most users, according to Amplitude.
2. Recognize repeated journey entries. If a user enters the funnel by firing the first step on both July 1st and July 2nd, and completes the funnel within 30 days of both dates, Amplitude counts that user in the conversion percentages for both July 1st and 2nd, according to Amplitude.
3. Check custom event coverage. Only the 50 most frequently queried custom events in the project are used in Flows analysis, according to Mixpanel.

This approach isolates the specific point in the journey where progress toward the initial result stops.

The analysis relies on a strict temporal and sequential structure. For example, a funnel can show (1) any users who (2) triggered all these events (3) in this order, (4) within one day of triggering the initial event, according to Amplitude. The one-day window in this example illustrates how the completion limit anchors the measurement to a specific timeframe following the first action. You must specify both the order of actions and the duration allowed for completion to generate a valid count.

When mapping an existing customer's journey, the ordered sequence must reflect the actual product interactions required to reach first value. Use Onboarding tools: compare 4 customer project plans when you choose the project plan that should hold this sequence, and use Verify 7 onboarding checklist items across 5 tools when you want a checklist beside the path. By establishing these parameters, you create a measurable path that highlights the step with the highest drop-off. This allows you to identify where the onboarding process stalls before the customer achieves their initial result.

Before analyzing where a customer's onboarding journey stalls, you must confirm that the product events are actually being captured by your analytics source. The first practical step is to begin source event tracking by calling the Track method. According to Twilio, calling Track in one of the sources is one of the first steps to getting started with Segment.

When implementing this tracking, you must match the syntax to the specific library used in your project. The code structure varies depending on the technical stack and the particular source library selected for the integration. According to Twilio, based on the library you use, the syntax in the examples might be different. This variation means that a Track call written for one library may not function correctly if copied directly into another. You should verify the specific syntax requirements for your chosen library to ensure that the event data is formatted correctly for ingestion.

To prepare your instrumentation effectively, follow these steps:

1. Identify the specific source library you are using for your analytics integration.
2. Locate the documentation for the Track method within that specific library.
3. Implement the Track call using the syntax provided for that library.
4. Verify that the event is successfully recorded in your analytics platform.

After you verify that the event is recorded, save the library name beside the event name so a later review can find the Track syntax, the ordered sequence, and the time window together. Leave the repeated-entry case and the custom-event coverage limit in the same notes so you can explain the count without rebuilding the ordered sequence from memory. Name the publisher whose counting rule you used when you saved the note.

Specify the time limit within which a user must complete the sequence to count as converted. This window determines how the analysis groups activity into readable buckets. Amplitude automatically chooses a bucket size (1 second, 10 seconds, 1 minute, 10 minutes, 1 hour), depending on the conversion window and lookback window you select, according to Amplitude. Record the specific window chosen for the analysis so that future reviews can replicate the exact grouping logic. Read the bucket sizes beside the window you saved so a later review can follow the grouping.

Entry date attribution defines which date a user's progress is assigned to when they enter the funnel. For example, if a user enters a funnel on January 1st and then converts in the funnel on January 5th, Amplitude counts them in the bucket for January 1st, since that's when they first entered the funnel, according to Amplitude. This rule ties the conversion to the initial entry date rather than the completion date. When analyzing an existing customer's journey, note the date they first triggered the first step to determine which bucket their eventual conversion falls into.

Repeated entries can affect conversion percentages if a user triggers the first step multiple times. This behavior means a single user's activity can contribute to multiple daily conversion metrics if the completion occurs within the defined window for each entry date.

When a customer reaches the first event in your sequence, the next question is which subsequent actions they actually take. Different tools handle the display and combination of these events differently, so you must check the coverage limits before interpreting the results.

Combine alternative events

If your onboarding path allows users to reach a milestone through different actions, you can group those actions into a single step. In Funnels - Docs - PostHog, you can combine multiple events into a single funnel step using inline combination, according to PostHog. When you select the events to include in a step, they're combined using a logical OR – any occurrence of the selected events counts toward that step, according to PostHog. This approach treats the step as a set of acceptable actions rather than a single rigid path.

Refine qualifying actions

To ensure the step measures the right behavior, distinguish between the action itself and the conditions that qualify it. Think of funnel steps as actions to be performed, not filters to be applied, according to PostHog. To refine your steps, you can filter out events using event, person, or group properties, autocapture elements, or SQL, according to PostHog. Use these properties to exclude events that do not represent genuine progress toward first value, such as test accounts or internal traffic.

Inspect initial path coverage

Before analyzing the data, verify what the tool displays by default. In Flows - Mixpanel, by default, Flows shows you the first 3 events performed by users after the selected event, according to Mixpanel. To adjust this conversion window, click on the words 30 days in the conversion criteria, according to Mixpanel.

After the path is counted, review usage with Customer adoption analytics: 4 tools for usage reviews.

Picture 50 users who trigger the first event. The completion window is 30 days. Inside that window, 25 users finish the remaining events in order, so the step where the count moves from 50 users to 25 users is the step that loses the most users. You also allow 2 actions to qualify for that step. 10 users complete only one of those actions, and that single action still lets them pass the step. Another 5 users trigger the first event on 2 days and finish within 30 days of both days, so both days include them. These round figures are only a rehearsal before you open the live report and record the events, the order, and the window. Walk the same order and window on paper before you change a live report.

Record these specific behaviors in your analysis notes to ensure the counting logic matches the tool you are using.

Recording how you built the report protects the analysis when you revisit it later. Today, write down the specific events you selected, the order you placed them in, and the time window you applied. Note any logical operators used to combine events and any properties used to filter them. This documentation lets you explain why a particular user appears in or out of the funnel when you discuss the account with stakeholders.

When using Flows, note that the report is accessed from the left-side navigation by clicking the '+ Create New' button, according to Mixpanel. Record this access point in your notes so you can quickly locate the report during a review. More importantly, document that coverage limitation in your file before the review. If your first-value event falls outside that limitation, it will not appear in this specific view. Flag this in your file so you do not misinterpret a missing event as a user failure; it may simply be outside the tool's current query scope.

If the primary path does not match the customer's actual behavior, use the tool's capability to dig into a particular view, for example, to explore the 2nd most popular path taken, according to Mixpanel. Record which alternative path you inspected and why.

How does onboarding path analysis show where customers stop?

It shows the step in your ordered sequence that loses the most users inside the time limit you set.

What happens when I combine several events into one funnel step?

This allows multiple actions to satisfy a single requirement in the sequence.

How does Amplitude count a user who enters the funnel on two dates?

Amplitude counts that user on both entry dates when completion is inside the window in the takeaways.

Does Mixpanel Flows include every custom event in my project?

No, Flows analysis does not include every custom event, so use the coverage limit in the takeaways and confirm your first-value event sits inside it.

How can I inspect the second most popular path?

Open the view that explores the 2nd most popular path, then record which alternative you inspected and why.

This post is general operational information, not legal advice about notice periods or renewal clauses. It does not promise that any method keeps a customer. A review model checked the facts once, and that check can miss errors, so open the sources before you act.