Вне зависимости от типа продукта вопрос измерения пользовательской лояльности актуален всегда:
- рады ли мои клиенты?
- можно ли сказать, что в этом месяце они рады больше, чем в прошлом?
- сколько денег мне принесёт их радость?
Эти вопросы в том или ином виде задают себе многие менеджеры продукта. В данной статье аналитики devtodev Василий Сабиров и Вера Карпова рассматривают метрики пользовательской лояльности и разбирают, в каких случаях их необходимо использовать.
Что такое лояльность?
Можно было бы сказать, что лояльность — это счастье пользователей, их удовлетворенность.
Лоялен ли к игровому автомату лудоман, зависимый от азартных игр? Пожалуй, да. Счастлив ли он? Едва ли.
Лоялен ли клиент к любому продукту-монополисту? Как правило, да. Удовлетворён ли он, учитывая, что альтернатив вокруг и нет?
С аналитической точки зрения на этот вопрос ответить ещё труднее: метрики лояльности как таковой нет, и измерить ее непросто.
Поэтому давайте будем определять лояльность через лояльного пользователя. Что он делает?
- Он остаётся с продуктом на протяжении какого-то времени.
- Лояльный пользователь платит. А если заплатил и остался лоялен, то скорее всего заплатит ещё.
- Лояльный пользователь делится информацией о продукте, рассказывает о нём друзьям.
- Лояльный пользователь даёт фидбек, честно рассказывая, что ему нравится, а что нет.
Соответственно, если переходить к метрикам, то это будут:
- метрики удержания;
- монетизационные метрики;
- метрики виральности.
Рассмотрим каждый из типов метрик отдельно.
Метрики удержания
Прежде всего, мы говорим о классическом retention:
- day 1 retention — доля пользователей, входивших в проект через 1 день после первого визита. Эта метрика говорит о реакции пользователей на их первую сессию, приятен ли им визуальный стиль проекта, понятно ли, о чём проект, достаточно ли они заинтересованы, чтобы дальше изучать проект.
- day 7 retention — доля пользователей, входивших в проект через семь дней после первого визита; эти пользователи уже разобрались в проекте и поняли его основы;
- day 28 (30) retention — эти пользователи уже прошли испытание временем, они поняли суть проекта и согласны использовать его и в дальнейшем.
Этими интервалами в 1, 7, 28 дней retention не ограничивается, однако именно по ним встречается больше всего бенчмарков на рынке. И даже знаменитое правило retention “40-20-10” означает средние показатели удержания для успешного проекта именно за эти временные интервалы.
Можно рассчитывать retention и за другие дни. Так, часто встречается day 3 retention как некий промежуточный показатель между удержаниями первого дня и первой недели.
Многие также рассчитывают и retention за более длительные интервалы времени. В SaaS и GaaS (game as a service) проектах, которые основаны на долгосрочном удержании, могут рассчитывать retention и за 3 месяца, и за 6, и за 12, и за несколько лет.
При этом, рассчитывая retention, всегда важно понимать, считается ли он по календарю или по часам (в этом случае “следующий день” — это 24-часовой интервал через 24 часа после первого входа). Особенно эта разница актуальна для проектов, аудитория которых рассредоточена по разным часовым поясам. В этом случае retention по часам будет более точным показателем.
У себя в devtodev мы реализовали оба способа расчёта retention:
Таким образом, можно даже говорить и о day 0 retention — доле пользователей, совершавших свой второй вход в течение суток после первого. Быстрая метрика, удобная для оперативного мониторинга изменений, особенно если они касались первой сессии.
Говоря о retention, также важно понимать, что вообще говоря пользователь, не вошедший в проект, допустим, через семь дней после первого визита, не обязательно нелоялен к вам. Может, он был в командировке? у бабушки? в больнице? просто заработался?
А вы уже не учли его в day 7 retention и посчитали нелояльным.
Чтобы избавиться от этой несправедливости, была введена метрика rolling retention. Рассчитывается она в общем так же, но с одним важным дополнением: day 7 rolling retention — это доля пользователей, входивших в проект через семь дней после первого визита или позже, т.е. rolling retention даёт им шанс.
Разумеется, это значит, что rolling retention ≥ classic retention.
И вот как они взаимосвязаны:
Подробнее о графике можно прочесть здесь.
А мы идём дальше.
Вполне возможно, что своим новым изменением в проекте вы понижаете day 1 retention (например, делаете туториал более сложным, чтобы отсечь нецелевую аудиторию), но повышаете day 7 retention.
Как понять, стало ли новое обновление лучше старой версии? Нужна какая-то свёртка всех показателей retention в один сводный показатель. И у нас есть такая метрика, она называется lifetime.
Lifetime — это метрика, которая говорит о том, сколько в среднем дней пользователь проводит в приложении. Математически она рассчитывается как раз как интеграл по линии retention (тут-то вам и пригодятся школьные знания). Однако проще объяснить методику расчёта lifetime следующим образом:
- выберите для себя временной интервал неактивности, по истечение которого вы будете считать пользователя покинувшим ваш проект (на практике берут неделю, две недели, месяц);
- каждый день отмечайте тех пользователей, которые в этот день признаны покинувшими проект;
- кстати, доля таковых пользователей называется churn rate, и это тоже отдельная метрика, которую, в отличие от большинства других, надо минимизировать, а не максимизировать;
- замеряйте их среднее время жизни от первого до последнего входа. Эта средняя величина и будет их lifetime. Чем больше пользователей (и чем больше временной период, за который вы делаете расчёты), тем точнее значение этого показателя.
Да, lifetime — это небыстрая метрика, и для того, чтобы точно её рассчитать, нужно выждать время, однако если замерять её регулярно, вы сможете точно сказать, как меняется лояльность ваших пользователей во времени.
Ещё одна метрика удержания — это sticky factor. Он рассчитывается как среднедневная аудитория, делённая на среднемесячную аудиторию проекта. Нетрудно догадаться, что он будет изменяться от 3% до 100%. Обычно для успешных проектов говорят о sticky factor выше 20-25%.
Это своего рода показатель “липкости”, показатель регулярности пользовательских входов. Чем он выше, тем, конечно же, лучше. Наши исследования показывают, что он имеет сильную корреляцию с долей платящих пользователей.
Опять же, измеряйте его во времени каждый месяц и делайте выводы об изменении качества продукта.
Метрики монетизации
Главной метрикой монетизации, если мы говорим о лояльности пользователей, является ARPU — средний доход с пользователя. ARPU рассчитывается как доход, делённый на аудиторию. Именно показателем ARPU очень любят меряться на конференциях, именно его у вас спросят партнёры и инвесторы. Как правило, ARPU считается за месяц (месячный доход, делённый на MAU), но вообще говоря его можно считать за любой период.
Так, например, ARPU за день, рассчитываемый как дневной доход, делённый на DAU, даже имеет своё название ARPDAU. ARPDAU как правило имеет сильную сезонность, он очень зависит от дня недели.
Отдельный показатель лояльности — это ARPPU, средний доход с платящего пользователя. ARPPU рассчитывается как доход, делённый на количество пользователей, заплативших за период. Таким образом, ARPPU — это показатель лояльности именно платящих пользователей, их реакция на уровень цен в вашем проекте и на ту ценность, которую он несёт.
Не путайте ARPPU и средний чек: средний чек говорит лишь о размере транзакции, а ARPPU включает в себя и повторные платежи. Кстати, если рассмотреть структуру дохода большинства проектов, то именно повторные (а не первые) платежи составляют основу дохода. Таким образом, важно, чтобы платящему пользователю и понравилось то, что он получает за деньги, и захотелось заплатить ещё.
ARPU, ARPPU, ARPDAU — это метрики небыстрые, они хорошо работают лишь на стабильной аудитории. А если же вам нужно быстро оценить качество, допустим, новой версии проекта, то лучше всего использовать показатель накопительного дохода.
Накопительный доход за N дней показывает, сколько в среднем денег платит пользователь за свои первые N дней в проекте.
Эта метрика поначалу растёт достаточно быстро (пока и пользователи не “отвалились”, и деньги у них не закончились), затем её рост замедляется, и впоследствии её график становится более плоским. Пределом же графика при больших N будет метрика LTV — общий доход с пользователя за всё время.
LTV — это также небыстрая метрика, для её расчёта требуется, чтобы от регистрации пользователей прошло определённое время. Но если замерять LTV регулярно (раз в месяц), вы будете получать представление о том, куда движется ваш проект, как изменяется его качество.
Дело в том, что LTV — это метрика, которая учитывает в себе и retention, и ARPU. Есть несколько способов расчёта LTV, и один из самых популярных берёт интеграл от retention (тот самый lifetime) и умножает его на ARPDAU. Таким образом, LTV — это прекрасная метрика, отражающая лояльность пользователей, правда считается небыстро.
Ещё одной монетизационной метрикой лояльности считается доля платящих (paying share), которая рассчитывается как количество платящих пользователей за период, делённое на общую аудиторию за период.
Paying share — хорошая метрика, однако есть пара метрик, которые говорят примерно о том же, но могут дать больше информации:
- Конверсия в первый платёж — доля пользователей, зарегистрированных в проекте в определенный период, совершивших хотя бы один платёж к текущему моменту.
- Конверсия в повторный платёж — доля пользователей, зарегистрированных в проекте в определенный период, совершивших более одного к текущему моменту. Наши исследования показывают, что вероятность совершения второго платежа выше, чем первого, а третьего — выше, чем второго. Таким образом, самое трудное, что надо сделать пользователю — это первый платёж, дальше будет проще. Однако основную сумму приносят именно повторные платежи.
Наконец, ещё важно замерять, как быстро пользователи совершают свои платежи (особенно это актуально для первого платежа). Зная это, вы сможете и получить представление о лояльности, и использовать его себе во благо, баннерами и акциями привлекая внимание пользователя к возможности совершения платежа, увеличивая его вероятность.
В devtodev мы можем измерить среднее время до совершения первого, второго, третьего платежа. Также этот отчёт можно построить не по дням, а по уровням, чтобы ещё точнее находить паттерны пользовательского поведения и увеличивать вероятность платежа.
Для первой части статьи, пожалуй, достаточно метрик.
Во второй части мы поговорим про метрики виральности, расскажем о необычных кастомных метриках (которые подходят не для всех, но для тех, кому подходят, они чрезвычайно полезны), а также рассмотрим популярный показатель Net Promoter Score, немного покритикуем его и предложим пару альтернатив.