# Behavioral cohort
behavioral cohorts are mainly used in scenarios where users are delineated by their behaviors. You may use data assets that have been created within the system and generate cohorts by simple interface configurations.
# Condition types
behavioral cohorts can be roughly divided into the following types:
Category | Condition type | Description |
|---|---|---|
User behavior | Have Done | The specified event has occurred within the specified time range. |
| Have not Done | The specified event has not occurred within the specified time range. | |
| Have done in sequence | A series of specified events have occurred within the specified time range. | |
| Have not done in sequence | A series of specified events have not occurred within the specified time range. Situations where specified events have not occurred, or have occurred but not in accordance with the specified sequence are both regarded as in conformity with the condition. | |
| User property | Property Satisfies | Users' specified property satisfies or dissatisfies a configured condition. |
A logic equation involving multiple conditions can be used to combine the cohort condition. In actual combination, identical categorical conditions are first connected by "AND" or "OR", and the logic results of the two categories are then connected by "AND" or "OR", as shown in the following figure.
# The "Have done in sequence" condition
The 「Have done in sequence」 / 「Have not done in sequence」 conditions are relatively complicated. They define the occurrence mode of a series of specified events for users (e.g., sequence, interval and same-value property) to delineate users' conditional type. The effects of configuration are as follows:
| Mode definition item | Description |
|---|---|
| Event | The sequence of the procedural events within the series is a strict sequential order, that is, simultaneous occurrence is not successive occurrence. Attention is paid only to the sequence between the configured events in the series, while whether unconfigured events will happen does not affect the result of the determination. Successively repeated occurrences of a same event is allowed as long as the relative sequence of procedural events is satisfied. |
| Time range | All procedural events within the series need to occur within the selected time range. Please note that this is different from the time range of the occurrence of the first step in funnel analysis. |
| Associated property | The property values are not void and must be identical among all events in the series. Please note that the so-called "all events" here include events occurring successively and events that have not been done between different steps. |
| Time window | The time interval between two events in the series. The upper limit of the time interval can be configured, and when time interval <= the time window, it is deemed as satisfying the condition. The interval of the number of days is not judged by natural days but by every 24 hours. |
| Have not Done between | An event that can not occur between two events. If the event occurs to the user between the two steps, it is regarded as dissatisfying the definition mode. |
More notes about special situations
- When you select exactly identical events for neighboring steps in the series, it will be deemed as the event occurs successively at least twice.
For example, in the 4-step mode of 「user registration - user obtains rewards - user obtains rewards - user payment」, the 2nd and 3rd events are exactly the same. In actual determination, 「user obtains rewards」 occurs at least twice between 「user registration」 and 「user payment」.
- When you select an event and use the custom event defined by the said event for neighboring steps in the series, it will be deemed as the event occurs successively at least twice, with one being the event itself and the other being the virtual event.
For example, in the 4-step mode of 「user registration - user obtains rewards - user obtains rewards or coupons (virtual event) - user payment」, the 2nd event 「user obtains rewards」 is used to define the 3rd-step virtual event. In actual determination, if the event 「user obtains rewards」occurs twice or more between 「user registration」 and 「user payment」, it is deemed as satisfying the mode; if 「user obtains rewards」 only happens once and no other event in the definition of 「user obtains rewards or coupons」 happens, then it is deemed as dissatisfying the mode.
- When the undone event that you configured between steps in a series is the same as events of its earlier and later steps, it will be deemed that the event can only occur once.
For example, in the 3-step mode of user registration-user obtains rewards - (undone: user obtains rewards) - user payment, there is an undone step defined between the 2nd and 3rd steps, which is 「user obtains rewards」, the same as the 2nd step. In actual determination, if the event 「user obtains rewards」 occurs twice or more between 「user registration」 and 「user payment」, it is deemed as dissatisfying the mode.If 「user obtains rewards」 only happens once, then it is deemed as satisfying the mode.