Руководство по A/B- и A/A/B-тестированию монетизации на платформе Appodeal

Компания Appodeal подготовила подробный туториал по сплит-тестированию монетизации на своей платформе.

В мобильном маркетинге широко распространена практика продуктового A/B-тестирования. Она позволяет быстро понять реакцию пользователей на:

новую графику;
изменения в интерфейсе;
перемены в расположении рекламных блоков и так далее.

Задача этого материала — рассказать, как правильно с помощью сплит-тестирования проверить эффективность тех элементов, которые отвечают за монетизацию приложения.

Руководство построено на примере работы с платформой Appodeal, которая в том числе позволяет отдельно проверять рекламную логику, отдельно — настройки «водопадов».

Выбор предмета тестирования

Первый шаг — решить:

что будет проверяться (изменение какого аспекта приложения);
какой результат планируется достичь (что должно «вырасти»).

Именно от этого этапа зависит успешное проведение теста.

Соответственно, в ходе этого этапа:

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

Какую метрику лучше выбрать для отслеживания

Как правило, мы фокусируемся на накопительном ARPU по итогу седьмого дня (здесь = LTV седьмого дня).

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

Согласно нашему опыту, ориентация на накопительный ARPU наиболее ликвидна, поскольку ее изменение говорит об изменении и всех дополнительных метрик.

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

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

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

Мы чаще всего проводим A/B-тестирование монетизации казуальных игр. Для нас седьмой день является оптимальным выбором. Уже к концу первой недели мы получаем достаточно информации не только о том, как нововведение сказалось на монетизации, но и на долгосрочном удержании пользователей.

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

Разумеется, кроме накопительного ARPU можно отталкиваться при оценке результативности и на другие метрики:

выручку к N-дню;
ARPDAU;
удержание к N-дню;
среднее проводимое в приложении время каждый день.

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

Еще можно выбрать второстепенную метрику для проверки.

Например, стоит задача проверить сразу две гипотезы:

согласно первой, «частота показа рекламы влияет на LTV седьмого дня»;
согласно второй «частота показа рекламы влияет на удержание седьмого дня».

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

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

Какие гипотезы достойны тестирования?

Проверить, стоит ли ваша гипотеза того, чтобы ради нее затевать A/B-тест, — очень просто. Если вы предполагаете, что в результате неких изменений проверяемая метрика измениться не более чем на 10%, то тратить время на тестирование не стоит. Достоверный и заметный на общем трафике результат вы вряд ли получите.

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

Гипотезы могут быть разные. Некоторые могут влиять только на монетизационные показатели (это тесты водопадов), но, как правило, проверка большинства гипотез затрагивает и продуктовые метрики приложения.

Вот список гипотез, которые мы успешно тестировали, проверяя их влияние на LTV седьмого дня:

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

Можно ли доверять результатам тестов?

Пользователь может определить ту вероятность корректности тестов, которая его устроит. Мы рекомендуем остановиться на 95%.

Повысить корректность можно даже до 99%, однако это потребует увеличение численности группы в два раза, а значит и времени тестирования.

Еще одним способом минимизировать ошибку является A/A/B-тестирование. О нем и поговорим.

A+A+B = A/A/B

Для повышения точности проверки гипотез Appodeal проводит так называемое A/A/B-тестирование.

Суть тестирование — добавление дополнительной когорты пользователей, аналогичной первой.

Подобный подход позволяет нивелировать ошибку, когда группа показывает случайный результат (если ее численность рассчитана на достоверность в 95%).

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

Финальное решение о выборе метода тестирования зависит от сроков тестирования и метрик.

Сколько человек должно принимать участие в тестировании?

Универсального ответа на этот вопрос нет. Все зависит от конкретной игры в конкретный отрезок времени.

Как определить, достаточная ли выборка?

Первое. Выбираем метрику, на которую будем ориентироваться. Мы берем накопительный ARPU седьмого дня (это небиноминальная метрика).

Второе. Выгружаем необходимые данные из медиации. Это можно сделать с помощью инструмента Ad revenue attribution. Он позволяет получить данные о выручке по пользователям за нужный период.

Третье. Рассчитываем количество пользователей, которые должны участвовать в тесте по формуле:

n=( (std**2) * (2*(Za+Zb)**2) ) / m**2

где:

Za=1.96 – для p-value=95 %
Zb=0.8416 – для мощности теста равной 80 %
m – чувствительность, величина разницы которую мы хотим уловить
std – стандартное отклонение, рассчитанное на основе исторических данных по ad revenue.

Также можно воспользоваться калькулятором статистической значимости для небиномиальных метрик (есть бесплатная триал-версия).

Настройка А/А/Б-теста

После того, как гипотезы сформулированы, а метрики для отслеживания выбраны — пора запускать тестирование.

Шаг первый — работа с выборкой

Сперва вы должны определить процент пользователей, который примет участие в тестировании.

Если вы хотите запустить тест, например, на 60% пользователей, то вы должны сформировать три сегмента по 20% пользователей в каждом.

На каком проценте пользователей вообще стоит остановиться?

Мы советуем проводить тестирование на всем трафике (важно понимать, что контрольная группа — часть тестирования).

Почему?

Чем больше охват, тем быстрее можно получить результат.

Шаг второй — создание сегментов

Сегмент — это часть аудитории, удовлетворяющая неким условиям (например, отобранная по полу, возрасту, региону или любому другому параметру, известному приложению и направляемому в Appodeal SDK).

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

Создание сегмента начинаем с присвоения ему имени. Оно затем будет указано в списке сегментов и появится в статистике показов по этому конкретному сегменту.

Сегмент без рекламы

Первая контрольная группа

Вторая контрольная группа

Шаг третий — настройка

После того, как тестовый сегмент создан, его необходимо настроить в зависимости от того, какой параметр вы собираетесь тестировать.

Тут же можно сгруппировать пользователей:

по типу устройства;
по версии приложения;
по средней продолжительности сеанса;
по версии ОС;
по совершившим покупки в приложении;
по совершившим покупки в приложении n-раз;
по зашедшим в приложение;
по находящимся онлайн и так далее.

Шаг четвертый — протестировать новый водопад

Что нужно сделать:

перейдить в DCC;
выбрать нужный тип рекламы;
создать или продублировать водопад;
изменить настройку рекламных блоков;
настроить водопад на своем тестовом сегменте.

Что чаще всего тестируют в монетизации?

Чаще всего речь идет о проверке рекламной сети и рекламной логики.

Проверка рекламной сети для определенного типа рекламы

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

Для выполнения проверки вы должны добавить соответствующий параметр в тестовый сегмент.

Проверка рекламной логики

Перед тестированием нужно добавить плейсмент, соответствующий тому, какой тип рекламы вы собираетесь тестировать, и не забыть выполнить нужные настройки по всем ГЕО (выставить частоту обновлений, время начала показа рекламы, интервалы и так далее).

К чему приводят подобные проверки?

В истории успеха Join Blocks, игры, прошедшей бизнес-акселератор Appodeal, именно такие эксперименты помогли найти наиболее оптимальный интервал между показами объявлений.

Основные рынки Join Blocks сильно отличались друг от друга, как и поведение игроков из этих стран. Поэтому интервал между показами рекламы нужно было определять отдельно для рынков СНГ, США и Бразилии. Такая оптимизация привела к увеличению ARPU на 20% в США и на 40% на рынках СНГ.

Важно: прежде чем переходить к анализу теста, необходимо дождаться, когда финализируется статистика нужного вам дня по пользователям. Так как последние пользователи попадут в тест позже, а вы, например, смотрите метрики седьмого дня, то статистика по ним должна какое-то время копиться, чтобы результат был корректным.

Как анализировать результаты A/A/B-тестирования

1) Перейдите в панель управления Appodeal и создайте отчет с рассматриваемыми показателями. Не забудьте выбрать дату установки в фильтрах, чтобы построить когортные отчеты.

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

3) Проанализируйте, как ваш тест повлиял на накопительный Ad ARPU седьмого дня.

Дополнительный комментарий: в приведенном выше примере мы видим, что Ad ARPU тестовой когорты меньше, чем Ad ARPU контрольных когорт на 20%.

4) Обратите внимание на коэффициент удержания и время, проведенное пользователем в игре в день. Если гипотеза предполагает, что тест должен влиять на удержание, то лучше подождать подольше, чтобы собрать больше данных.

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

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

5) Принимается заключение о ситуации.

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

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

К выводам можно приступать, если:

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

Конкретные примеры А/А/Б-тестирования монетизации

Тест интервала полноэкранного баннера после конца раунда

Гипотеза: увеличение частоты показа баннеров приведет к росту выручки, но не скажется значительно на других важных показателях.

Контрольная группа: дефолтный интервал между показами рекламы — две минуты.

Тестовая группа: нет дефолтного интервала (реклама показывается чаще).

Результат: в тестовой когорте основная метрика (Ad ARPU D7) на 10-15% выше, чем в контрольных группах. При этом на побочных метриках значительных различий между группами не наблюдается.

Тест конфигурации водопада

Гипотеза: добавление дополнительных рекламных блоков при удалении дешевого рекламного блока на интерстишалах приведет к улучшению ARPU 7 дня.

Контрольная группа: текущий (дефолтный) сетап.

Тестовая группа: добавлены следующие дополнительные рекламные блоки:

+ Admob 25, 35, 45, 60;
+ Notsy 40, 50;
— Admob 0 (all price).

Обратите внимание: Appodeal ограничивает опрос рекламных блоков в Admob (позволяется делать не более трех опросов в рамках одного показа).

В других сервисах медиации такого лимита нет. Однако есть риск, что сам Admob проведет пессимизацию, если используется более трех коллов в водопаде.

Результаты: добавление дополнительных рекламных блоков дало положительный результат (+15%) для ARPU 7 дня. Также увеличилась заполняемость и количество показов рекламы на пользователя (и это при удалении дешевого рекламного блока).

Оптимизация водопада для zero-IDFA пользователей (тех, кто не дает согласие на использование The Identifier for Advertisers)

Гипотеза: фокус на рекламе с низким флором приведет к увеличению выручки среди аудитории, не готовой делиться личными данными.

Контрольная группа: дефолтный сетап.

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

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

Поднялась заполняемость, увеличилось количество показов на пользователя, что в итоге привело к росту ARPU примерно на 8-10%.