Как анализировать retention?

Retention — кривая, которая показывает, как пользователь возвращается в приложение. Данная метрика является одной из ключевых для всех мобильных и веб-проектов: как для программ, так и для игр. Именно ретеншн показывает, насколько хорошо приложение способно удерживать пользователей. Однако, несмотря на это, метрика является очень спорной.

Что считать ретеншеном первого дня?

Самый главный камень преткновения — методика подсчета ретеншена. Существует несколько основных вариантов, каждый из которых имеет свои минусы и плюсы:

Календарный день по серверному времени — наиболее плохой вариант. С одной стороны, по данному способу легко считать — из текущей даты вычитаем дату регистрации пользователя. Но, с другой стороны, возникает проблема разных временных зон у людей. Так, например, если сервер находится в России, а закупки трафика идут в США, значительно изменяется продолжительность первого дня. Ситуация особенна опасна в случае, когда идет сравнение сегментов из разных стран — так, например, если сравнивается трафик в России и США, то ретеншен может отличаться на несколько процентов. На основании подобных данных может быть принято неверное решение.

Календарный день по клиентскому времени — уже лучше, но не идеально. Мы точно знаем, что у пользователя сменяется календарный день, однако, в этом случае также есть ряд проблем: во-первых, если пользователь зарегистрировался в 23:59, а в следующий раз он зашел в 00:01, мы посчитаем это как два разных дня, но это, на самом деле, таковым не является. Кроме этого, пользователь может перемещаться по временным поясам, делая наши данные зашумленными. Однако, так как первый день < 24 часов, то основная проблема — завышение ретеншена.

Нулевой день: 24 часа — самый честный способ с точки зрения понимания, но, с продуктовой точки зрения, это также несколько неверно. Если пользователь установил приложение в 15:00, а потом зашел — в 14:50 следующего дня, данная методика это по-прежнему считаем нулевым днем, хотя, с точки зрения пользователя, это не является таковым. Но основная проблема — занижение ретеншена. Однако, чаще всего лучше занизить, чем завысить.

Что же делать? Истина где-то по-середине. Хороший способ использовать метрику ретеншена, где нулевой день: 12 часов, все последующие: 24. При таком способе расчета, у пользователя, вероятнее всего, день поменяется. Если он устанавливает приложение в 19:00 и открывает его в следующий раз в 07:00, то день сменяется. Да, этот метод также неидеален (например, установка в 08:00 и открытие в следующий раз в 21:00 — нулевой день у нас заканчивается, а у пользователя — нет), но он наиболее точно отражает продуктовую составляющую. Проблема — незначительное завышение ретеншена.

Таким образом, выбирать следует между третьим и четвертым вариантом. Главное — рассчитывать метрики одинаково для всех пользователей, ведь вы, чаще всего, будете сравнивать различные сегменты внутри своего приложения. Также стоит отметить, что на длительном периоде все метрики сходятся к одному значению.

Согласно данным, который предоставляет Google, место в ТОПе и ретеншн первого дня сильно коррелированы. 

Ретеншн в зависимости от места в ТОПе (на следующий день после первой сессии игрока)

Первые 10 минут в приложении — наиболее важные

Что ж, про важность данной метрики вряд ли кто-то будет спорить. Однако, что с ней делать? Некоторые игровые разработчики смотрят на уровень, который достигает пользователь в первый день, интернет-магазины могут смотреть зависимость просмотренных товаров и дальнейший ретеншн. Однако, есть еще одна ключевая метрика — время, проведенное в приложении в нулевой день, и ретеншн первого дня.

Идеальная картина зависимости ретеншена первого дня от времени, проведенного в приложении в нулевой день.

Метрика показывает строгую зависимость — чем больше пользователь находился в приложении в первый день, тем более вероятно он вернется на следующий. Однако, так бывает не всегда. Можно определить еще несколько паттернов поведения. На основе анализа приложений, Google определяет 4:

Зависимость ретеншена для приложений соответствующего места в ТОПе

Таким образом, на данном графике мы видим 2 наиболее опасных типа кривой: у приложений 3 квартиля длинное плато, лишь после которого начинается подъем, а у 4 квартиля есть падение ретеншена при увеличении времени в приложении. Это означает, что пользователи игры или программы разочаровались после 1-2 минут, проведенных в приложении, поэтому они не возвращаются обратно.

Вам, как разработчикам, необходимо стремиться к тому, чтобы не было паттерна с «плато» или с «ямой». С другой стороны, согласно статистике Google, примерно 25-50% игр обладают данной проблемой. На что обратить внимание, при анализе метрики:

  • Первый запуск приложения: сколько загружается приложение «на холодную»? Докачивается дополнительный контент? А что, если у пользователя плохой интернет? Сможет ли он зайти в приложение? 
  • FTUE: обучение, понятное ли оно? Завлекает ли пользователя: достаточно фановое или затянутое и занудное? 
  • Интерфейс: понятно ли пользователю, куда нажимать? Нет ли мис-кликов и мис-тапов? Много ли баннеров? Стараетесь ли вы сразу продать пользователю что-то или создаете положительный UX?
  • Полезность: если пользователь пришел заказать еду, действительно ли ему это удобно сделать? Долго ли ему заполнять формы? В играх — геймплей. Положительная ли первая сессия? Что остается у игрока по ее истечении?

Попробуйте представить себя пользователем или обратитесь к play-test, чтобы оценить новых клиентов. Действительно ли они делают то, что вы предполагали. Проведя пару A/B-тестов, вы сможете улучшить данную метрику, если в ней есть проблемы.

Как мы работали с этой метрикой?

Построив аналогичную кривую, мы выяснили, что обладаем наиболее худшим вариантом — у нас не просто есть «яма», но их еще и несколько.

Данный график получился сильно волатильным, так как игра на момент анализа находилась в soft-launch, поэтому данных было немного. Однако, воспользовавшись аппроксимирующей линией, мы сгладили неровности и обнаружили падение на 1-2 минуте и 9-10.

Первое, что мы сделали — выбрали игроков, которые попали в данный промежуток и не зашли на следующий день. Оказалось, что пользователи, отказавшиеся от прохождения обучения, разбивали весь собственный флот, получали негативный UX и больше не возвращались. Второе падение обусловлено маленьким количеством игроков. Но и у них вырисовывается тот же паттерн — пользователи разбивают флот и не возвращаются обратно на следующий день.

Что мы сделали? Добавили защиту от негативных потерь при первой атаке. Хоть они и стали менее динамичными, мы тем самым сильно улучшили эту метрику, что привело к значительному улучшению ретеншена в целом.

Работаю аналитиком в игровой сфере. Участвую в различных хакатонах. Область интересов - монетизация проектов и применение ML в продуктах и бизнесе.

Leave a Comment

Ваш e-mail не будет опубликован. Обязательные поля помечены *