While users are counted only once within the People column of each cohort (based on distinct_id) in Retention reports, users can exist in multiple rows. This allows you to capture the activity patterns of active users regardless of whether those users have performed an Event before.
Let’s take a user who:
Made a purchase on June 1
Made a purchase on June 2
Made a purchase on June 17
In this Retention report, the user would be represented:
Once in the People column for the May 29 cohort (even though she made two purchases during this week)
In the People column for the June 12 cohort
In the <1 wk column in the May 29 cohort, representing her second purchase that week on June 2
In the 2 column in the May 29 cohort, representing her purchase on June 17
The Cohorts builder allows you to define and save definitions of custom user groups that you can use when filtering for users in other reports. Just as with any row in the retention report, the user is counted in every row of the retention report that they qualify for. This means that a user may be counted in multiple custom cohorts viewed in Retention.
What if I don’t want users in multiple rows?
Use Cohorts to define a user group based on property or event conditions unique to that group. As another option, you can use a First Time Retention report to define a group of users based on a one-time Event (like Signup) rather than a particular date range so that users are only included in one cohort:
If you don’t have a one-time Event like Signup, you could alternatively add a Property (such as “First time = true”) to an existing Event that happens more than once (like Page Load or App Open) and use that in the First Time Retention report to ensure users are only included in one row.