How it works
Each cohort is a row and each column is time since install: day 0, day 1, day 7, day 30. The cells hold a metric for that cohort at that age, such as the share of users still active, revenue per user or the number of purchases. Cohorts can be narrowed by campaign, network, country or app version. Reading down a column shows whether newer cohorts do better or worse than older ones at the same age. Reading along a row shows how one cohort matures.
Why it matters for an app team
Daily totals mix new and old users, so a burst of installs can hide the fact that each new user is worth less. Cohorts separate the two. They are the basis for retention, LTV and ROAS, and the quickest way to see whether a product change or a new traffic source improved the quality of users.
In practice
Example with made-up numbers: the cohort that installed in the first week of May has 2,000 users and a day-7 retention of 18%. The cohort from the second week, after a new onboarding flow shipped, has 2,200 users and a day-7 retention of 23%. Daily active users barely moved, but the cohorts show that the change worked.
Common confusion
A cohort table is incomplete by design: last week's cohort has no day-30 value yet, so do not compare it with one that does. Small cohorts swing widely, and a campaign with 40 installs can show almost any retention figure by chance. Cohort revenue is assigned to the install date, not to the day the money came in, so it does not match finance reports for the same calendar period.