Retention rates in the Adjust platform have just been updated to better reflect retention of users from timezones that significantly diverge from UTC.
Up until now, the “day” of a given retention rate has been defined in UTC, as with everything else in the underlying Adjust platform. UTC is the “base” timezone (roughly equal to GMT or London time, without daylight savings), and every other timezone is defined as a number of hours before or after UTC.
From today onwards, we will instead define a “day” of retention as a 24-hour period starting at the original time of install. For example, a user first opening an app at 17:00 UTC will count toward day-zero (day of install) retention until 16:59 UTC the next day; any activity in the following 24 hours will be counted toward day-1 retention.
The problem with defining the day as UTC was primarily users that fell around the edges. With the old definition, a user installing at 23:45 UTC – which can be in the middle of the day, depending on their timezone – would only need to be active for about 20 minutes before contributing to day-1 retention. The result was a “fuzzing” of retention rates for userbases with a heavy presence in the most distant timezones, e.g. in timezones in and around the Pacific, where individual days would melt into each other.
This didn’t affect the broader trends, but made benchmarking between userbases a bit more difficult, and wasn’t comparative across apps. That’s one of our core goals behind our metrics – comparative, accurate measurement of results.
This new definition is timezone-agnostic. By defining the “day” as the first 24 hours after time of install, it’s consistent for that user around the world, but also accurately reflects how long the user will remain active after the install.
The new retention rate metric may diverge from your existing metrics to a small degree, depending on how you have segmented your user base and your active markets.
If you have any questions, feel free to reach out to the team at email@example.com.