Метрики вовлечения pt1
User Aquisition
Метрики привлечения пользователей в основном используются маркетинговыми аналитиками и специалистами по user aquisition, привлечению пользователей. Продуктовые аналитики в основном работают с метриками стоимости пользователя: CPA (cost per action), CPI (cost per install), хотя иметь представления о прочих метриках тоже надо.
Процесс привлечения пользователей
рекламодатель (тот, кто хочет привлечь пользователей)
аукцион рекламной площадки (рекламная площадка выбирает, кому, когда и по какой цене показыть рекламные материалы)
целевые действия (установка, платеж и т.д.) (в зависимости от того, на выполнение какого целевого действия оптимизируется рекламная сеть, в приложение будут приходить разные пользователи - те, кто вероятнее всего установит приложение/сделает платеж / сделает другое целевое действие)
управление кампанией - таргетинг, бюджет, креативы (рычагов управления рекламными кампаниями не так уж и много: на кого ориентируем рекламу, какой бюджет в день рекламная сетка может потратить на привлечение пользователей, какие рекламные материалы показываем)
Маркетинговая воронка в мобильных приложениях
Когда пользователи видят рекламу, они проваливаются в “воронку” — последовательность шагов, которые приводят пользователя в приложение. Вообще воронки — полезный инструмент для оценки, где и на каком этапе отваливается пользователь.
реклама (баннер, playable, прочий креатив): CPM (cost per mille - сколько платим за каждые 1000 показов рекламных материалов), CPC (cost per click - сколько платим рекламной сетке за каждый клик по баннеру), СTR(click through rate – клики / показы)
переход в стор
установка приложения (CR, conversion rate, регистрации / показы)
целевое действие (CPI, CPA)
Для продуктовых аналитиков важнее всего стоимость пользователя (как правило, CPI или CPA), так как это позволяет сопоставить, сколько заплатил пользователь за время своей жизни в приложении и сколько потратили на его привлечение. То есть, окупился пользователь или нет. Оптимизировать окупаемость можно и с помощью понижения цены закупки, и с помощью повышения среднего чека / LTV пользователя. На последнее как раз влияют прождуктовые изменения, которые и входят в зону ответственности продуктовых аналитиков.
Новый пользователь
Основная цель рекламных кампаний – привлечение пользователей в приложение. Одна из базовых метрик этого процесса – количество новых пользователей. Однако есть сложности с самим определением, что такое новый пользователь. В частности, считать инсталлом новое физическое устройство. Или новый аккаунт пользователя. Или пользователя, который сделал покупку / подписку (e-comm, в частности). Например, когда пользователь на новый телефон устанавливает приложение и туда происходит логин с помощью его гугл/эппл аккаунта. В этом смысле устройство новое (а маркетинг закупает девайсы), а пользователь старый. Или когда пользователь пользовался приложением на телефоне. Потом удалил и через пару лет увидел рекламу и поставил заново и создал новый аккаунт. Или просто отдал телефон кому-то. Девайс старый, а пользователь новый.
Другая история с новыми пользователями – это механизмы ретаргетинга. Это когда мы стараемся вернуть в приложение пользователей, которые уже были нашими пользователями, но потом отвалились. Например, мы выбираем набор девайсов с каким-то суммарным платежом более X единиц, и просим рекламной сетке именно этим устройствам показать нашу рекламу, с помощью которой мы надеемся вернуть пользователей. Этих пользователей сложно считать новыми, но рекламная кампания на них была и, соответственно, сколько-то мы потратили на возвращение этих пользователей.
Активность и вовлечение
Другая группа метрик - метрики активности и вовлечения пользователей в продукт. К этим метрикам относят обычно количество заходов пользователя в день (количество сессий), количество уникальных пользователей, заходящих в день в приложение. В некоторых случаях считают более длинные метрики - количество уникальных пользователей, зашедших в приложение в последнюю неделю/месяц.
DAU, WAU, MAU
Daily Active Users
Weekly Active Users
Monthly Active Users
Основная метрика - DAU, как наиболее гибкая и быстро реагирующая на изменения в продукте. Месячные и недельные метрики считаются в скользящем окне, за последние 30 и 7 дней для каждой даты соответственно.
Stickness / Sticky factor
Иногда смотрят отношение DAU/MAU и интерпретируют как метрику залипания пользователя в проект, его лояльности. В целом это метрика вполне хорошо заменяется метриками удержания (retention).
Retention rate
Метрика удержания пользователя (retention) — какая доля пользователей вернулась в приложение. Во многом формула расчета ретеншена зависит от того, что мы считаем точкой отсчета. Когда речь идет о мобильных приложениях развлекательного плана (игры, стриминговые сервисы и проч.), то точкой отсчета обычно считают день инсталла, когда пользователь установил приложения. В некоторых продуктах может быть иначе, например, в e-commerce или в сервисах, предлагающих определенные услуги оффлайн (доставка продуктов), считаются только возвраты тех пользователей, которые сделали уже платеж (возвратом считается последующий платеж).
В целом, метрика удержания одна из важнейших в аналитике - она позволяет понимать, насколько пользователям интересно приложение (сервис), останутся ли они в нем. Соответственно, это прямо влияет на монетизацию: когда пользователи остаются, они либо больше платят, либо, как минимум, есть шансы их побудить сделать платеж (скидками, новыми фичами и т.д.)
Нюансы:
install day = day 0: традиционно день инсталла считается нулевым днем.
day 1/7/14/28: полезно иметь в виду, что бывают циклы, например, ретеншен в течение недели может варьировать в определенном диапазоне. Соответственно, сравнивать два периода/объекта/тестовых группы хорошо бы по одному и тому же по структуре интервалу.
проблема интервала (сутки vs календарная дата): обычно считается ретеншен по календарным дням, то есть, если произошла смена даты, то это уже другой день, даже если пользователь установил приложение в 23.55. Временами встречаются вычисления ретеншена строго по 24 часовым интервалам (вернувшийся в игру через 24 часа). Метрики удержания по этим двум формулам вычисления различаются, всегда надо уточнять, как именно велся расчет.
rolling retention: иногда нет возможности логировать каждый заход пользователя в приложение, поэтому используется только дата последнего захода пользователя в приложение - то есть, считается, какая доля пользователей заходила после N дня от инсталла. Иногда
retention 1 дня/удержание 1 днясокращают доret1 / ret1d, r1(номер дня может быть любым, не только 1).однородность когорт: когда мы считаем удержание по когорте пользователей (например, пришедшим в сентябре), то мы должны считать ретеншен только того дня, который могли прожить все пользователи. То есть, на момент 3 сентября нельзя считать ретеншен 7 дня для тех, кто пришел в приложение 31 августа - они принципиально не могли прожить 7 дней, максимум - 2 (день инсталла и 1-2 октября, 3 сентября также нельзя считать, так как день еще не закончился). Соответственно, по всей месячной когорте можно считать только ret2, даже для тех, кто пришел в начале сентября и мог провести в приложении больше дней. Иногда это минимальное количество дней, которые могли прожить пользователи всех когорт,
называют окном лайфтайма.
Google Spreadsheet с примерами расчета ретеншена и сравнения дневных когорт.
Полезные материалы
Статья про Rolling retention и Retention rate от Олега Якубенкова.
Статья от dev2dev про Retention.
Список фреймфорков, которые используют продуктовые менеджеры в своей работе.
Оффтоп: cмешной случай, как потеряли информацию о 16 тысячах заболевших граждан. Хороший пример, почему для работы с большими данными (да и просто с данными) Excel не очень полезен.
Домашнее задание
Домашние занятия для желающих. Если будут вопросы, пишите в канал #discussion. Если возникнет необходимость получить от меня какие-то персональные комментарии - пишите в личку.
Задание можете выполнять на любом доступном вам языке / среде для статистики.
level 1 (IATYTD)
Обновите знания по работе с табличками — аггрегации (групировки), слияния, создание и модификация колонок.
Ссылка на конспекты прошлого курса: https://mar231s.upravitelev.info/
level 2 (HNTR)
Необходимо подсчитать и нарисовать, сколько пользователей в день приходит в приложение, в том числе и с разбивкой по платформам. Датасет: https://gitlab.com/hse_mar/mar211f/-/raw/main/data/installs.csv
level 3 (HMP)
Используя датасет по заходам пользователей в приложение (dau.csv), подсчитайте и отобразите на графике, сколько пользователей в день заходит в приложение (DAU). Ссылка на файл.
Осторожно, файл около 400мб.
level 4 (UV)
На основе данных по логинам нарисуйте area plot DAU проекта, в котором цветами выделите группы пользователей по количеству дней с момента инсталла:
группа 1: 0 дней с инсталла
группа 2: 1-7 дней с момента инсталла
группа 3: 8-28 дней с инсталла
группа 4: более 28 дней с инсталла
У вас должно получится что-то вроде слоеного пирога, где цветами выделены группы. Подумайте, есть ли необходимость рисовать этот график не в абсолютных числах (количество пользователей), а в долях каждой группы от DAU, в чем могут быть плюсы и минусы такого графика. Возможно, вам потребуется нарисовать графики разных типов, чтобы ответить на этот вопрос.
Попробуйте подумать, что говорит подобный график о продукте и его пользователях. Есть ли у него проблемные зоны, над которыми надо поработать или которые могут влиять на стратегию развития и/или оперирования продукта?
