Введение
В настоящей статье речь идет об анализе данных, а конкретнее - анализе условно-бесплатных игр-сервисов, обычно называемых free to play games или F2P. Вероятно, рассуждения будут уместны и для других интернет-сервисов, будь то социальная сеть или интернет-магазин.
Тема эта нынче популярная, публикаций - масса, и, на первый взгляд, попытка добавить сюда своего доморощенного контента - затея довольно глупая.
Однако, при ближайшем рассмотрении, большинство доступных в сети материалов о метрике “ретеншен” - очень однотипны и к тому же весьма незначительной глубины, недостаточной для практической работы.
В частности, повсеместно можно найти формулу ретеншена (retention rate), как отношения возвратов к установкам, и некоторый список его разновидностей (ролинг ретеншен, например), узнать, что метрику можно считать за разный период времени, а также прочитать рассуждения о влиянии метрики на качество игры и получить множество советов, как его повысить. Казалось бы все доступно и понятно, причем, не только профессиональным аналитикам, но и менеджменту.
Но постойте. А не слишком ли бодро авторы переходят от вычисления простой дроби к принятию решения о переделке продукта? Посмотрели на какие-то цифры и уже собираетесь тратить ресурсы на разработку? Вы действительно уверены, что достоверно определили значение искомой метрики? Вы уверены, что вы получили достаточно аналитической информации для принятия решения?
Нет. Вообще-то совсем недостаточно разделить число измеренных возвратов на число измеренных установок и наивно полагать, что метрика известна. Мы имеем дело со случайной величиной, значение которой можно измерить лишь приблизительно.
Насколько приблизительно? От чего это зависит? Как это зависит от результатов измерений? Как это зависит от внешних факторов, таких как, например, качество трафика, день недели или качество маркетинговых материалов? Можно ли учитывать эти факторы для более точного определения искомой метрики и как это сделать?
Доступных широкому кругу читателей материалов, сфокусированных на этих вопросах, довольно мало. Например, простой поиск в интернете фраз “ретеншен статистическая значимость” или “ретеншен биномиальное распределение” выдает примерно 0 полезных ссылок, а ведь нужно еще было догадаться написать эти фразы в поисковике! Знания приходится разыскивать в учебниках по теории вероятности и математической статистике, причем в такой учебник необходимо погрузиться действительно глубоко - изучить его первую половину, посвященную теории вероятности, далее перейти к изучению статистики, разобраться в куче терминов и формул, и примерно где-то в последней четверти учебника начинаешь понимать, как правильно сформулировать вопросы, и находить на них ответы.
Таким образом и возникла идея написать доступным языком статью, а возможно и цикл, посвященный вопросам измерения этой метрики с точки зрения математический статистики, но при этом не закапываясь слишком глубоко в математику, и не отрываясь от продуктовых задач.
Статья ориентирована на широкую аудиторию - не только опытных аналитиков, но и аналитиков начинающих, а также для менеджеров продуктов, продюсеров, проджекст менеджеров, геймдизайнеров, и других сотрудников компаний-паблиширов, принимающих решения о судьбе игровых проектов на основе предоставляемой им аналитической информации. Я постараюсь объяснять все на понятных примерах, довольно подробно, с графиками, но небольшим количеством формул, а также избегать, по-возможности, введения некоторых сложных терминов, если этого можно избежать.
Надеюсь, фидбэк профессионального сообщества позволит исправить ошибки, если, вдруг, они присутствуют в моих рассуждениях и терминологии. Буду очень рад комментариям, дополнениям, уточнениям, исправлениям.
Благодарности
Огромное спасибо Филиппу Управителеву за подробную рецензию статьи. Мне пришлось многое переделать, но это точно было не зря.
Определение
Информация из этого раздела является вводной. Вы можете смело пропустить ее, если из хорошо знакомы определением понятия “ретеншен”.
Под словом “ретеншен” я буду понимать метрику, называемую в англоязычной литературе “retention rate“.
В русскоязычной литературе можно встретить альтернативные наименования этого термина, например, “возврат пользователей” или “удержание”, однако, по моим наблюдениям, использование подобных смысловых переводов скорее вносит путаницу, чем способствует пониманию, ведь перевод по транскрипции давно и успешно прижился профессиональном сообществе. Также может показаться странным, что я пишу “ретешен”, а не “ретеншен рейт”, как следует из английского термина. Но, опять же по моим наблюдениям, чаще используется именно короткое “ретеншен”, без второго слова. Среди двух возможных вариантов транскрипции “ретеншен” и “ретеншн” я использую “ретеншен” как более благозвучный - все-таки следование 3-х согласных подряд в конце слова для русского языка совсем противоестественно.
Ретеншен (англ. retention rate) - это отношение количества пользователей, продолжающих пользоваться интернет-сервисом (например, F2P игрой) через некоторое время после первого использования, к количеству людей, изначально им воспользовавшихся. Что можно выразить простой формулой:
(1)
где
Uinst - количество пользователей, изначально установивших игру,
Uret - количество пользователей, продолжающих играть в нее в нее через некоторое время.
Часто это значение умножают на 100, чтобы получить проценты, но я буду, обычно, использовать значения в диапазоне от 0 до 1, чтобы избежать лишних преобразований в формулах.
“Продолжающий играть” пользователь (или “вернувшийся”) - это человек, который некогда запустил игру впервые, а затем еще раз запустил ее, хотя бы один раз, в другой день, позже. Момент первого запуска игры принято называть установкой, или инсталлом. Это несколько неверно, ведь часть людей скачивают игру, устанавливают, но ни разу потом не запускают. Вероятно, традиция пришла из веб-сервисов, где почти невозможно скачать веб-страницу, но не открыть ее. Будем чтить традиции и называть первый запуск установкой, предполагая что пользователь, установивший игру, обязательно немедленно ее запустил.
Из определения следует, что значения ретеншена лежат в диапазоне от 0 до 1 (или от 0% до 100%), поскольку количество вернувшихся игроков не может превышать количество изначально пришедших, и оба числа в дроби положительны.
Существует несколько разновидностей ретеншена, коротко упомянем их для полноты картины. Они отличаются, как правило, только числом в числителе, то есть они фиксирую факт возврата пользователя несколько разными способами. Вот несколько примеров.
В формуле классического ретеншена 1-го дня в числителе стоит количество людей, вернувшихся в игру строго на следующий день после установки игры.
Аналогично мы можем посчитать классический ретеншен 2-го дня. В числителе будут пользователи, вернувшиеся в игру строго во 2-й день после установки.
Можно поступить иначе - посчитать всех людей, вернувшихся в игру в 1-й день после установки или когда-либо позднее. Эту метрику называют “роллинг ретенншен 1-го дня”.
Есть и некоторые другие разновидности, но не будем на них останавливаться, поскольку они редко используются на практике. Практически всегда вы будете использовать классический ретеншен, ведь вы хотите сравнить метрику своего продукта с конкурентами, а почти во всех публикуемых аналитических отчетах и другой доступной вам аналитической информации используется именно классический ретеншен.
Очень часто на практике рассматривается история изменения ретеншена по дням, поскольку именно она отражает историю изменения качества вашего продукта. Пример графика истории изменения классического ретеншена изображен ниже. На графике изображены классический ретенешен 1-го дня, 2-го дня, 3-го дня и 7-го дня, 14 дня и 28 дня. В каждой точке графика метрика рассчитана по приведенной выше формуле, то есть в знаменателе - число людей, фактически установивших игру в конкретный день, а в числителе - строго те из них, кто вернулся в игру строго через 1, 2, 3, 7, 14 и 28 дней после установки игры.
На графике хорошо видно,что ретеншен - это случайная величина - в разные дни наблюдаются разные значения. Также видно, что вероятность возврата пользователя в игру снижается со временем, прошедшим от момента установки - почти во все дни значения ретенеша 2-го дня меньше чем 1-го дня, значения 3-го дня меньше чем 2-го, 7-го дня меньше чем 3-го и т.д, Но в отдельные дни эта закономерность нарушена, например, в одной из точек ретеншен 3-го дня оказывается больше ретеншена 2-го дня. Причина опять же в случайной природе рассматриваемого процесса.
Постановка задачи контроля ретеншена
Ретеншен принято называть главной метрикой качества игры из-за его простой формулы и простой и понятной логики его трактовки “если игра качественная, то она понравится игроку, следовательно, он через некоторое время в нее вернется, а если не понравилась - не вернется”.
Более того ретеншен зачастую называют не просто главной метрикой качества, но и вообще САМОЙ ГЛАВНОЙ МЕТРИКОЙ ПРОЕКТА, и вот почему. Если ретеншен плохой, и пользователи не остаются в игре, то нет смысла привлекать в игру новых пользователей и тратить на это средства - они ведь ведь все равно скоро уйдут. Следовательно, нет смысла тратить силы на улучшение монетизации проекта - пользователей ведь нет, кого тут монетизировать. Поэтому надо сначала увеличивать главную метрику - ретеншен проекта, повышая его качество, потом уже привлекать пользователей и только в третью очередь - монетизировать их. Коротко данное утверждение известно как “Retention-Acquisition-Monetization”.
Именно поэтому, паблишеры принимают решение о будущем проекта, исходя, в первую очередь, из значений ретеншена, именно поэтому вопросы правильного измерения этой метрики является весьма важными, и именно поэтому на ней я сосредотачиваю внимание. Хотя, конечно, многие утверждения статьи можно распространить и на другие метрики тоже.
На практике мы имеем несколько задач, возникающих перед паблишером, в том числе:
Проект выпущен в софтланч, надо минимальными средствами, привлекая минимальное количество пользователей, определить ретеншен проекта с заданной достоверностью и принять решение, что далее делать с проектом - продолжать его развивать или нет.
Проект уже некоторое время находится в продакшене и вот выпущен очередной его патч. Надо проанализировать патч, сравнить его качество с предыдущими и понять, стала ли игра лучше или хуже, и принять решения о дальнейших планах.
Контроль метрики при изменении маркетинга, например качественного и/или количественного состава трафика, промо материалов и т.д.
Регулярный контроль метрики с целью обнаружения каких-то нештатных ситуаций, например, технических сбоев или проблем с трафиком.
Первая задача скорее интересна довольно крупным паблишерам, выпускающих очень большое количество проектов, в частности, паблишерам гиперказуальных игр. Прочие задачи применимы ко всем проектам, которые давно уже выпущены в продакшен.
Отметим, что в всех перечисленных задачах, как правило, речь идет об измерении краткосрочного ретеншена, а не долгосрочного, поскольку для измерения долгосрочного ретеншена по определению требуется очень много времени. На практике же паблишер хочет разобраться в текущей ситуации и принять решение как можно скорее - за несколько дней, или, максимум, 1-2 недели. Поэтому мы будем фокусировать внимание больше на краткосрочном ретеншене.
Вероятностный подход к измерению ретеншена
Возьмем один конкретный день жизни проекта. Измерим количество установок в этот день и количество возвратов в игру из этих установок на следующий день и, далее, посчитаем ретеншн 1-го дня как отношение возвратов к установкам по приведенной выше формуле (1)
(1)
Однако, полученное нами значение - лишь одно из многих возможных, ведь мы имеем дело со случайной величиной. Если мы измерим значение метрики на следующий день - оно будет другое, через день опять другое, и т.д. Что хорошо видно на рисунке 1.
Если мы будем рассматривать только одно или даже несколько измеренных значений метрики за разные дни (так называемую, выборку), можно легко сделать неправильные выводы о качестве проекта. Нам может показаться, что проект слишком хорош, если вдруг измеренный ретеншн случайно оказался большим или же наоборот, слишком плох, если друг ретеншен оказался низким.
Владельца продукта интересует вовсе не это текущее значение. Его интересует наиболее вероятное значение этой случайной величины, то есть среднее значение или, если использовать более строгую терминологию - математическое ожидание случайной величины. Именно это среднее значение и является критерием качество проекта.
Поэтому рассмотрим далее интересующую нас метрику с точки зрения теории вероятности и математической статистики и постараемся понять, а насколько точно его можно оценить.
Биномиальное распределение ретеншена
Возврат пользователя - бинарное событие, у которого существует два возможных исхода - пользователь вернулся (происходящего с вероятностью p) или пользователь не вернулся (происходящего с вероятность q = 1-p).
Это можно сравнить с подбрасыванием монетки. Но только чуть-чуть необычной монетки, какой-то неровной монетки, одна сторона которой почему-то выпадает систематически чаще.
Последовательность подобных независимых случайных событий, вероятность «успеха» в каждом из которых постоянна и равна некоторой величине p, подчиняется биномиальному распределению, выражаемой формулой Бернулли:
(2)
где
и - так называемый биномиальный коэффициент
Примечание! В настоящей статье мы будем предполагать, что события возврата пользователей в игру являются независимыми и равновероятными в течении одного календарного дня, что делает легитимным применение биномиального распределения для оценки статистической значимости наших измерений. Утверждение это, однако, небесспорно, и было бы очень интересно обсудить это вопрос в комментариях к настоящей статье.
Итак, формула (2) может быть использована для оценки распределения абсолютного числа вернувшихся пользователей. Чтобы получить из нее формулу распределения ретеншена, как отношения числа возвратившихся пользователей к числу установок n, нужно от переменной k (абсолютное число возвратившихся пользователей) перейти к относительному числу
Если мы выполним это несложное преобразование, то получим формулу распределения
Далее такое распределение в относительных величинах по оси x (от 0 до 1) я буду называть “биномиальное распределение ретеншена”, в отличие от обычного биномиального распределения, где по горизонтальной оси указано абсолютное количество экспериментов от 0 до n
Форма графиков распределений (2) и (3) абсолютно идентична, они отличаются только масштабирующими коэффициентами по осям X и Y
Вот как будет выглядеть график биномиального распределения ретеншена для математического ожидания равного 0.35 или 35% (довольно распространенное на практике значение ретеншена) и разного количества установок: 16, 32, 64, 128, 256.
Важные свойства такого распределения:
Распределение - дискретное, причем количество точек совпадает с числом установок.
Математическое ожидание случайной величины (иначе говоря, ее среднее значение), ожидаемо, равняется вероятности возврата пользователя, то есть M = p (на графике - это величина 0.35). Это и есть та самая величина, которую нам необходимо найти - искомое значение ретеншена.
Дисперсия биномиального распределения ретеншена, позволяющая нам судить о достоверности наших измерений, рассчитывается по простой формуле:
(3)
Стандартное отклонение σ вычисляется как корень из дисперсии и равняется
(4)
Графики подобной формы зачастую называют “колокол” из-за некоторого внешнего сходства.
Геометрический смысл стандартного отклонения - ширина “колокола”. Чем больше величина стандартного отклонения, тем более сильным является возможный разброс значений случайной величины.
Нормальное распределение ретеншена
Одно из самых известных утверждений теории вероятности, центральная предельная теорема вероятностей, гласит, что сумма достаточно большого количества слабо зависимых случайных величин, имеющих примерно одинаковые масштабы (ни одно из слагаемых не доминирует, не вносит в сумму определяющего вклада), имеет распределение, близкое к нормальному. Функция плотности вероятности нормального распределения (или функция Гаусса) имеет следующую формулу:
где
???? - математическое ожидание случайной величины, в нашем случае - это ретеншен
σ - стандартное отклонение случайной величины.
Применим это утверждение к нашей задаче. Возьмем некоторый набор большого количества событий возврата пользователей в игру, построим их распределение - согласно центральной предельной теореме оно должно быть нормальным.
Постойте! Здесь противоречие! В предыдущей главе говорилось, что распределение будет биномиальным, а не нормальным.
Противоречия нет. При большом количестве экспериментов, эти две совершенно разные формулы (2) и (5) будут давать практически один и тот же результат. В учебниках по математической статистике (например [1]) утверждается, что аппроксимация биномиального распределения нормальным считается допустимой, если выполняется критерий:
n*???? ≥ 4 и n*(1-????) ≥ 4 (6)
где
???? - математическое ожидание случайной величины, то есть, в нашем случае - искомый ретеншен,
n - количество экспериментов испытания Бернулли, то есть, в нашем случае - количество установок.
Покажем это на практике. Построим графики биномиального распределения ретеншена и нормального распределения с одинаковыми математическим ожиданием и стандартным отклонением и наложим их друг на друга. Всего рассмотрим 10 вариантов графиков: 2 варианта математического ожидания ретеншена, p = 0.35 и p = 0.1, для каждого из которых рассмотрим 5 вариантов стандартного отклонения, соответствующих разному количеству экспериментов (установок), а именно n = 16, 32, 64, 128, 256.
Точками отображены графики биномиального распределения. Для каждого из них по формуле (4), на основе известного математического ожидания и количества установок, рассчитано стандартное отклонение и, далее, для этого стандартного отклонения построен график соответствующего нормального распределения, изображенный сплошной линией того же цвета.
Как видно из графиков, при значении математического ожидания p=0.1 биномиальное распределение сильнее отличается от нормального, чем при значении p=0.35. Происходит это из-за множителя p*(1-p), который приближается к нулю тем сильнее, чем ближе p к 0 или 1. На практике значения ретеншена близкие к 1 не встречаются (как бы не хотел этого каждый разработчик и паблишер), поэтому таким случаем пренебрегаем, а вот малые значения, около нескольких процентов, конечно, имеют смысл - они соответствуют долгосрочному ретеншену, например, месячному, двухмесячному и т.д. Однако, как было указано в начале статьи, здесь мы сосредотачиваем свое внимание на краткосрочном решение. Именно поэтому в примере было рассмотрено значение 0.35, которое, как правило, соответствует довольно неплохому ретеншену 1 дня, а таже значение 0.1, которое вполне может соответствовать ретеншену 4-7 дня.
Как видим, при значении ретеншена 0.35 (такой ретеншен первого дня, как правило, принято считать довольно неплохим) уже всего 16 установок (красная кривая на рисунке 3) вполне достаточно, чтобы биномиальное распределение весьма точно аппроксимировать нормальным. При значении 0.1 отклонение более значительное, но и здесь более чем приемлемое - всего лишь 64 установки (зеленая кривая на рисунке 4) достаточно, чтобы графики неплохо совпадали.
Итак, мы можем заменить биномиальное распределение нормальным, если это требуется по какой-нибудь причине. Но, кстати, а какова эта причина? Зачем потребовалось нормальное распределение? Почему не использовать биномиальное, как выше было предложено.
Дело в том, что многие известные методы теории вероятности и математической статистики сформулированы и справедливы именно для нормального распределения. А поскольку некоторые их них мы планируем ниже применять, уместно было бы обосновать возможность их применения. В частности:
Распределение является симметричным.
Можно использовать правило 3-х сигм, гарантирующее 99.7-процентную вероятность правильного экспериментального определения случайной величины в определенный коридор значений.
Можно использовать метод наименьших квадратов для поиска математического ожидания, поскольку этот метод как раз минимизирует ошибку, возникающую в результате нормально распределенного шума.
Также в литературе по математической статистике, особенно довольно старой, рекомендуется использовать нормальное распределение вместо биномиального по причине большой вычислительной сложности последнего, а точнее, из-за сложности вычисления биномиальных коэффициентов.
Доверительный интервал значений ретеншена
Полученные выше знания позволяют судить о статистической значимости измерений.
Пусть Uinst пользователей установили игру в некоторый день и Uret из них вернулись на следующий день
Рассчитаем значение ретеншена по формуле. (формально, в статистике это значение называют точечной оценкой математического ожидания, но далее в статье мы не используем этот термин, можно его не запоминать)
(1)
Полагая, что распределение метрики ретешнена является биномиальным, мы мы можем оценить стандартное отклонение на основе основе количества установок и полученной величины Rfact с использованием уже известной нам формулы:
(7)
И, далее, для оценки коридора возможных значений (или как, принято говорить в математической статистике, доверительного интервала) ретеншена мы используем известное правило 3-х сигм (которое мы можем применить из-за большого сходства нашего распределения с нормальным). Это правило утверждает, что вероятностью 99.7 % искомое значение ретеншена будет лежать в коридоре (Rfact - 3 *σ, Rfact + 3 *σ). Или:
P( M ∈ (Rfact - 3 *σ, Rfact + 3 *σ) ) ~= 0.997 (8)
Также можно использовать правило 2-х сигм и правило одной сигмы, которые гласят:
P( M ∈ (Rfact - 2*σ, Rfact + 2*σ) ) ~= 0.95 (9)
P( M ∈ (Rfact - σ, Rfact + σ) ) ~= 0.68 (10)
Еще раз проговорим, что означают эти утверждения, немного другими словами:
С вероятностью ~99.7% (то есть почти 100%) наша метрика (ретеншен) лежит в диапазоне от Rfact - 3 *σ до Rfact + 3 *σ
С вероятностью ~95% метрика лежит в диапазоне от Rfact - 2 *σ до Rfact + 2 *σ
С вероятностью ~68% метрика лежит в диапазоне от Rfact - σ до Rfact + σ
Используем этот метод на практике. Приведенный ниже python-код рассчитывает и отображает на графике и в таблице значения доверительных интервалов по одной, двум и трем сигмам для разного количества установок от 8 до 65536. В качестве математического ожидания ретеншена выбрано значение 0.35, как часто встречающееся на практике.
#Мониторинг доверительных интервалов значений ретенеша для разного количества инсталлов
import numpy as np
import matplotlib.pyplot as plt
import pandas
def plot_borders_of_binomial_distribution(numbers, means, linestyle='solid', marker = '', draw_up_borders = True, draw_down_borders = True):
Sigma = np.sqrt (np.clip(means * (1-means), 0, 1) / numbers )
R_min_1s = np.clip(means - Sigma, 0, 1)
R_min_2s = np.clip(means - Sigma * 2, 0, 1)
R_min_3s = np.clip(means - Sigma * 3, 0, 1)
R_max_1s = np.clip(means + Sigma, 0, 1)
R_max_2s = np.clip(means + Sigma * 2, 0, 1)
R_max_3s = np.clip(means + Sigma * 3, 0, 1)
plt.plot(numbers, means, color = "black", linestyle = linestyle, marker = marker)
if draw_down_borders:
plt.plot(numbers, R_min_1s, color = "yellow", linestyle = linestyle, marker = marker, label = 'σ')
plt.plot(numbers, R_min_2s, color = "orange", linestyle = linestyle, marker = marker, label = 'σ x 2')
plt.plot(numbers, R_min_3s, color = "red", linestyle = linestyle, marker = marker, label = 'σ x 3')
if draw_up_borders:
plt.plot(numbers, R_max_1s, color = "yellow", linestyle = linestyle, marker = marker)
plt.plot(numbers, R_max_2s, color = "orange", linestyle = linestyle, marker = marker)
plt.plot(numbers, R_max_3s, color = "red", linestyle = linestyle, marker = marker)
Uinst = 2 ** np.arange(3, 3+14)
R_0 = np.ones_like(Uinst) * 0.35
Sigma = np.sqrt (R_0 * (1-R_0) / Uinst )
Sigma_x2 = Sigma * 2
Sigma_x3 = Sigma * 3
fig, axs = plt.subplots(figsize=(15,10))
axs.set_xscale('log')
plot_borders_of_binomial_distribution(Uinst, R_0, linestyle = 'solid', marker = 'o')
plt.legend(bbox_to_anchor=(0.85, 0.95), loc=2, borderaxespad=0., fontsize = 17)
plt.show()
R_0 = np.round(R_0 * 100, 2)
Sigma_x2 = np.round(Sigma * 2 * 100, 2)
Sigma_x3 = np.round(Sigma * 3 * 100, 2)
Sigma = np.round(Sigma * 100, 2)
arr = np.vstack([Uinst, R_0, Sigma, Sigma_x2, Sigma_x3])
df = pandas.DataFrame({"Installs": Uinst, "Retention": R_0, "σ": np.round(Sigma, 2), "σ x 2": Sigma_x2, "σ x 3": Sigma_x3})
print(df)
Ниже приведен результат работы программы - в виде графика и таблицы. По горизонтальной оси графика отложено количество установок (в логарифмической шкале), по вертикальной оси - значение ретеншена (кривая черного цвета) и коридор его допустимых, соответствующих этому математическому ожиданию по одной (кривые желтого цвета), двум (оранжевый цвет) и трем сигмам (красный цвет).
Таблица 1. Зависимость стандартного отклонения ретеншена от количества установок
№ |
Installs |
Retention |
σ |
σx2 |
σx3 |
0 |
8 |
35.0 |
16.86 |
33.73 |
50.59 |
1 |
16 |
35.0 |
11.92 |
23.85 |
35.77 |
2 |
32 |
35.0 |
8.43 |
16.86 |
25.30 |
3 |
64 |
35.0 |
5.96 |
11.92 |
17.89 |
4 |
128 |
35.0 |
4.22 |
8.43 |
12.65 |
5 |
256 |
35.0 |
2.98 |
5.96 |
8.94 |
6 |
512 |
35.0 |
2.11 |
4.22 |
6.32 |
7 |
1024 |
35.0 |
1.49 |
2.98 |
4.47 |
8 |
2048 |
35.0 |
1.05 |
2.11 |
3.16 |
9 |
4096 |
35.0 |
0.75 |
1.49 |
2.24 |
10 |
8192 |
35.0 |
0.53 |
1.05 |
1.58 |
11 |
16384 |
35.0 |
0.37 |
0.75 |
1.12 |
12 |
32768 |
35.0 |
0.26 |
0.53 |
0.79 |
13 |
65536 |
35.0 |
0.19 |
0.37 |
0.56 |
К сожалению, наблюдаемая картина неутешительна - нам необходимо очень-очень много данных, чтобы обеспечить достаточную статистическую значимость измерений для принятия решений о судьбе проекта!
Возьмем последнюю строчку в таблице, соответствующую очень популярному проекту, привлекающему 65 тысячи новых пользователей в день (то есть примерно 2 миллиона в месяц). Доверительный интервал значений ретеншена этого проекта будет составлять 35+-0.5%, ширина интервала - 1%, что, кажетя, довольно неплохо. Но 2 миллиона установок в месяц - огромная величина, доступная лишь единичным проектам. На практике редко идет речь о таком большом количестве новых установок, особено на стадии софтланча, когда контроль ретеншена проекта имеет самое большое значение. Вероятно, вы будете наблюдать у своего проекта несколько тысяч новых пользователей или даже, возможно, сотен новых пользователей в день. Но, если мы посмотрим на графике точку 1024 установки, то интервал возможных значений метрики будет составлять уже целых от ~30.5% до ~39.5%!
Ну разве допустимо такой большой возможный разброс значений при исследовании метрики? Однако, вот вам свежий пример статьи в довольно авторитетом источнике, совершенно игнорирующий этот факт. Метрика Retention. Что означает, как ее рассчитать и как ее улучшить. В статье приводится пример расчета метрики для количества установок равного 1300, и, как несложно рассчитать по предлагаемой выше методике, ширина доверительного интервала измерений по 3-м сигмам в этом случае составит ~8%! Однако, авторы сразу же переходят к советам по изменению продукта, совершенно не затрагивая вопросы статистической значимости. Советы неплохие, и последовательное применение их действительно может, во многих ситуациях улучшить качество и, следовательно, измеряемую метрику. НО! На практике (тут уже говорю как практик с 20-летним стажем, 10 лет из которых посвящены разработке F2P-игр) увеличить ретеншен проекта невероятно сложно, вам придется выгрызать каждый процент зубами, и если вам удалось как-то поднять метрику на 1-2 процента - это действительно большая победа. Но при доверительном интервале 8% вы даже не сможете зафиксировать эту победу, поскольку это изменение не выйдет за пределы доверительного интервала, вы не увидите это на фоне шумов.
Поэтому, конечно, хотелось бы иметь способ, позволяющий измерять ретеншен значительно точнее чем +-4%, желательно, с точностью хотя бы +-1%.
Какой доверительный интервал выбрать?
Первый, и самый очевидный способ “повысить точность измерений” - сузить доверительный интервал и вместо коридора “три сигмы”, как рассматривалось выше, использовать “две сигмы” или даже “одну сигму”.
Да, так действительно поступают. Но тут важно понимать следующее.
Это вовсе не способ повысить точность измерений (поэтому выше я написал эту фразу в кавычках)! Мы сужаем доверительный интервал ценой возможной ошибки, ведь при использовании коридора “две сигмы”, с вероятностью 95% метрика лежит внутри этого коридора, и, следовательно, существует вероятность 5%, что метрика лежит вне коридора.
Доверительный интервал “две сигмы”, обычно, считается приемлемым, поскольку очень уж заманчиво сузить доверительный интервал аж в полтора раза ценой всего лишь 5%-ой ошибки измерения. Интервал “одна сигма”, обычно, уже считают неприемлемым, потому что плата за ошибку уж слишком велика - интервал сократили еще в два раза, но ошибка увеличилась с 5% до 32%.
Ошибка 5% - дорогая ли это цена? Как это понять?
Как правило, вполне допустимая. Эта цена ваших ошибочных бизнес решений. Например, по ошибке закрыли проект, который был где-то вблизи пороговых значений метрик; или по ошибке слишком рано вывели из софт-ланча в релиз проект, который был у пороговых значениях метрик ; или по ошибке решили, что хватит поднимать решеншен проекта, давайте займемся уже монетизацией и т.д. Все это звучит не очень страшно. Вероятность ошибки этих бизнес-решений хотя бы приблизительно измерили, и она довольно мала, что нельзя сказать о большинстве других принимаемых бизнес-решений.
Повысить точность измерений - сложная задача
Теперь все-таки поговорим о том, как по-настоящему повысить точность измерений, не манипулируя "количеством сигм".
Очевидный способ повысить точность измерений - увеличить количество установок.
Формула (6) стандартного отклонения показывает, что для удвоения точности измерения метрики нам необходимо увеличить количество измерений в 4 раза (поскольку в формуле стандартного отклонения количество установок стоит в знаменателе под квадратным корнем). Следовательно, если мы имеем ~1000 установок в день и доверительный интервал по трем сигмам шириной ~9% , то для получения интервала шириной ~1% потребуется примерно в 16 раз больше установок.
Один из очевидных способов увеличить количество данных - увеличить количество дней наблюдений. Здесь необходимо отметить следующие проблемы.
Потребуется немало времени чтобы увидеть результат, причем каждый день необходимо тратить средства на приобретение пользователей и оперирование проекта, а команда разработки, возможно, будет частично простаивать или делать что-то ненужное, ожидая результаты измерений.
В течении всего длительного периода измерений мы не можем гарантировать равную вероятность события возврата пользователя (по целому ряду причин, о которых мы поговорим ниже), поэтому (несмотря на то, что предельная теорема вероятности обеспечивает нам примерную нормальною форму распределения), доверительный интервал будет более размытым, чем при измерениях, произведенных в течении одного дня. Поэтому, де факто, увеличение продолжительности наблюдений в 4 раза не позволит увеличить точность измерений в 2 раза.
Полученную метрику необходимо будет сравнивать с эталонными значениями, полученынми таким же способом, в течении такого же промежутка времени, тех же 16 дней, при таких же условиях. Обычно, это весьма сложно обеспечить, потому что каждый проект живет своей жизнью - у каждого свои ивенты, патчи, сбои, которые существенно влияют на проект.
Другой возможный способ повысить количество данных - увеличить количество установок в день. Очевидно, что при такой стратегии мы получаем некоторые плюсы:
Точность измерений скорее всего будет более высокой, поскольку пользователи прибывают в один день, и, следовательно, мы можем с большей уверенностью говорить о равной вероятности возврата каждого из них.
Кроме того, мы выигрываем время, следовательно сможем быстрее принять решение и таким образом сэкономить средства компании.
Однако, здесь есть другие проблемы, уже маркетингового характера. В частности.
Как правило увеличение количества пользователей требует нелинейного увеличения рекламного бюджета компании, то есть закупить много трафика в единицу времени стоит нелинейно больше, чем мало. Увеличение объема трафика в 4 раза в день вполне может привести к увеличению рекламного бюджета в 8 раз.
При таком большом росте объемов трафика, как правило, невозможно обеспечить его качественный состав близкий к тому, что был до этого, ведь нам придется поднимать рекламный бюджет и/или закупать трафик на других площадках или в других регионах (возможно, более дешевых, чтобы сэкономить бюджет), в результате чего аудитория рекламной кампании изменится, и, следовательно, изменится состав пользователей, приходящих в ваш проект. Следовательно и метрики проекта изменятся.
Существует и множество других причин для манипулирования с объемами трафика как для повышения доходов, так и для развития и продвижения игры, и это значительно более сложный вопрос, чем просто повышение статистической значимости метрик. Например, для PvP-игры количество пользователей является весьма критичным для геймплея, поэтому закупка трафика в малых объемах будет сильно занижать метрики проекта, и всегда необходимо поддерживать большое количество пользователей.
Таким образом, хотя и нельзя совсем исключать возможность покупки трафика в большем объеме для увеличения статистической значимости измерений, все-таки это нельзя считать доступным и приемлемым методом. Поэтому далее нам необходимо сосредоточить свое внимание на методах, позволяющих повысить качество измерения метрики без изменения количества установок в день
Почему ретеншен меняется со временем и как это учитывать
Настоящая глава выходит за пределы предмета текущей статьи и является постановкой задачи для следующей статьи из планируемого цикла.
Каковы же упомянутые выше причины, из-за которых ретеншен меняется с течением времени. Их множество. Среди самых заметных выделим следующие.
Ретеншен всегда падает со временем, что особенно критически заметно в первые дни жизни проекта. Если, например, сразу после релиза игры значение метрики составляет сказочные 55%, то уже во второй день метрика может составлять 50%, а через месяц-два опуститься до 40%. Это объясняется изменением состава привлекаемой аудитории. В первые дни жизни проекта к вам приходят самые лояльные и преданные пользователи, многие из которых давно ждали вашу игру или же сегодня узнали о ней безо всякой рекламы просто потому, что каждый день они роют интернет в поисках чего-то подобного. Чем больше проходит времени от момента релиза, тем меньше остается таких лояльных пользователей, и метрика снижается.
Существуют устойчивые колебания метрики в течении недели. В частности, как правило, люди больше играют в выходные дни, поэтому пользователи, впервые пришедшие в игру в пятницу, вернутся в нее в субботу с бОльшей вероятностью, чем в другие дни. В противоположность этому, пользователи, установившие игру в воскресенье, не очень охотно возвращаются в понедельник.
Технические проблемы приводят к тому, что игроки не могут войти в игру, что снижает ретеншен как в день, предшествующий техническим проблемам (они не смогли вернуться в игру на следующий день из-за проблем), так и в день появления проблем (они пришли в игру во время проблем и поэтому сразу разочаровались в ней и, следовательно, неохотно возвращаются). Кроме того, крупный технический сбой могут приводить к повышению ретеншена на следующий день после сбоя, и вот почему. Если вдруг игра недоступна и пользователи совсем не могут войти в игру, то среди них есть как старые, так и вновь пришедшие пользователи, которые пытаются войти, но не могут, даже в самый первый раз. Поэтому игровой профиль для таких игроков не создается и установка не учитывается в статистике. Среди этих есть доля очень лояльных пользователей, которые, несмотря на неудачу в первый день, возвращаются в игру на следующий день, и именно в этот момент их установка учитывается; а затем они приходят в игру снова через день, и, таким образом завышают ретеншен в день после технических проблем. Таким образом, технический сбой искажает метрику за целых 3 дня!
Выпуск патчей, конечно, тоже влияет на все метрики, в том числе ретеншен. Здесь во-первых, влияет качество патча - его фичи и контент. Удалось ли вам улучшить игру или нет - метрика может как возрасти, так и снизиться. Во-вторых, выпуск патча сопровождается, как правило, техническими работами, во время которых игра становится недоступной на некоторое время, поэтому патч является одновременно и техническим сбоем, к которому применимы упомянутые выше закономерности - метрика искажается на целых 3 дня наблюдений.
Календарные ивенты. Праздничные дни, каникулы или, например, ковидный локдаун - все эти события значительно меняют паттерн поведения многих пользователей. В частности, во время каникул разница между днями недели может стать практически незаметной.
Источник и регион трафика. Если ваш маркетинговый отдел не сидит сложа руки, источники трафика и регионы будут постоянно меняться, что приводит к тому, что в игре появляются какие-то другие пользователи, поведение которых будет чем-то отличаться от предыдущих. Причин масса. Они могут плохо понимать язык интерфейса вашей игры, у них может быть другой менталитет или просто плохой пинг из-за большой физической удаленности от ваших серверов и т.д.. Ваша игра также может получить фичеринг платформы, и вы получите резкий рост объемов трафика, но, как правило менее качественного, чем трафик из ваших основных источников.
Качество рекламных материалов тоже может влиять на метрики проекта, в том числе на ретеншен. Всем известно, как сделать промо-материалы, которые обеспечат большое количество установок в ущерб ретеншену - надо создать так называемый мислид, то есть фальшивые скриншоты и видео из какой-то другой игры (обычно, несуществующей), значительно более крутой - хай-поли графика, интересный и необычный игровой процесс и т.д.. Как правило, установок будет больше нормы, но многие пользователи тут же уйдут из игры, поняв обман, и, следовательно, ретеншен будет плохой.
Учитывать эти факторы для повышения точности измерения ретеншена проекта весьма непросто. Однако, при наличии большого количества данных наблюдений о своем проекте, а желательно, многих проектов, задача разрешима по крайней мере отчасти. Именно этой теме хотелось бы посвятить следующую статью цикла публикаций, которая выйдет в свет, если настоящая статья вызовет достаточный интерес.
Выводы
Подведем итоги.
Метрика “ретеншен”, с некоторыми оговорками, подчиняется закону биномиального распределения, а также, согласно предельной теореме вероятностей, закону нормального распределения. Знание закона распределения позволяет нам оценить доверительный интервал значений метрики.
Измеренное значение будет точечной оценкой математического ожидания ретеншена.
Дисперсию D=σ^2 вычисляется аналитически по очень простой формуле и зависит только от величины математического ожидания ретеншена и количества установок. Эту формулу используем для оценки дисперсии, подставив в нее вычисленную выше оценку матожидания ретенешна и также известное количество установок.
Стандартное отклонение σ считаем как квадратный корень из дисперсии
-
Находим доверительный интервал значений ретеншена.
По правилу “3 σ” с вероятностью 99.7% искомая метрика лежит в доверительном интервале плюс минус 3 σ от измеренного значения ретеншена.
По правилу “2 σ” с вероятностью 95% метрика лежит в доверительном интервале плюс минус 2 σ от измеренного значения ретеншена
Обычно, используется интервал “2 σ”, потому что он в полтора раза уже и дает вероятность ошибки всего 5% - приемлемая плата за ошибочное бизнес решение.
Итак, зная лишь текущее значение метрики и количество инсталлов мы оценили доверительный интервал возможных значений метрики. Устраивает полученная точность измерений? Можем ли мы ее повысить?
Да, это возможно, но задача нетривиальна.
Для повышения точности измерений необходимо сужать распределение, а для этого необходимо увеличивать количество измерений (то есть установок).
Зависимость стандартного отклонения от числа установок нелинейная - для линейного увеличения точности измерений необходимо увеличивать установки квадратично.
Мы не можем увеличить количество установок каждый день, ведь за трафик надо платить, это дорого, и, к тому же, привлечение дополнительного трафика искажает наблюдаемую метрику. Этот способ практически недоступен.
Следовательно, необходимо суммировать количество установок за большой период наблюдений, но это весьма непросто, ведь метрика очень значительно меняется со временем под влиянием массы факторов.
Таким образом, необходимо разработать метод более точного измерения метрики “ретеншен” в течении нескольких дней наблюдений, чему и будут посвящены следующие статьи планируемого цикла.
Заключение
Предположу, что некоторые аналитики со стажем, дочитавшие статью до конца, сейчас готовы уличить меня в обмане и забросать гневными комментариями. Казалось бы, я анонсировал во введении что-то новое и интересное, вот наконец-то добрался до этой интересной темы, и вдруг уже статья завершена.
Прошу понять меня правильно. Эта работа требует определенных усилий, и физических и эмоциональных. Изначально я планировал уложиться в одну статью, но необходимость прояснять некоторые существенные (с моей точки зрения) моменты увеличивает объем публикации. Поэтому считаю целесообразным сделать паузу, опубликовать текущий материал, посмотреть, комментарии читателей, и, надеюсь, получить эмоциональный заряд для продолжения работы. В итоге, вероятно, получится 3 статьи - именно так это пока выглядит в черновиках, но, конечно, ситуация может измениться в процессе.
Большое спасибо за внимание. Буду рад вашим комментариям.
Источники
Лисьев В.П. ТЕОРИЯ ВЕРОЯТНОСТЕЙ И МАТЕМАТИЧЕСКАЯ СТАТИСТИКА: Учебное пособие/ Московский государственный университет экономики, статистики и информатики. – М., 2006. – 199 с.
Биномиальное распределение https://ru.wikipedia.org/wiki/Биномиальное_распределение
Нормальное распределение https://ru.wikipedia.org/wiki/Нормальное_распределение
Центральная предельная теорема https://ru.wikipedia.org/wiki/Центральная_предельная_теорема
Метрика Retention. Что означает, как ее рассчитать и как ее улучшить https://gopractice.ru/product/retention/
-
Retention Rate: Definition, Strategies, & Examples https://amplitude.com/blog/retention-rate-meaning-use-cases-and-more
И, конечно https://www.google.com/search?q=ретеншен
Areso
А что делать со сложными играми, у которых retention заведомо ниже гиперкэжуалов и 3 в ряд?
dmitrybaltin Автор
Не понимаю вопрос. Теория вероятности работает независимо от того, гиперкэжуал у вас или нет, она не выбирает)
Ну, конечно, не надо сравнивать метрики сложных игр с гиперкэжуалом. Сравнивайте со своими референсами. Я, кстати, никогда не разрабатывал гиперкэжуал, и всего один раз в жизни разрабатывал 3 в ряд, и это было более 10 лет назад, еще на ПК)
Areso
По 3-в-ряд и гиперкэжам есть R2,R3, Rn, в открытых данных.
По остальным жанрам с этими данными очень плохо.
dmitrybaltin Автор
Да, мало данных, факт. Ну иногда крупные аналитические компании типа Appsflyer и Sensortower выкладывают в паблик какие-нибудь отчеты.