The group by clause allows you to break down queries even further by creating groups within reports based on user and event-level properties.
Heap automatically captures certain user properties, such as date first seen and other first touch (initial) properties. A full list of all properties which are automatically captured is available in the Autocaptured Properties doc. You can also define additional properties, such as account type, LTV, and more using our addEventProperties API.
To segment your analysis by one or more of these user-level properties, simply click the '+ Add Group By' button, and select your property.
Grouping by a user-level property allows you to get an in-depth picture of who is using your product. As an example: within Heap, there are six analysis tools: graphs, funnels, retention, users, influence, and paths. Using a multigraph, we can compare how frequently each of these features is used, which helps our product team prioritize which features to work on.
When we group this multigraph by job title, we are not only comparing which features are being used most frequently, but also comparing who is using them. A marketer needs a different feature set than someone in sales or design.
This provides actionable insight into how we should prioritize our features and who we need to build features for.
You can also use a multigraph + a group by to compare the effectiveness of different campaigns, landing pages, blog posts, and more across different groups of users. In this example, we can compare three different blog posts and their conversion rate for signups based on the region. Looking at the results, it’s clear that some blog posts are more effective than others in different regions. This enables our outbound team to adjust their strategy when getting prospects to sign up for Heap.
When using funnels, conversion rate over time, and average time between, you can segment your data by grouping by an event-level property.
When you group by the property of the first event in a funnel (or any intermediate event), we calculate the conversion rate by bucketing the user into the instance of the event immediately before a conversion. If the user has not completed the rest of the funnel, we use the most recent value of the event’s property. Each user will only be included in one bucket, and if a user completes a funnel multiple times, we will use the data from their first conversion.
For example, in an A→ B→ C funnel:
- Bob does event A with path /home, event A with path /blog > event B > event C
- Tammy does event A with path /home
- Beth does event A with path /home > event B > event C
The results will be as follows:
When you group by the properties of the last event in the funnel, users will be bucketed into categories based on the first instance of the last event (the first conversion). As above, each user will only be included in one bucket, and if a user completes a funnel multiple times, we will use the data from their first conversion.
For example, in the funnel A → B:
- Bob does event A > event A > event B with Referrer Google, B with Referrer Facebook
- Tammy does event A > event B with Referrer Facebook
- Beth does event A
The results will be as follows:
You can group by event-level properties in the graph (including average time between and conversion rate between queries) and in the funnel modules.
Grouping by the first or intermediate step of a funnel provides insight into what was happening immediately before the conversion. In this example, we compare the effectiveness of different marketing pages by grouping by the marketing page immediately preceding the Sign Up event.
This example can be adapted to see which collection was viewed before checking out, or which product was viewed before adding to the cart.