Reengagement refers to the percentage of users that used the app yesterday and were also active today (regardless of their install date). Reengagement is based on a 24-hour rolling clock and users can contribute to this KPI only once per day. Day 1 reengagement, for example, is the percentage of users who started a session on the app today and at least once between the last 24 hours and 48 hours.
Reengagement provides you with a measurement for the ‘stickiness’ of your app. This information can help you to identify whether a recent update to your app is causing your customers to use the app more frequently or whether it is alienating new users.
Viewing reengagement data
The KPI Metrics dashboard and Trend Reports provide you with graphs depicting reengagement data.
The following figure shows the Day 1, Day 3 and Day 7 Reengagement KPIs in a sample Trend Report, where:
- 2,663 is the number of users who engaged with the app on December 13th and who also used it during the previous day.
- 4,334 is the number of users who engaged with the app on December 13th and who also used it at some point during the previous three days.
- 5,995 is the number of users who engaged with the app on December 13th and who also used it within the past week.
Understanding reengagement data
From a high level point of view, reengagement can be considered to be the number of users who have recently used your app and have now returned to use it again. A more accurate definition states that the day-N reengagement for a given day represents the number of users who started a session on your app today and have also previously started a session at least once in between ((x + 1) * 24)) and 24 hours ago.
Imagine that you are investigating Day 1 Reengagement and that today a session_start event is received from a user. If this user started a session at least once between 48 and 24 hours ago, the Day 1 Reengagement KPI is incremented by one for the current day (with the understanding that a user can only contribute once a day to a reengagement KPI).
Note that only the hour granularity of the event times is taken into account when searching for any previous logins in between 48 and 24 hours ago. In the case of Day 1 Reengagement, this means that a user who starts a session for the first time at 2018-12-11 02:15 and a second time at 2018-12-12 02:16 does not count as day-1 reengaged. While these two timestamps are indeed 24 hours and 1 minute apart (which is more than 24 hours), only the hour granularity is taken into account. The time difference between 2018-12-11 02:00 and 2014-12-12 02:00 is used, which reduces the time between the two events to 24 hours. If the second timestamp was 2018-12-12 03:00, then the time between the two events would be calculated as 25 hours, making the user day-1 reengaged.
Why not a percentage?
The reason that Swrve does not display reengagement as a percentage is best illustrated by means of an example. Imagine that you have an app with a steady 100 DAU and a daily Day 1 Reengagement of 40 (40%). One day you suddenly receive an influx of 2,000 new users. This enormous influx causes Day 1 Reengagement to suddenly drop from 40% to just 1.9% (40/2,100). So even though your app is performing well, your Day 1 Reengagement suggests that it is performing very badly. Swrve displays reengagement as an absolute number in order to avoid this type of scenario.
The example scenarios below illustrate how day-N reengagement is calculated.
Imagine a user who starts a session for the first time at 2018-12-11 02:15 and a second time at 2018-12-12 03:00. As this user’s previous session start time was between 48 and 24 hours ago, this user is day-1 reengaged and causes the Day 1 Reengagement KPI for day 2018-12-12 to be incremented by one. However, this user is also day 3 reengaged as this user’s previous session start time was between 96 and 24 hours ago. This user therefore also caused the Day 3 Reengagement KPI for day 2018-12-12 to be incremented by one. A similar reasoning shows that the Day 7 Reengagement KPI is also incremented by this user.
This means that the Day 7 Reengagement KPI also includes those users who are day 3 and day 1 reengaged. Similarly, the Day 3 Reengagement KPI also includes users that are day-1 reengaged. A side effect of this is that the Day 7 Reengagement KPI is always larger than the Day 3 Reengagement KPI, which in turn is always be larger than the Day 1 Reengagement KPI.
Imagine a user who only uses the app twice and then never uses it again. If this user starts a session at 2018-12-11 02:10 and 2018-12-11 08:10, then this user has no impact on any of the reengagement KPIs as the two sessions are less than 24 hours apart. However, if a new user starts a session at 2018-12-11 02:15 and 2018-12-12 03:00 and then never uses the app again, something different happens. This user now influences the reengagement KPIs for day 2018-12-12, even though the user is not really a recurring user. This is simply a side effect of Swrve choosing 24 hours as the minimum amount of time that there has to be between recent logons before considering a user as reengaged.
Imagine a user who starts a session every 14 hours over a period of a month or so. Upon their first session start, the user is not marked as reengaged as, at that point, they have no previous sessions. Upon their second session start, this user is still not marked as reengaged as this session start is less than 24 hours ago. It isn’t until their third session start that the user is marked as reengaged, as this is 28 hours after the first one. So users who use your app a lot are eventually counted as day-1 reengaged (and day-3 and day-7 reengaged). On the other hand, a user who starts a session every 30 hours contributes to Day 1 Reengagement (and Day 3 and Day 7) with each successive session start.