Cohorts
Cohorts are one of the data tools the system provides for segmenting users. A cohort can be understood as a set of users selected from all users. You can create a cohort from a batch of users, or from a data condition (that is, a rule for selecting users), and then use it in analysis and operations. Each cohort divides users into two groups: users in the cohort and users not in the cohort.
Compared with user tags, which label users, cohorts are more about selecting users. The user sets selected this way are fairly purpose-specific, so we generally recommend using each cohort for only one scenario. For example, a cohort "Participants of a specific event" can be used to analyze the event's impact on retention, and a cohort "Users who earned more than 500 points in the last 3 days" can be used to distribute rewards for daily point tasks.
1. Create a cohort
In Users - Cohorts, create a Behavioral cohort, ID cohort, or SQL cohort:
In an analysis result table, create a Result Cohort:
You can create a cohort in several ways. The following table compares the types:
| Definition method | Cohort type | Description |
|---|---|---|
ID set (Saves the set of IDs contained in the cohort directly as the cohort. The scope of a cohort defined this way almost never changes.) | ID cohort |
|
Result Cohort |
| |
Data condition (Saves the calculation rule as the cohort definition. Each time the cohort is calculated by the rule, whether a user joins the cohort depends on whether the user currently meets the rule. The default project limit for this type of cohort is 200.) | Behavioral cohort |
|
| SQL cohort |
|
When you create a cohort, in addition to its ID set or data condition, you also need to select its entity and time zone.
Entity
Cohorts are a tool for segmenting users, and there are many kinds of user identifiers, such as device ID, account ID, character ID, and platform ID. In project configuration, you can add user identifiers (properties) other than the AE user ID as entities. These entities can also be segmented with cohorts.
When you create a cohort, first select its entity. The calculated result is a set of that entity, and the Users in cohort count you see is also the number of that entity. Note that when the selected entity was created from an event property, behavioral cohorts can't use the Have not done or Have not done in sequence condition.
Timezone
If your project has Time Zone Converter turned on (in project configuration), you also need to select the cohort's settlement time zone first when you create a cohort. If the definition of a behavioral cohort or SQL cohort uses event data, the time range in event conditions is by default the time range in the cohort's time zone. Events reported in other time zones are offset first and then checked against the event conditions.
Note that if you choose a different time zone to view dashboards and reports during analysis, the cohort data used is the pre-computed result, and its settlement time zone doesn't change accordingly.
2. Update cohorts
Cohorts are pre-computed data (as opposed to ad hoc queries). That is, the system calculates cohorts in advance and then uses the result data in later analysis and operations, instead of calculating a cohort ad hoc each time it is used. Pre-computation greatly reduces computational complexity at use time and avoids repeated calculation, which improves data efficiency, but at the cost of data freshness (for cohorts defined by data conditions). For most analysis scenarios, cohorts updated daily are sufficient, while operations scenarios have higher freshness requirements for cohorts.
Behavioral cohorts and SQL cohorts are defined by data conditions, and the system supports multiple update modes, as described below:
| Update Mode | Description |
|---|---|
| Scheduled | If you turn on the Scheduled Update switch of a behavioral cohort or SQL cohort when you create or edit it, the system automatically updates the cohort at the scheduled time every day. ID cohorts and result cohorts don't support this update mode. |
| Manual | Behavioral cohorts and SQL cohorts can be updated manually. When you need the latest cohort data, you can trigger an update manually. ID cohorts must be updated by importing a new file again. Result cohorts don't support manual updates. |
| Update with Dependents | If the audience of an operation task uses this cohort, the cohort is calculated once before the push. |
| System-triggered | Cohort updates triggered by other system features. If your project has the Engage module deployed, the system automatically triggers cohort updates based on operation task configurations. |
| Create calculation | Every cohort is calculated once immediately after it is created. |
| Edit calculation | After you change the conditions or time zone of a behavioral cohort and save it, it is calculated once immediately. |
Note that because user and event data in the system is updated in real time, you can use event conditions for Today in a cohort definition, but cohort calculation can only use today's data up to the time of calculation. To use full-day data, use event conditions that end yesterday.
3. Manage cohorts
Cohorts created in the four modules Analytics, Engage, Users, and API can all be viewed in Users - Cohorts. If the module that created a cohort allows it to be publicly managed, you can also delete, update, and edit the cohort here.
In Cohorts, you can quickly filter the cohorts created by the Analytics, Engage, and API modules by creation source. Cohorts not created in the Users module are also marked with their creation source after the cohort name, so they are easy to find.
The management actions available in Cohorts are listed below. Different actions have different requirements for the cohort type, cohort settings, and operator permissions. See the following table:
| Management action | The action is available when all of the following conditions are met |
|---|---|
Manual Update |
|
Edit Cohort |
|
Download imported data and errors |
|
Duplicate |
|
| Delete cohort |
|
Because cohorts can be used by assets such as reports, cohorts (created in the Engage module), and alerts, modifying or deleting a cohort can cause abnormal fluctuations in these assets' data or even make them impossible to calculate. When a cohort you delete or edit has dependent assets, its scope of impact is shown, and you need to assess the impact before you continue to delete or modify it.
4. Cohort user list
After a cohort is calculated, you can view the number of users in it in Cohorts, and click the number to view the list of users in the cohort.
In the user list, you can view the cohort's condition definition (behavioral cohorts and SQL cohorts) and the user list. The table shows data for up to 1,000 users. For more data, click the download button in the upper-right corner of the table to download data for up to 500,000 users.
Note that clicking update in the upper-right corner of the table on the user list page only re-queries the cohort result data and doesn't recalculate the cohort itself, but the property data of the cohort users may change.
5. Usage permissions
- Analytics roles
| Root | Admin | Analyst | Member | |
|---|---|---|---|---|
| View cohort list | ● | ● | ● | ○ |
| Add, edit, and delete own behavioral/ID cohorts | ● | ● | △ | ○ |
| Add, edit, and delete own SQL cohorts | ● | ● | △ | ○ |
| Add, edit, and delete own result cohorts | ● | ● | ▲ | ○ |
| Edit and delete others' cohorts | ● | △ | ○ | ○ |
- Engage roles
| Engage Admin | Engage | Data Engineer | |
|---|---|---|---|
| View cohort list | ● | ▲ | △ |
| Add, edit, and delete own behavioral/ID cohorts | ● | ▲ | △ |
| Cohort drill-down - View user list | ● | ▲ | △ |
Permission notes:
● The role always has this permission
▲ The role has this permission by default, but it can be removed
△ The role doesn't have this permission by default, but it can be granted
○ The role never has this permission