--- title: Classic Retention: Definition, Formula and Example description: Classic retention counts users active on exactly Day N. See the formula, a worked example on sample users, its strengths, traps and the conclusions it supports. url: https://retentioncohorts.com/types/classic/ --- [Home](https://retentioncohorts.com/) / [Three types](https://retentioncohorts.com/types/) / Classic # Classic retention Also called N-day, Day-N or exact-day retention. How it is counted, a worked example, and what it can and cannot tell you. **Short answer** Classic retention is the share of an install cohort that opened the app on exactly Day N after installing. Also called N-day, Day-N or exact-day retention. In the sample app, the 1 Sep cohort's classic Day 7 is 16%. ## What is classic retention? **Classic retention is the share of an install cohort that opened the app on exactly Day N after installing.** A user counts on Day N if they opened the app on exactly Day N. Activity on any other day does not count. Day 0 is the install day and never counts as a return; several opens on one day count once. classic(N) = users active on Day N / installs in the cohort x 100 The same definition is used in [Linkrunner's glossary entry on classic retention](https://linkrunner.io/glossary/what-is-classic-retention?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=types-classic&utm_content=inline), so the numbers here line up with tools that follow it. Figure 1 ## Worked example: ten users Ten made-up users over 14 days, counted with the classic rule at Day 7. Shaded columns are the days that count. | | D0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | | |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| | User 1 | | | | | | | | | | | | | | | | counted | | User 2 | | | | | | | | | | | | | | | | not counted | | User 3 | | | | | | | | | | | | | | | | not counted | | User 4 | | | | | | | | | | | | | | | | counted | | User 5 | | | | | | | | | | | | | | | | not counted | | User 6 | | | | | | | | | | | | | | | | not counted | | User 7 | | | | | | | | | | | | | | | | not counted | | User 8 | | | | | | | | | | | | | | | | not counted | | User 9 | | | | | | | | | | | | | | | | counted | | User 10 | | | | | | | | | | | | | | | | not counted | Classic Day 7: 3 of 10 = 30% The same ten users at Day 7 under the other rules: rolling 60%; cumulative 80%. Try other days in the [ten-users view](https://retentioncohorts.com/#ten-users). **Source:** Sample data: a made-up app to show the method, not a benchmark. ## How does classic retention behave across a cohort? The 1 Sep cohort of the sample app, the only one observed to Day 14. | Day N | Users counted | Classic retention | |---|---|---| | Day 1 | 51 of 148 | 34% | | Day 3 | 42 of 148 | 28% | | Day 7 | 23 of 148 | 16% | | Day 14 | 23 of 148 | 16% | Figure 2 ## Every cohort, counted as classic Rows are install days, columns are days since install. | Install cohort | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13 | D14 | |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| | 1 Sep Tue 148 installs | 34 | 23 | 28 | 24 | 19 | 16 | 16 | 16 | 27 | 18 | 8 | 17 | 15 | 16 | | 2 Sep Wed 152 installs | 34 | 36 | 32 | 28 | 24 | 20 | 19 | 36 | 14 | 18 | 17 | 17 | 18 | | | 3 Sep Thu 154 installs | 41 | 30 | 23 | 27 | 27 | 23 | 38 | 18 | 13 | 18 | 13 | 13 | | | | 4 Sep Fri 142 installs | 38 | 26 | 22 | 21 | 18 | 35 | 20 | 18 | 15 | 14 | 12 | | | | | 5 Sep Sat 148 installs | 36 | 27 | 26 | 26 | 39 | 20 | 16 | 12 | 12 | 16 | | | | | | 6 Sep Sun 249 installs | 29 | 26 | 22 | 36 | 17 | 14 | 15 | 16 | 10 | | | | | | | 7 Sep Mon 262 installs | 29 | 20 | 39 | 16 | 17 | 16 | 13 | 12 | | | | | | | | 8 Sep Tue 278 installs | 32 | 42 | 21 | 21 | 18 | 19 | 13 | | | | | | | | | 9 Sep Wed 258 installs | 52 | 25 | 20 | 19 | 17 | 14 | | | | | | | | | | 10 Sep Thu 266 installs | 31 | 20 | 18 | 15 | 14 | | | | | | | | | | 0% 85%+ not reached yet **Source:** Sample data: a made-up app to show the method, not a benchmark. ## Strengths - Fixed once Day N has passed, so a number in last month's report never changes. - The definition most published benchmarks use, so it is the fair one for outside comparison. - Shows calendar events clearly: a release or a push lights up one diagonal of the table. - Each point on the curve is the share of users active that day, which is what forecasts of active users need. ## Traps - Punishes apps people use weekly or irregularly: a loyal user who skips the exact day is not counted. - Noisy day to day, especially on small cohorts and around weekends or campaigns. - A bump on one day (a push notification) can look like better users when it is a one-day event. ## What can classic retention tell you? #### What you can conclude - Whether one cohort was more active on a given day than another at the same age. - Whether a change on a specific day moved activity on that day (read the diagonal). - How your exact-day number compares with a published benchmark that uses the same definition. #### What you can't - Whether a user has churned: absent on Day 7 does not mean gone. - How many users came back at least once (that is cumulative). - Anything from one small cohort on one day without checking its neighbours. ## Compare with the other two - [01 **Rolling retention** Rolling retention is the share of an install cohort that opened the app on Day N or on any later day observed so far.](https://retentioncohorts.com/types/rolling/) - [02 **Cumulative retention** Cumulative retention is the share of an install cohort that opened the app at least once between Day 1 and Day N.](https://retentioncohorts.com/types/cumulative/) - [03 **All three side by side** One table with the rule, the boundedness and the best use of each.](https://retentioncohorts.com/types/) See this on your own app Linkrunner counts classic retention with the same exact-day rule as this page and shows it next to rolling and cumulative for each install cohort. - [Classic retention in the Linkrunner glossary](https://linkrunner.io/glossary/what-is-classic-retention?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=types-classic&utm_content=panel) - [Retention in the Linkrunner docs](https://docs.linkrunner.io/features/retention?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=types-classic&utm_content=panel) - [Create a free account (25k installs free)](https://dashboard.linkrunner.io/sign-in?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=types-classic&utm_content=panel) ## Questions **What is classic retention?** Classic retention is the share of an install cohort that opened the app on exactly Day N after installing. It is also called N-day or Day-N retention, and it is fixed once Day N has passed. **Is N-day retention the same as classic retention?** Yes. N-day, Day-N, exact-day and classic retention are names for the same rule: count users active on exactly the Nth day after install. Always check which day counts as Day 0 in your tool. **Why is classic retention lower than rolling or cumulative?** Classic only credits activity on one day. Rolling and cumulative both include that day plus other days, so they can never be lower than classic for the same cohort and Day N. **What is the difference between classic, rolling and cumulative retention?** Classic counts users active on exactly Day N. Rolling counts users active on Day N or any later day, and cumulative counts users active at least once from Day 1 to Day N. They use the same raw activity but answer different questions. **Why is my rolling retention higher than classic?** Rolling also counts users who skipped Day N but came back later, so it can never be lower than classic. The gap grows the longer a cohort has been observed, because late returns keep adding to it. **What is cumulative retention?** Cumulative retention is the share of an install cohort that opened the app at least once between Day 1 and Day N. It never falls as N grows and it is fixed once Day N has passed, which makes it a good activation measure.