Аналитики devtodev Катя Нагорная и Василий Сабиров разбирают разницу в методах расчёта удержания и объясняют, почему важно понимать, как ваша аналитическая система считает эту метрику.
О чём речь?
Retention как главный показатель удержания пользователей - очень важная метрика. По retention судят о том, насколько хорош проект и как пользователи к нему относятся. Ведь если плохое удержание, то о монетизации чаще всего нечего говорить. Есть разные виды retention (классический, rolling, full и др.). Вне зависимости от способов, удержание всегда рассматривают в разрезе дней с момента установки.
И тогда возникает вопрос: а что такое в данном случае день? День - это надпись на календаре? Ведь пользователи находятся в разных часовых поясах, команда может быть распределенной, и будет разница во времени между аналитиком и геймдизайнером. А сервера вообще могут быть на Филиппинах. Что делать в таких случаях?
Задавшись этими вопросами, кто-то определяет для себя одну таймзону, по которой ведутся расчеты метрики удержания (да и остальные тоже).
А некоторые идут дальше и решают, что retention можно рассчитывать для каждого пользователя, отсчитывая его 24 часа с момента первого входа. То есть удержание можно считать по календарным дням, а можно считать по часам от самого первого входа пользователя.
А в чём разница?
При расчете календарного retention, например, 1-го дня, учитывается вход в интервале от 0 до 48 часов с момента установки.
-
Почему от 0? Потому что пользователь может установить приложение в 23:50 3 сентября, а войти уже в 00:10 4 сентября (ну отвлек его кот, который захотел есть).
-
Почему до 48? Потому что пользователь может установить приложение в 00:10 3 сентября, а войти только в 23:50 4 сентября. Вот так здесь все широко. Но 0 и 48 часов - это, скорее, исключения. В среднем пользователи попадают во временной промежуток 12-36 часов.
А если вы рассчитываете почасовой retention, то здесь все более определенно: вход пользователя для расчета retention 1-го дня считается строго от 24 до 48 часов с момента установки. Поэтому неудивительно, что значения retention, рассчитанного таким способом, будут ниже, но при этом более точными, ближе к исконному смыслу понятия retention.
Ничего не понятно, можно ещё раз?
Поясним графически.
Выше вы видите календарный способ, ниже - почасовой. Рассмотрим трех пользователей А, В и С, которые зарегистрировались 1-го июня.
При календарном способе все довольно просто с графической точки зрения: все пользователи, которые входили 2-го июля, посчитались для ретеншен 1-го дня. И даже пользователь С, между визитом и регистрацией которого прошел всего лишь час, свой вход совершил 2-го июля, что относит его к retention 1-го дня.
При почасовом способе мы при визите смотрим, сколько прошло времени с момента регистрации. И если в случае с пользователем А все очевидно, то визиты пользователей В и С не попадут в расчет retention 1-го дня: хоть они и зашли в приложение 2-го июля, но с момента их регистрации прошло не более 24-ч часов.
А что на практике?
Теперь давайте сравним два способа расчета retention на примере трех разных по объему аудитории игровых проектов. Назовем их Small, Medium и Large. Такие названия соответствуют среднему количеству новых пользователей за период (месяц в нашем случае). Для Small среднее количество новых пользователей ~ 150, Medium ~ 3 500, Large ~ 15 500.
Ниже представлены графики сравнения кривых retention, рассчитанного по дням и по часам.
Две кривые имеют равные значения на 7-й день и далее.
Для проекта Medium значения retention становятся равными с 10-го дня.
В Large кривые сближаются с 11-го дня, а после 25-го почасовая кривая становится выше календарной.
На всех графиках видно, что календарный retention выше, чем этот же показатель, рассчитанный по часам. И в первые дни разница почти в 10 процентных пунктов (что много). Но постепенно линии склеиваются, и разница между метрикой, рассчитанной разными способами, становится минимальной либо исчезает совсем.
На следующем графике приведено отношение почасового retention к календарному.
Из этого графика видно, что это отношение уменьшается значительно с 1-го по 5-й дни (почти как кривая retention, только в обратную сторону), а дальше более плавно и приближается к 100%, что означает равенство. В некоторых точках retention по часам превышает retention по дням (как, например, у проекта Small, и это обусловлено малым объемом выборки).
Что в первые дни кажется большой разницей в значениях, в долгосрочной перспективе оказывается все тем же retention.
Как это реализовано в devtodev?
Мы в devtodev считаем retention обоими способами, но по умолчанию - именно по часам.
Почему так? Мы считаем, что данный способ расчета точнее и четче отображает поведение пользователей. Для данного расчета не важен часовой пояс и расчет 24-x часов производится для каждого пользователя с момента установки приложения.
И ещё один бонус
Также при расчете retention по часам появляется новое значение метрики - retention 0-го дня. Это значение рассчитывается для пользователей, которые совершили повторный вход в приложение в течение 24-х часов с момента первого входа. Данная метрика чаще всего будет выше retention 1-го дня, рассчитанного календарным способом. Ведь при первом знакомстве пользователь, которому понравилась игра, будет запускать ее снова и снова, отложив на время уже известные ему игры.
Резюмируем
Где бы вы ни были и какой бы системой для анализа игр не пользовались, имейте в виду, что retention в них может считаться по-разному. И ответить на вопрос “а где правильно?” нельзя, равно как и считать верным то значение, которое выше.
Не так страшна разница в показателях в разных системах, как страшны:
а) разнонаправленная динамика одного и того же показателя;
б) непонимание вами правил расчёта этих показателей.
Вот от этого мы и хотим предостеречь вас данной статьей.
