Cohorts

Cohorts Analysis is an industry standard that focuses on users taking one action and then repeatedly taking the same or another action over time.

One example, available in Flurry analytics, is Return Rate. In Return Rate, an app’s users are grouped, or cohorted by the Day, Week or Month they installed the app and then measured on their Daily, Weekly or Monthly usage of the app. Other variants of Cohort Analysis allow you to use Events to define the cohorting and measurement of the analysis.

Using Explorer, you can easily build and run queries that examine the behavior and performance of groups of users related by a number of common attributes.

Cohorts Analysis Basics

Cohort analysis has two major components in Explorer, both of which are defined by events:

Component Description Explorer UI
Cohort Event The event used to group users into buckets based on the first time they execute a particular event. In the UI, the field directly under the label SHOW USERS WHO FIRST DID.
Measurement Event The event used to measure the user’s behavior over time. In the UI, the measurement defined by the field with the label AND THEN DID.

Explorer Cohort analyses provide you with Daily, Weekly and Monthly bucketing for both the Cohort and Measurement definitions.

Build & Run Cohorts Queries

To build and run Cohorts queries, first navigate to Explorer as described in Getting Started.

Once you are in the Explorer UI, you can run saved queries by selecting one from the Saved Queries dropdown or create a new query by clicking the + New Query button at the right side of the page.

cohorts-new-query-dau-overall

To understand how this works, follow these steps to build the Return Rate analysis that exists in Flurry Analytics. Building this analysis in Explorer allows you to dig deeper into the data than is possible in Flurry.

  1. Define the cohorting by selecting Install in Show Users Who First Did and select Day as the grouping option.
  2. Define the measurement by selecting Session in And Then Did and again select Day as the grouping option.
  3. Click Run Query.
  4. Choose between Chart and Table views by selecting your desired reporting format above the chart.

A Return Rate Analysis

This analysis mimics what appears in the Return Rate analysis that Flurry Analytics produces.

Using Explorer, however, you can dig deeper and farther into the analysis. For example, you could see this data only for users who had performed a given event at least some number of times. For this exercise, we assume the app has an event called inAppPurchase and that we want to see Return Rate for only those users who have triggered that event at least 3 times.

To dig deeper, do this:

  1. Click + Add Filter in the Filter section.
  2. Type or Select Event.
  3. Select the event you want to filter by, in this case, inAppPurchase.
  4. Notice that the filter is then populated with
cohorts-in-app-purchase

  1. Change the 1 to 3.
  2. Now click Run Query.

The analysis has now been filtered to just users that have done the inAppPurchase event at least 3 times in their history.

To see this procedure in action, check out the Explorer Cohort Introduction Video:

Example Use Cases

The following 2 use cases provide an analysis of

  • how often a user repeats an action after taking a first action
  • how one action by a user can affect their likelihood to take another action, which can be very useful in understanding the behavior of users in your app

Use Case 1: Event Reoccurrence

One important analysis that Cohort Analysis in Explorer can undertake is looking at how often a user repeats an action after taking a first action. For example, the question “After a user makes their first purchase, how often do they repeat purchase in the next thirty days?” can be answered with Explorer (assuming you are tracking your In App Purchases).

You do this:

  1. Click + New Query to create a blank slate for the new query.
  2. In SHOW USERS WHO FIRST DID, we select inAppPurchase, as we want to start the measurement on the user’s first purchase.
  3. In AND THEN DID, we again select inAppPurchase, as we want to measure the re-occurrence of that event for the user over time.
  4. Click Run Query.

A chart appears showing the percentage of users that triggered inAppPurchase 1 day after their initial purchase. The x-axis is the date of first purchase.

  1. Above the chart, we change Day 1 to Day 7 and the chart now displays data for purchases made 7 days after the initial purchase.
  2. Finally, we can change to a table view to see the data for Days 1 through 30 presented in a table format.

Use Case 2: Event Relationships

Looking at whether one action by a user can affect their likelihood to take another action can be very useful in understanding the behavior of users in your app. This could apply in many cases such as “Do users who register engage more with the app than users that don’t?” or “Do users that have shared content with others read more content in the days following?”. For the example here, we will look at the question “Do users that join private chat rooms send more messages in general?”.

You do this:

  1. Click to create a blank slate for the new query.
  2. In SHOW USERS WHO FIRST DID, we select sendChatText, as we want to start the measurement when the user sends their first text.
  3. In AND THEN DID, we again select sendChatText, as we want to measure the reoccurrence of them sending texts over time.
  4. Now, to separate out users based on whether they have join a room or not, in the Dimensions box, select Event, and then select the joinPrivateRoom event.
  5. Click Run Query.

A chart appears showing the percentage of users who triggered sendChatText 1 day after sending their first text.

Here, the x-axis is the date the users sent their first text. The chart has two bars as it is showing the data for two groups of users, Users that have joined a private room and those that have not.

Looking at the chart, we can see that users who joined a private room are a little less likely to send a text on the day after they start, but that the effect is not consistent.