Показатель Retention считают если не все, то многие из тех, кто работает над веб- и мобильными проектами.
Это важнейший показатель проекта, который в первую очередь говорит об удержании пользователей: retention дня N рассчитывается как доля пользователей, которые входили в проект на день N после первого входа.
Однако важен он не только как показатель удержания: это один из факторов, влияющих на доход с пользователя. Логично, чем дольше пользователь в проекте, тем выше вероятность, что он заплатит. Более того, наши исследования показывают, что со временем выше не только вероятность платежа, но и его размер: кто дольше в проекте, тот платит больше.
Ещё одной особенностью показателя retention является то, что он очень чувствителен к любым изменениям в проекте. Любое изменение хоть в первой сессии, хоть в основном цикле приложения, отражается на retention, и чем раньше посчитан retention, тем более он чувствителен.
Приходим к тому, что retention важно замерять регулярно и реагировать на его изменения.
А теперь тот самый нюанс, вынесенный в заголовок статьи.
Вы точно знаете, как у вас рассчитан retention?
- Какое событие считается за точку отсчёта?
- Какое событие говорит вам о том, что пользователь вернулся?
- Что такое “день”, когда мы говорим о retention дня N? Это календарный день или 24-часовой интервал?
- А если календарный день, то по какому времени он посчитан?
Если вы не можете ответить на эти вопросы, я очень рекомендую узнать ответ у вашей аналитической системы. Возможно, вы понимаете retention не так, как они.
Кстати, именно разница в методах расчёта является основной причиной того, что retention, посчитанный в разных системах, не сходится.
Вернёмся к тому, как задавать понятие “дня” при расчёте retention. Если ваши пользователи сосредоточены в одном часовом поясе, то можно просто настроить серверное время так, чтобы их время совпадало с вашим, и быть уверенным в том, что retention считается 100% точно, по крайней мере до тех пор, пока не появился пользователь из другого часового пояса.
А на практике очень часто (да практически всегда!) бывает так, что пользователи раскиданы по разным часовым поясам, притом иногда разница между поясами составляет не 1 и не 2 часа.
Скажем, если 50% ваших пользователей проживает в Европе, а 50% — в США, то как считать retention в этом случае? Что называть календарным днём?
Проблема даже не в том, что на этот вопрос ответить непросто. А в том, что любое изменение в процентном соотношении пользователей между Европой и США повлияет на чуткий показатель retention, и вы можете ошибочно предположить, что среднее удержание увеличилось или уменьшилось, а затем принять неверное решение на этом основании.
Как можно решить эту проблему?
Например, в devtodev мы считаем retention двумя способами, по выбору:
- в одном случае мы считаем retention по календарным дням, причём время устанавливает сам клиент;
- в другом же случае мы считаем retention по 24-часовым интервалам: например, пользователь попадает в retention первого дня, если он имел хотя бы один повторный вход спустя 24-48 часов после первого входа.
Что изменилось у проектов?
У кого-то не изменилось практически ничего. В основном это относится к проектам, у которых а) мало пользователей, б) все они сосредоточены в одном часовом поясе.
А у некоторых показатель retention day 1 изменился на 4-5%! Учитывая, что среднее значение retention первого дня — порядка 30%, то колебания в 4-5% — это критично.
Что изменилось у нас?
После того, как мы ввели возможность расчёта retention по 24-часовым интервалам, мы смогли сформулировать новую для себя метрику:
day 0 retention
Это доля пользователей, которые совершали повторный вход спустя 0-24 часа после первого входа. Доля тех, кто заинтересовался и решил совершить вторую сессию, притом в первые же часы после начала.
В среднем day 0 retention на 30-40% в относительных значениях выше, чем day 1 retention.
Вкупе с метриками Tutorial conversion и day 1 retention, показатель удержания нулевого дня становится ещё одной важной метрикой, позволяющей отследить поведение пользователей на раннем этапе.
И если раньше мы могли отследить лишь повторный визит пользователя на следующий день (посчитанный для разных пользователей по-разному), то теперь мы можем просчитать и прохождение туториала, и вторую сессию в те же сутки, и лишь потом обратиться к day 1 retention, будучи уверенными в том, что он считается точно.
Резюмируем
- Retention — чуткая метрика, и небольшие колебания в распределении пользователей, не связанные с удержанием как таковым, могут вести к неверным решениям.
- Поэтому разберитесь в том, как считается ваш retention. Не исключено, что вы и аналитическая система понимаете этот показатель по-разному.
- Retention первого дня — не самая быстрая метрика, которую можно посчитать по новым пользователям. Считайте также конверсию туториала и retention нулевого дня.