Retention rate — одна из фундаментальных метрик в работе над продуктом. Мы все используем метрику Retention регулярно, но не все знают, что существует много разных способов расчета Retention. И очень важно четко понимать, какой именно метод расчета был использован, при обсуждении результатов анализа и принятии решений на основе Retention метрик.
История. Когда я работал в Zeptolab, нам часто писали игровые студии, которые хотели, чтобы Zeptolab выступил в роли паблишера для их игр. Однажды пришло письмо, которое сильно выделялось на фоне остальных. Метрики игры, которую нам предлагали опубликовать, выглядели впечатляюще: Retention 1 дня превышал 55%, Retention 7 дня — 25%.
Мы начали тестировать игру, чтобы понять, в чем секрет. Но быстро стало понятно, что что-то здесь не сходится. Геймплей не был настолько увлекательным, чтобы обеспечить Retention 1 дня > 55%. Мета-игра также не выглядела достаточно глубокой и проработанной, чтобы вытянуть Retention 7 дня при таком геймплее.
Последующее расследование выявило, что под Retention студия имела в виду не классический Day N Retention rate, а Rolling Retention. Когда мы получили значения классического Day N Retention их игры, то цифры уже не выглядели впечатляющими.
Это лишь один из примеров, как неправильная интерпретация Retention метрики может отправить команду в ложном направлении. В этой статье мы рассмотрим разные нюансы расчета и интерпретации Retention, и то, как они влияют на итоговые значения метрики и принимаемые решения.
Несколько комментариев к статье:
- Этот материал больше сфокусирован на особенностях методов расчета Retention и их влиянии на значения метрики. Ранее в блоге публиковалась статья о том, как влиять на Retention продукта.
- Большинство рассуждений ведутся на примере Daily Retention, но они полностью применимы к недельному и месячному Retention. Выбор того, с какой гранулярностью считать Retention для конкретного продукта, зависит от специфики его использования.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
→ «Симулятор управления продуктом на основе данных» поможет научиться принимать решения с помощью данных и исследований при создании продукта (путь от 0 к 1).
→ «Симулятор управления ростом продукта» поможет найти пути управляемого роста и масштабирования продукта. Вы построите модель роста и составите стратегию развития продукта (путь от 1 к N).
→ «Симулятор SQL для продуктовой аналитики» поможет освоить SQL и применять его для решения продуктовых и маркетинговых задач.
→ «Симулятор управления ML/AI-проектами» научит применять технологии машинного обучения с пользой для бизнеса.
Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.
Еще больше ценных материалов и инсайтов — в телеграм-канале .
Классический Day N retention vs Rolling Retention
Определение классического Day N Retention и Rolling Retention
Классический Day N Retention (далее — Day N Retention) показывает, какой процент новых пользователей вернулись в продукт в конкретный день с момента прихода.
Rolling Retention показывает, какой процент новых пользователей вернулись в продукт в конкретный день с момента прихода или любой день после него.
Если Retention 2-го дня приложения равен 50%, это значит, что 50% новых пользователей этого приложения возвращаются в него на 2-й день.
Если Rolling Retention 2-го дня приложения равен 50%, это значит, что 50% новых пользователей приложения вернутся в него на 2-й день или позже.
Пример расчета Day N Retention и Rolling Retention для реального продукта
На графике ниже показан Day N Retention и Rolling Retention для реального приложения.
Разница между двумя метриками огромная. Более того, она нарастает по мере того, как мы движемся от 1 к 14 дню.
Представьте, что вы попросили аналитика посчитать Retention нового продукта, а он по какой-то причине посчитал Rolling Retention вместо Day N Retention. В этом случае велик шанс, что вы примете неправильное решение о будущем векторе развития продукта.
Давайте более внимательно посмотрим на отличия между значениями двух метрик:
- Day 1 Retention равен 43%, то есть 43% новых пользователей вернулись в продукт на следующий день после его первого использования.
- Day 1 Rolling Retention равен 59%, то есть 59% новых пользователей вернулись в продукт на следующий день или любой день далее.
- Это значит, что 43% новых пользователей вернулись на 1 день. Но было еще 16% новых пользователей, которые не вернулись на 1 день, но зашли в продукт в последующие дни.
Главный минус Rolling Retention
Rolling Retention имеет минус, из-за которого я рекомендую его использовать лишь в очень редких случаях.
Проблема этой метрики в том, что она может постоянно меняться. Если какой-то пользователь первый раз вернется в приложение спустя 90 дней, он увеличит Rolling Retention всех предыдущих дней.
При обычном Retention вы знаете точное значение Retention 1-го дня для пользователей, которые пришли в определенный день, уже спустя 24 часа. В случае же Rolling Retention значение для 1-го дня может измениться и 90, и 250 дней спустя.
Поэтому обычный Retention работает намного лучше для задач анализа экспериментов или сравнения версий продуктов. Это не значит, что Rolling Retention — плохая метрика, но при ее использовании надо четко понимать ее физический смысл и особенности ее расчета.
Когда использовать Rolling Retention, а когда N-day Retention
Для подавляющего большинства задач и продуктов N-day (week/month) Retention подходит лучше, чем Rolling Retention.
Но бывают редкие случаи, когда Rolling Retention удобнее. Обычно его применяют для продуктов, которые подразумевают достаточно редкое использование.
Например, если вы хотите проанализировать долгосрочную возвращаемость в приложение для покупки авиабилетов или бронирования отелей, то с этим поможет Rolling Retention.
Rolling Retention позволит ответить на вопрос: «А какая часть пользователей хотя бы раз вернулась в наше приложение после 30 дня?». Но и здесь можно обойтись без Rolling Retention, а следить за обычным месячным Retention, либо же создать квартальный или годичный Retention (за годичным Retention, например, следят в Airbnb).
Теперь вы знаете, что такое Rolling Retention и чем он отличается от обычного N-day Retention. Если вдруг вы с ним где-то столкнетесь в работе, будете понимать, что означают цифры.
Откуда взялась путаница между N-day Retention и Rolling Retention
На заре мобильной эры популярная система аналитики для мобильных приложений Flurry в отчете Retention показывала не N-day Retention, а Rolling Retention, тем самым создав путаницу между этими двумя метриками в сообществе разработчиков мобильных приложений.
Позже Flurry добавили отчет с классическим Retention, но уже было поздно. Многие стали воспринимать Rolling Retention как дефолтный и единственный способ расчета метрики.
Расчет Retention на основе 24-часовых окон и на основе календарных дней
Как работает расчет Retention на основе 24-часовых окон и на основе календарных дней
Выше мы обсудили различия между Day N Retenion и Rolling Retention. Но есть и другие неочевидные особенности расчета метрики Retention rate.
Например, Day N Retention можно считать на основе 24-часовых окон, а можно на основе календарных дней. На первый взгляд разница может показаться незначительной, но, как вы увидите дальше, значения метрики Retention сильно отличаются в зависимости от выбранного метода расчета. Различия становятся еще более значительными при расчете недельного или месячного Retention каждым из этих способов.
При расчете на основе 24-часовых окон для конкретного пользователя Retention будет считаться на основе индивидуальных временных интервалов. День 0 конкретного пользователя начинается с момента первого запуска продукта и заканчивается через 24 часа. День 1 начинается спустя 24 часа после первого запуска и заканчивается спустя 48 часов. И так далее. Именно по этим индивидуальным интервалам и будет считаться Retention каждого пользователя, общий Retention потом будет получен с помощью агрегирования значений метрики всех представителей изучаемой когорты.
Пусть Retention 1 дня при расчете на основе 24-часовых окон равен 10% для когорты из 1000 новых пользователей, которые пришли 1 октября. Это значит, что 100 из этих пользователей зашли в приложение между 24 и 48 часом после своего первого запуска. Важно понимать, что временной интервал 1 дня для разных пользователей в данном случае будет индивидуальным.
Когда Retention считается на основе календарных дней, то для всех пользователей, которые пришли в определенный день, окно первого дня при расчете Retention будет одинаковым. Это будет просто следующий календарный день.
Пусть Retention 1 дня при расчете на основе календарных дней равен 10% для когорты из 1000 новых пользователей, которые пришли 1 октября. Это значит, что 100 пользователей из этой когорты запустили приложение 2 октября. Среди них вполне могут быть пользователи, которые впервые открыли приложение 1 октября в 23-50, а потом еще раз в 2 октября в 00-10, то есть спустя 20 минут. При расчете на основе календарных дней такие пользователи засчитаются как те, кто вернулся на 1 день.
Подробнее про тонкости расчета Retention на основе 24-часовых окон и календарных дней можно прочитать .
Пример расчета Day N Retention на основе 24-часовых окон и календарных дней
На графике ниже посчитан Day N Retention на основе 24-часовых окон и календарных дней для того же приложения, которое мы рассматривали выше.
Здесь вы вновь можете видеть значительную разницу между значениями Retention метрик, посчитанных двумя способами. В данном случае максимальная разница наблюдается в первые дни и практически пропадает потом.
Retention 1 дня, посчитанный на основе календарных дней, равен 43%. При этом Retention 1 дня, посчитанный на основе 24-часовых окон, составляет лишь 32%.
По мере удаления от первых дней разница между двумя метриками сходит на нет, так как относительная разница между окнами расчета Retention становится все меньше и меньше. Временные окна 30 дня при расчете обоими способами будет примерно совпадать, при этом временные окна 1 дня будет значительно различаться.
Причина значительных различий для первых дней связана со следующим явлением. При расчете на основе календарных дней пользователи имеют больше шансов быть засчитанными как вернувшиеся на 1 день, так как их первый день наступает значительно раньше, чем через 24 часа (тем раньше, чем ближе к концу первого календарного дня они впервые запустили приложение).
Пользователю, который впервые зашел в продукт 1 октября в 23-00, достаточно запустить его хотя бы раз 2 октября, то есть в период с 1 по 25 час с момента своего прихода, чтобы засчитаться вернувшимся на 1 день при методе расчета на основе календарных дней.
При этом для того, чтобы такой пользователь был засчитан вернувшимся на 1 день при расчете Retention на основе 24-часовых окон, ему надо зайти в приложение в период с 23-00 2 октября по 23-00 3 октября. Это значительно более жесткое требование. Оно практически идентично требованию, которое будет предъявлено к этому пользователю, чтобы засчитаться вернувшимся на 2 день при расчете на основе календарных дней.
Почему важно знать, как именно посчитан Retention rate
Мы часто используем Retention метрики, чтобы сравнивать продукты между собой или сравнивать их с рыночными бенчмарками. Так мы осмысляем конкретные значения метрики Retention, понимаем, является ли возвращаемость нашего продукта хорошей или плохой.
Давайте рассмотрим гипотетическую ситуацию. Вы работаете над казуальной мобильной игрой. Вы запустили ее в софт-лонч и через несколько дней посчитали, что Retention 1 дня игры равен 32%.
Вы сходу не можете понять, хорошо это или плохо, и поэтому идете в поисковик и находите Appsflyer с бенчмарками Retention для мобильных игр.
Для попадания в топ 10% казуальных игр Retention 1 дня должен быть более 50.7%. Ваша игра очень далека от этого значения.
Медианное значение Retention 1 дня для казуальных игр составляет 38.8%. Выходит, что с Retention 1 дня на уровне 32% ваша игра находится где-то среди самых слабых продуктов, представленных на рынке.
На основе полученной информации вы закрываете проект как бесперспективный.
Но это ошибочное решение.
Amplitude, аналитическая система, которую вы используете, по умолчанию считает Retention на основе 24-часовых окон. При этом Appsflyer по умолчанию считает Retention на основе календарных дней.
Если пересчитать Retention игры на основе календарных дней в Amplitude, то Retention 1 дня будет уже 43%. Это лучше медианного значения по нише и не так далеко от топ 10% лучших казуальных игр.
Скорее всего, такая трактовка результатов первого запуска изменит решение по поводу будущего игры.
Какой метод расчета Retention rate лучше
На этот вопрос нет однозначного ответа.
Расчет метрики Retention rate на основе 24-часовых окон дает более честный ответ на вопрос о том, как ваш продукт возвращает пользователей. Но такой метод расчета Retention требует больше времени. Вы получите финальное значение метрики для пользователей, которые запустили продукт в конкретный день, лишь спустя 2 календарных дня (48 часов с момента прихода последнего пользователя). При расчете же Retention на основе календарных дней, значение Retention 1 дня будет доступно уже через 24 часа.
Retention на основе календарных дней имеет смысл использовать тогда, когда скорость получения данных критична. Например, для анализа маркетинговых кампаний, где лишние 24 часа неудачной рекламной кампании могут обойтись в значительную сумму. В случаях же, где вы можете подождать или где вы уже работаете с историческими данными, имеет смысл выбрать Retention, посчитанный на основе 24-часовых окон.
Это лишь рекомендации. Вы можете использовать то, что вам нравится больше. Главное, чтобы вы четко понимали, как именно конкретные значения метрики получены и что они значат.
В заключение
Существует много разных способов расчета Retention. В этой статье мы обсудили две особенности расчета Retention, которые могут повлиять на выводы, но есть и другие более специфичные кейсы.
Ключевая идея статьи в том, что вы должны очень четко понимать, что именно вы называете Retention, когда работаете с этой метрикой. Это позволит избежать ошибок при принятии решений на основе данных по возвращаемости.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
→ «Симулятор управления продуктом на основе данных» поможет научиться принимать решения с помощью данных и исследований при создании продукта (путь от 0 к 1).
→ «Симулятор управления ростом продукта» поможет найти пути управляемого роста и масштабирования продукта. Вы построите модель роста и составите стратегию развития продукта (путь от 1 к N).
→ «Симулятор SQL для продуктовой аналитики» поможет освоить SQL и применять его для решения продуктовых и маркетинговых задач.
→ «Симулятор управления ML/AI-проектами» научит применять технологии машинного обучения с пользой для бизнеса.
Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.
Еще больше ценных материалов и инсайтов — в телеграм-канале .
