Важный нюанс в расчёте retention: как и зачем считать day 0 retention

Показатель 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 нулевого дня.