Docs
Event Analytics
Funnels

Funnels

Funnels are the basic building block of event analytics. They provide a way to see how an entity (or set of entities) completes a sequence of steps.

Configuration

Event sequence

The event sequence is the ordered list of events which an entity must perform to complete the funnel. Event sequences can be edited during explore, or defined in the model for quicker access and sharing.

Steps are just a named condition to match a given event to. The most common condition is simply matching the name of an event. You can click the settings icon next to a step to edit the conditions directly. Using this, you can specify more nuanced steps, such as "a view_page event with '/blog' in the URL" instead of just "a view_page event".

Filters

Filters are applied to the query before any funneling logic occurs. Since funnel queries can be more expensive than standard aggregates, this can be used to reduce the amount of data you are processing, or to focus your analysis to a particular time region or segment.

Note that if you apply a historical timestamp filter, you may see lower conversion rates toward the end of the time window. The entity may not have had time to finish the funnel before the filter cut the data off.

Time limit

The time limit sets the maximum duration which an entity can take to complete the event sequence. Hashboard will match the first event as normal. Subsequent events for that entity must all occur within the time limit of their first event. After the time limit is up, all their future events will be ignored.

All entities are still evaluated only a single time. If an entity entered a funnel, timed out, and then later re-entered the funnel and succeeded, they would still be counted as not converting, as their "first attempt" at the funnel timed out.

Breakouts & segmentation

You can break out a funnel to see how different user segments perform, or compare the effect of differences in the first step.

When breaking out on an attribute related to the entity, such as a user's membership_type, this works like a standard GROUP BY. Each user is only evaluated once, and then bucketed into separate groups based on the breakout. No overlap will occur.

When breaking out on other attributes, Hashboard runs parallel analyses, with variations on the the conditions for the initial step. All entities and events are shared between each analysis.

Example

For example, imagine a simple funnel with steps ad_impression -> purchase. This analysis answers the question "how many users saw an ad then made a purchase?"

We then break out on platform, which will split funnels based on the platform users received the ad_impression on. If we have "mobile" and "desktop" platforms, then this will answer two correlated questions:
- "how many users saw an ad on mobile and then made a purchase?"
- "how many users saw an ad on desktop and then made a purchase?"

If a given user saw an ad on both mobile and on desktop, then they would appear in both the "mobile" and "desktop" segments.

How it works

The main task of funnel analysis is matching event data to form "journeys" for each entity, a path of events where each event maps to the next sequence step.

For each entity, we search for an event of theirs which matches the first step of the funnel. For all the entities for whom we found an event, we look for another event of theirs which matches the second step of the funnel, and occurs after their first event. For all the entities for whom we found a matching second event, we look for another event of theirs which matches the third step of the funnel, and occurs after their second event. This process can repeat for up 62 distinct steps.

Breakouts further partition this, so instead of evaluating each entity, we evaluate each distinct entity:breakout-value pair.

Performing the process described above directly in SQL would be highly inefficient. Instead, we implement the SQL using a technique in which event types are hashed to string characters, concatenated together, and then searched for matches using regular expressions. A similar approach to ours is outlined in this blog post (opens in a new tab). This technique results in a complex, but efficient query. If you need help debugging these queries, feel free to reach out to our team.