Ретеншен — основная метрика F2P игры, вероятностный подход

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Введение

В настоящей статье речь идет об анализе данных, а конкретнее - анализе условно-бесплатных игр-сервисов, обычно называемых free to play games или F2P. Вероятно, рассуждения будут уместны и для других интернет-сервисов, будь то социальная сеть или интернет-магазин.

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

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

В частности, повсеместно можно найти формулу ретеншена (retention rate), как отношения возвратов к установкам, и некоторый список его разновидностей (ролинг ретеншен, например), узнать, что метрику можно считать за разный период времени, а также прочитать рассуждения о влиянии метрики на качество игры и получить множество советов, как его повысить. Казалось бы все доступно и понятно, причем, не только профессиональным аналитикам, но и менеджменту.

Но постойте. А не слишком ли бодро авторы переходят от вычисления простой дроби к принятию решения о переделке продукта? Посмотрели на какие-то цифры и уже собираетесь тратить ресурсы на разработку? Вы действительно уверены, что достоверно определили значение искомой метрики? Вы уверены, что вы получили достаточно аналитической информации для принятия решения?

Нет. Вообще-то совсем недостаточно разделить число измеренных возвратов на число измеренных установок и наивно полагать, что метрика известна. Мы имеем дело со случайной величиной, значение которой можно измерить экспериментально лишь с некоторой достоверностью. 

С какой достоверностью? Как это зависит от результатов измерений? Как это зависит от внешних факторов, таких как, например, качество трафика, день недели или качество маркетинговых материалов? Можно ли учитывать эти факторы для более точного определения искомой метрики и как это сделать?

Доступных широкому кругу читателей материалов, сфокусированных на этих вопросах, довольно мало. Например, простой поиск в интернете фраз “ретеншен статистическая значимость” или “ретеншен биномиальное распределение” выдает примерно 0 полезных ссылок, а ведь нужно еще было догадаться написать эти фразы в поисковике! Необходимые знания приходится тщательно разыскивать в учебниках по теории вероятности и математической статистике, причем в такой учебник необходимо погрузиться действительно глубоко - изучить его первую половину, посвященную теории вероятности, далее перейти к изучению статистики, разобраться в куче терминов и формул, и примерно где-то в последней четверти учебника начинаешь понимать, как правильно сформулировать вопросы, и находить на них ответы.

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

Статья ориентирована на широкую аудиторию - не только опытных аналитиков, но и аналитиков начинающих, а также для менеджеров продуктов, продюсеров, проджект менеджеров, геймдизайнеров, и других сотрудников компаний-паблиширов, принимающих решения о судьбе игровых проектов на основе предоставляемой им аналитической информации. Я постараюсь объяснять все на понятных примерах, довольно подробно, с графиками, но небольшим количеством формул, а также избегать, по-возможности, введения некоторых сложных терминов, если этого можно избежать.

Буду рад комментариям, дополнениям, уточнениям, исправлениям.

Определение

Информация из этого раздела является вводной. Вы можете смело пропустить ее, если из хорошо знакомы определением понятия “ретеншен”.

Под словом “ретеншен” я буду понимать метрику, называемую в англоязычной литературе “retention rate“. 

Существуют альтернативные наименования этого термина, например, “возврат пользователей” или “удержание”, однако, по моим наблюдениям, использование подобных смысловых переводов скорее вносит путаницу, чем способствует пониманию, ведь перевод по транскрипции давно и успешно прижился в русскоязычном профессиональном сообществе. Также может показаться странным, что я пишу “ретешен”, а не “ретеншен рейт”, как следует из английского термина. Но, опять же по моим наблюдениям, чаще используется именно короткое “ретеншен”, без второго слова. Среди двух возможных вариантов транскрипции “ретеншен” и “ретеншн” я использую “ретеншен” как более благозвучный - все-таки следование 3-х согласных подряд в конце слова для русского языка совсем противоестественно.

Ретеншен (англ. retention rate) - это отношение количества пользователей, продолжающих пользоваться интернет-сервисом (например, F2P игрой) через некоторое время после первого использования, к количеству людей, изначально им воспользовавшихся. Что можно выразить простой формулой:

R = \frac{U_{ret}}{U_{inst}} (1)

где

Uinst  - количество пользователей, изначально установивших игру,

Uret  - количество пользователей, продолжающих играть в нее в нее через некоторое время.

Часто это значение умножают на 100, чтобы получить значение в процентах, но далее в статье мы будем, обычно, использовать значения в диапазоне от 0 до 1, чтобы избежать лишних преобразований в формулах.

Под словами “продолжающий играть” или, как еще говорят “вернувшийся”, подразумевают человека, который в некоторый момент запустил игру впервые, а затем еще раз запустил ее, хотя бы один раз, в другой день, позже. Момент первого запуска игры по традиции принято называть установкой, или инсталлом. Это несколько неверно, ведь часть люди скачивают игру из стора, устанавливают, но ни разу потом не запускают. Вероятно, традиция пришла из веб-сервисов, где практически невозможно скачать веб-страницу, но не открыть ее. Мы будем соблюдать традиции и называть самый первый запуск установкой, предполагая что пользователь, установивший игру, обязательно тут же ее впервые и запустил.

Из определения следует, что значения ретеншена обязаны лежать в диапазоне от 0 до 1 (или от 0% до 100%), поскольку количество вернувшихся игроков не может превышать количество изначально пришедших, и оба числа в дроби положительны.

Существует несколько разновидностей ретеншена. Они отличаются, как правило, только числом в числителе, то есть факт возврата пользователя в игру фиксируется несколько разными способами. Рассмотрим несколько примеров.

  1. В формуле классического ретеншена 2-го дня в числителе стоит количество людей, вернувшихся в игру строго на следующий день после установки игры.

  2. Аналогично мы можем посчитать классический ретеншен 2-го дня. В числителе будут пользователи, вернувшиеся в игру строго во 2-й день после установки.

  3. Можно поступить иначе - посчитать всех людей, вернувшихся в игру в 1-й день после установки или когда-либо позднее. Эту метрику называют “роллинг ретенншен 1-го дня”.

Есть и некоторые другие разновидности, но мы не будем на них останавливаться, поскольку это совершенно несущественно. Изредка они полезны, но, как правило, нет. Практически всегда на практике вы будете использовать классический ретеншен, ведь вы хотите сравнить метрику своего продукта с конкурентами, а почти во всех публикуемых аналитических отчетах используется именно классический ретеншен. Другие формулы (например, упомянутый роллинг ретеншен), зачастую, используются лишь для того, чтобы искусственно завысить показатели игры в глазах потенциального инвестора.

Очень часто на практике рассматривается история изменения ретеншена по дням, поскольку именно она отражает историю изменения качества вашего продукта. Пример графика истории изменения классического ретеншена изображен ниже. На графике изображены классический ретенешен 1-го дня, 2-го дня, 3-го дня и 7-го дня, 14 дня и 28 дня. В каждой точке графика ретеншен рассчитан по приведенной выше формуле, то есть в знаменателе - число людей, фактически установивших игру в конкретный день, а в числителе - строго те из них, кто вернулся в игру строго через 1, 2, 3, 7, 14 и 28 дней после установки игры.

Рисунок 1. Пример графика ретеншена
Рисунок 1. Пример графика ретеншена

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

Постановка задачи контроля ретеншена

Ретеншен принято называть главной метрикой качества игры из-за его простой формулы и простой и понятной логики его трактовки “если игра качественная, то она понравится игроку, следовательно, он через некоторое время в нее вернется, а если не понравилась - не вернется”.

Более того ретеншен зачастую называют не просто главной метрикой качества, но и вообще САМОЙ ГЛАВНОЙ МЕТРИКОЙ ПРОЕКТА, и вот почему. Если ретеншен плохой, и пользователи не остаются в игре, то нет смысла привлекать в игру новых пользователей и тратить на это средства - они ведь ведь все равно скоро уйдут. Следовательно, нет смысла тратить силы на улучшение монетизации проекта - пользователей ведь нет, кого тут монетизировать. Поэтому надо сначала увеличивать главную метрику - ретеншен проекта, повышая его качество, потом уже привлекать пользователей и только в третью очередь - монетизировать их. Коротко данное утверждение известно как “Retention-Acquisition-Monetization”.

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

На практике мы имеем несколько задач, возникающих перед паблишером, в том числе:

  1. Проект выпущен в софтланч, надо минимальными средствами, привлекая минимальное количество пользователей, определить ретеншен проекта с заданной достоверностью и принять решение, что далее делать с проектом - продолжать его развивать или нет.

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

  3. Контроль метрики при изменении маркетинга, например качественного и/или количественного состава трафика, промо материалов и т.д.

  4. Регулярный контроль метрики с целью обнаружения каких-то нештатных ситуаций, например, технических сбоев или проблем с трафиком.

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

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

Вероятностный подход к измерению ретеншена

Возьмем один конкретный день жизни проекта. Измерим количество установок в этот день и количество возвратов в игру из этих установок на следующий день и, далее, посчитаем ретеншн 1-го дня как отношение возвратов к установкам по приведенной выше формуле (1)

R = \frac{U_{ret}}{U_{inst}} (1)

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

Если мы будем рассматривать только одно или даже несколько измеренных значений метрики за разные дни (так называемую, выборку), можно легко сделать неправильные выводы о качестве проекта. Нам может показаться, что проект слишком хорош, если вдруг измеренный ретеншн случайно оказался большим или же наоборот, слишком плох, если друг ретеншен оказался низким.

Владельца продукта интересует вовсе не это текущее значение. Его интересует наиболее вероятное значение этой случайной величины, то есть среднее значение или, если использовать более строгую терминологию - математическое ожидание случайной величины. Именно это среднее  значение и является критерием качество проекта.

Поэтому рассмотрим далее интересующую нас метрику с точки зрения теории вероятности и математической статистики и постараемся определить статистическую значимость наших измерений. Несколько глав настоящей статьи посвятим тому, насколько достоверно можно определить математическое ожидание (то есть среднее значение) ретеншена, отталкиваясь лишь от данных, полученных за один день измерений. Далее мы поговорим о том, как получить еще более достоверные данные, обладая данными за несколько дней.

Биномиальное распределение ретеншена

Возврат пользователя - бинарное событие, у которого существует два возможных исхода - пользователь вернулся (происходящего с вероятностью p) или пользователь не вернулся (происходящего с вероятность q = 1-p).

Это можно сравнить с подбрасыванием монетки. Но только чуть-чуть необычной асимметричной монетки, одна сторона которой почему-то выпадает систематически чаще.

Последовательность подобных независимых случайных событий, вероятность «успеха» в каждом из которых постоянна и равна некоторой величине p, подчиняется биномиальному распределению (или распределению Бернулли) и выражается формулой:


p_{n}(k) = \left(\begin{array}{c}n\\ k\end{array}\right) p^{k}  q^{n-k}, k = 0,...,n, (2)

где

q = 1 - p

и \left(\begin{array}{c}n\\ k\end{array}\right) = C_n^k = \frac{n!}{(n-k)! k!} - так называемый биномиальный коэффициент

Примечание! В настоящей статье мы будем предполагать, что события возврата пользователей в игру являются независимыми и равновероятными в течении одного календарного дня, что делает легитимным применение биномиального распределения для оценки статистической значимости наших измерений. Утверждение это, однако, небесспорно, и было бы очень интересно обсудить это вопрос в комментариях к настоящей статье.  

Итак, формула (2) может быть использована для оценки распределения абсолютного числа вернувшихся пользователей. Чтобы получить из нее формулу распределения ретеншена, как отношения числа возвратившихся пользователей к числу установок n, нужно от переменной k (абсолютное число возвратившихся пользователей) перейти к относительному числу

x_k = k/n

Если мы выполним это несложное преобразование, то получим формулу распределения

p_{n}(x_{k}) = n \left(\begin{array}{c}n\\ nx_{k}\end{array}\right) p^{nx_{k}}  q^{n(1-x_{k})}, x_{k}= \frac1{n},\frac2{n},\frac3{n},...,1,  (3)

Далее такое распределение в относительных величинах по оси x (от 0 до 1) я буду называть “биномиальное распределение ретеншена”, в отличие от обычного биномиального распределения, где по горизонтальной оси указано абсолютное количество экспериментов от 0 до n

Форма графиков распределений (2) и (3) абсолютно идентична, они отличаются только масштабирующими коэффициентами по осям X и Y

Вот как будет выглядеть график биномиального распределения ретеншена для математического ожидания равного 0.35 или 35% (довольно распространенное на практике значение ретеншена) и разного количества установок: 16, 32, 64, 128, 256. 

Рисунок 2. Биномиальное распределение ретеншена для разного количества установок, от 16 до 256
Рисунок 2. Биномиальное распределение ретеншена для разного количества установок, от 16 до 256

Важные свойства такого распределения:

  1. Распределение - дискретное, причем количество точек совпадает с числом установок.

  2. Математическое ожидание случайной величины (иначе говоря, ее среднее значение), ожидаемо, равняется вероятности возврата пользователя, то есть M = p (на графике - это величина 0.35). Это и есть та самая величина, которую нам необходимо найти - искомое значение ретеншена.

  3. Дисперсия биномиального распределения ретеншена, позволяющая нам судить о достоверности наших измерений, рассчитывается по простой формуле:

D = \frac{p(1-p)}{n} (3)

  1. Стандартное отклонение σ вычисляется как корень из дисперсии и равняется

\sigma = \sqrt{\frac{p(1-p)}{n}} (4)

Графики подобной формы зачастую называют “колокол” из-за некоторого внешнего сходства.

Геометрический смысл стандартного отклонения - ширина “колокола”. Чем больше величина стандартного отклонения, тем более сильным является возможный разброс значений случайной величины.

Нормальное распределение ретеншена

Одно из самых известных утверждений теории вероятности, центральная предельная теорема вероятностей, гласит, что сумма достаточно большого количества слабо зависимых случайных величин, имеющих примерно одинаковые масштабы (ни одно из слагаемых не доминирует, не вносит в сумму определяющего вклада), имеет распределение, близкое к нормальному. Функция плотности вероятности нормального распределения (или функция Гаусса) имеет следующую формулу:

\frac{1}{\sigma\sqrt{2\pi}}\exp\left(-\frac{(x-\mu)^2}{2\sigma^2}\right) (5)

где 

Источник: https://habr.com/ru/post/726396/


Интересные статьи

Интересные статьи

Всем привет!Меня зовут Константин Щеглов, я – CIO SuperJob. Сегодня я расскажу о нашей системе грейдов, которую мы применяем для ежеквартальной оценки наших разработчиков. Мы поговорим о старой систем...
Всем привет! Меня зовут Александра Сорока, я занимаюсь синтезом речи в Тинькофф. А это — мой текст о том, зачем вообще думать о долгосрочной поддержке кода и ML-моделей. Я расскажу, почему мы отказали...
В своих проектах мы стараемся по мере необходимости покрывать код тестами и придерживаться принципов SOLID и чистой архитектуры. Хотим поделиться с читателями Хабра перев...
Приветствую вас (лично вас, а не всех кто это читает)! Сегодня мы: Создадим приложение (навык) Алисы с использованием нового (октябрь 2019) сервиса Yandex Cloud Functions. Настроим н...
Всем привет! В этой заметке я хотел бы поделиться своим подходом к организации и тестированию кода с использованием Redux Thunk в проекте на React. Путь к нему был долог и тернист, поэтому пост...