--- title: Rolling Retention: Why It Keeps Rising, With Examples description: Rolling retention counts users active on Day N or any later day, so it keeps rising as late returns arrive. Formula, worked example, traps and when to use it. url: https://retentioncohorts.com/types/rolling/ --- [Home](https://retentioncohorts.com/) / [Three types](https://retentioncohorts.com/types/) / Rolling # Rolling retention Also called unbounded, return or on-or-after retention. How it is counted, a worked example, and what it can and cannot tell you. **Short answer** Rolling retention is the share of an install cohort that opened the app on Day N or on any later day observed so far. Also called unbounded, return or on-or-after retention. In the sample app, the 1 Sep cohort's rolling Day 7 is 61%. ## What is 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.** A user counts on Day N if they opened the app on Day N or any later day up to the last day in the data. Day 0 is the install day and never counts as a return; several opens on one day count once. rolling(N) = users active on any day from Day N to the last day in the data / installs x 100 The same definition is used in [Linkrunner's glossary entry on rolling retention](https://linkrunner.io/glossary/what-is-rolling-retention?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=types-rolling&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 rolling 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 | | | | | | | | | | | | | | | | counted | | User 3 | | | | | | | | | | | | | | | | not counted | | User 4 | | | | | | | | | | | | | | | | counted | | User 5 | | | | | | | | | | | | | | | | not counted | | User 6 | | | | | | | | | | | | | | | | counted | | User 7 | | | | | | | | | | | | | | | | not counted | | User 8 | | | | | | | | | | | | | | | | not counted | | User 9 | | | | | | | | | | | | | | | | counted | | User 10 | | | | | | | | | | | | | | | | counted | Rolling Day 7: 6 of 10 = 60% The same ten users at Day 7 under the other rules: classic 30%; 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 rolling retention behave across a cohort? The 1 Sep cohort of the sample app, the only one observed to Day 14. | Day N | Users counted | Rolling retention | |---|---|---| | Day 1 | 108 of 148 | 73% | | Day 3 | 101 of 148 | 68% | | Day 7 | 91 of 148 | 61% | | Day 14 | 23 of 148 | 16% | Figure 2 ## Every cohort, counted as rolling 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 | 73 | 69 | 68 | 65 | 64 | 63 | 61 | 59 | 56 | 47 | 39 | 34 | 28 | 16 | | 2 Sep Wed 152 installs | 82 | 80 | 76 | 74 | 68 | 65 | 64 | 61 | 50 | 44 | 37 | 31 | 18 | | | 3 Sep Thu 154 installs | 79 | 75 | 73 | 72 | 68 | 66 | 62 | 47 | 42 | 34 | 24 | 13 | | | | 4 Sep Fri 142 installs | 77 | 73 | 69 | 67 | 65 | 63 | 51 | 43 | 37 | 25 | 12 | | | | | 5 Sep Sat 148 installs | 71 | 64 | 63 | 61 | 59 | 46 | 40 | 32 | 25 | 16 | | | | | | 6 Sep Sun 249 installs | 64 | 61 | 57 | 54 | 43 | 39 | 33 | 24 | 10 | | | | | | | 7 Sep Mon 262 installs | 61 | 57 | 55 | 43 | 37 | 31 | 22 | 12 | | | | | | | | 8 Sep Tue 278 installs | 67 | 59 | 49 | 44 | 37 | 27 | 13 | | | | | | | | | 9 Sep Wed 258 installs | 67 | 50 | 46 | 38 | 28 | 14 | | | | | | | | | | 10 Sep Thu 266 installs | 51 | 40 | 32 | 24 | 14 | | | | | | | | | | 0% 85%+ not reached yet **Source:** Sample data: a made-up app to show the method, not a benchmark. ## Strengths - Credits users who skip days but are still around, which suits apps used irregularly. - Answers a churn-style question: how many users have not left yet, as far as we can see? - Smooth curve: it can never rise as N grows on a fixed as-of date, so noise is lower than classic. ## Traps - It is unbounded: the same cell keeps rising as more days arrive, so a number in an old report is stale. - Older cohorts look better than newer ones simply because they have had more days to return. - On the last day in the data, rolling collapses to classic, so the newest edge of the table always looks low. - Easy to confuse with classic in a dashboard column labelled only "Day 7". ## What can rolling retention tell you? #### What you can conclude - How much of a cohort is still returning at some point, as of a stated date. - Comparisons between cohorts observed for the same length of time. - That a cohort is not yet lost, when classic looks low but rolling is high. #### What you can't - Comparisons between an old cohort and a new one (different observation windows). - A fixed figure for a board pack unless you state the as-of date. - Comparison with a classic benchmark: rolling will always flatter you. ## Compare with the other two - [01 **Classic retention** Classic retention is the share of an install cohort that opened the app on exactly Day N after installing.](https://retentioncohorts.com/types/classic/) - [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 shows rolling retention next to classic for each install cohort, so you can see how much of a number comes from late returns. - [Rolling retention in the Linkrunner glossary](https://linkrunner.io/glossary/what-is-rolling-retention?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=types-rolling&utm_content=panel) - [Retention in the Linkrunner docs](https://docs.linkrunner.io/features/retention?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=types-rolling&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-rolling&utm_content=panel) ## Questions **What is rolling retention?** Rolling retention is the share of an install cohort that opened the app on Day N or any later day observed so far. Because later days keep arriving, it is also called unbounded retention. **Why does rolling retention keep rising?** Each new day of data can add users who come back late, and rolling counts them for every earlier Day N. A cohort's rolling Day 7 therefore climbs for as long as you keep watching it. **Why is rolling retention so low for the newest cohort?** The newest cohort has only a few days of data. On its last observed day, rolling can only count that one day, so it equals classic there and looks low until more days arrive. **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.