Как стать автором
Обновить
Dodo Engineering
О том, как разработчики строят IT в Dodo

Как увеличить мощность A/B-теста, если мало данных и время поджимает

Время на прочтение6 мин
Количество просмотров4.4K

Привет, меня зовут Настя, я продуктовый аналитик в Dodo. Недавно мы провели A/B-тест по запросу геолокации у пользователей. Когда я приступила к анализу, то с ужасом обнаружила, что данных — кот наплакал, а бизнес уже очень ждёт результатов. Тогда мне пришлось пустить в ход свои «секретные техники» A/B-тестирования.

В этой статье расскажу, как мне удалось увеличить выборку без загадочного бутстрапа, причём тут раскатка и почему отсутствие результата — тоже результат. Статья может быть интересна как аналитикам и продакт оунерам, так и всем неравнодушным, интересующимся A/B-тестированием.

Немного о самом тесте

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

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

Тест раскатился на всех неавторизованных пользователей в России и состоял из трёх групп:

  • контрольная группа с системным всплывающим окном на этапе карты (Группа 0);

  • группа с системным всплывающим окном с просьбой предоставить геолокацию на этапе саджестов (Группа 1);

  • группа с кастомным всплывающим окном, в котором мы объясняем пользователю, что если он предоставит доступ к своей геолокации, то это улучшит релевантность саджестов (Группа 2).

Группа 0, Группа 1, Группа 2.
Группа 0, Группа 1, Группа 2.

Но есть (не)один нюанс. Сложности при анализе результатов

Первый нюанс — это то, что раскатка версии приложения с тестом может повлиять на качество данных. Так, мы запустили A/B-тест одновременно с раскаткой, и получили 2-3 недели данных, которые пришлось выкинуть в мусорку.

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

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

Второй, более очевидный нюанс. Стоит ещё при планировании теста задаться вопросом, а можем ли мы уже посчитать целевые метрики теста или нужно завести отдельные события? Хотим ли мы анализировать только метрики или же ещё и взаимодействие с новой функциональностью (клики на баннеры, а не только доли с геолокацией в тестовой и контрольной группах)? В нашем дизайне мы упустили возможность анализа кликов по алертам и довольствовались только целевой метрикой. Не надо так!

Как увеличить выборку

Таким образом, мне пришлось откинуть первые 2 недели эксперимента и на момент анализа я имела всего 10 с небольшим дней. Это было очень мало для теста, и тогда я решила увеличить выборку, уменьшив временные интервалы. «А что если срезать долю пользователей с геолокацией не за день, а за час?» — подумала я. И не прогадала.

Так, например, вместо 10 наблюдений, я разом получила в 24 раза больше: 24*10 = 240 наблюдений. Также я смогла заметить выбросы, различия поведения в утренние и вечерние часы активности и в будни и выходные.

Можно ли было получить ещё больше наблюдений?

В итоге мы смогли увеличить число наблюдений, уменьшив их временной интервал. Вместо анализа подневных долей пользователей с геолокацией проанализировали часовые интервалы. Можно ли было взять ещё меньшую дискретность — хороший и всё ещё открытый вопрос. Если в одно прекрасное утро мы проснёмся и решим использовать минутные интервалы, то, скорее всего, получим зашумленные данные. Сессия пользователя обычно длится от нескольких минут до получаса, и если мы начнём снимать измерения слишком часто, то можем столкнуться с ситуацией, где пользователь ещё не успел даль доступ к геолокации, а мы на него уже наклеили лейбл «без геолокации».

Вот такие милые горбики у меня получились.
Вот такие милые горбики у меня получились.

Также, именно при анализе этих диаграмм, я заметила, что дневное распределение пользователей имеет более одного пика: один утренний, а второй — обеденный. Так и пришла идея сравнивать отдельно группы по времени суток: Night, Morning, Day и Evening и отдельные подгруппы будних дней и выходных.

Стал ли тест мощнее и что это действительно значит?

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

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

Так, например, согласно этому калькулятору, для маленького эффекта и уровня значимости 0.05 мощность теста на моих первоначальных 10 наблюдениях составила 10%, а для 240 - 60%. Это все еще не рекомендуемые 80%, однако это огромное улучшение.

Собственно, перейдём к самим тестам.

z и t тесты: какой выбрать?

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

Расчёт z-статистики.
Расчёт z-статистики.
Пояснения к формуле z-теста

\hat p_1, \hat p_2— пропорции в группах 1 и 2 (например, процент людей с геолокацией);

n_1n_2— общее число наблюдений в группах 1 и 2;

\hat p— общая пропорция.

Более детально:

\hat p_1 = \frac{x_1}{n_1}\hat p_2 = \frac{x_2}{n_2}\hat p = \frac{x_1 + x_2}{n_1 + n_2}

где x_1, x_2 — число ожидаемых исходов в группе 1 и 2 (например, число людей с геолокацией в обеих группах).

t-тест , наоборот, учитывает поведение в каждый из дней, но имеет более жёсткие предпосылки. На самом деле, существует несколько подходов к применению t-критерия на практике. Я придерживаюсь того, в котором для t-теста данные не должны быть долями и должны быть распределены нормально.

Расчёт t-теста для двух выборок с разной дисперсией.
Расчёт t-теста для двух выборок с разной дисперсией.
Пояснения к формуле t-теста

\bar x_1, \bar x_2— средние значения в группах 1 и 2;


S_1^2, S_2^2— несмещённые выборочные дисперсии в группах 1 и 2;

n_1, n_2— число наблюдений в группах 1 и 2.

Я решила проводить оба этих теста на выделенных подгруппах. Для z-теста я использовала метрику «процент пользователей с геолокацией», а для t-теста — «число пользователей с геолокацией». При разбиении по группам я не выявила разницы между буднями и выходными, поэтому сравнивала по группам Night, Morning, Day, Evening.

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

Тем не менее, я не стала рассматривать выборки целиком, а разделила их на подгруппы по времени суток. К тому же, утренняя и дневная группы уже распределены около-нормально, поэтому их не нужно логарифмировать. Так как эти две группы самые многочисленные и сильно превосходят Night и Evening, я решила сфокусироваться на них.

Долгожданные результаты

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

После того, как я провела ряд t-тестов и z-тестов, я не смогла установить значимых различий и в этих двух группах.

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

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

Как трактовать такие результаты, или Всё не напрасно

 Так почему же отсутствие результата — тоже результат?

  1. Мы точно уверены, что существующее решение работает, и работает хорошо.

  2. Узнали что-то новое о наших пользователях: они меньше доверяют нам, если спрашивать у них геолокацию без веской причины (группа 1 <= группа 2), но при этом даже с объяснением причины те, кто не готов предоставить доступ, не хотят этого делать (группа 0 <= группа 2).

  3. Мы не спровоцируем непредвиденные побочные эффекты, если оставим все как есть.

  4. Нам удалось улучшить аналитический опыт и накопить больше знаний для последующих тестов и гипотез.

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
А как вы поступаете, когда мало данных для A/B-теста?
27.78% Продлеваю тест5
27.78% Использую бутстрап5
16.67% Делаю то же самое, что и автор статьи3
16.67% Использую свои секретные техники3
38.89% Сворачиваю тест и иду грустить7
Проголосовали 18 пользователей. Воздержались 4 пользователя.
Теги:
Хабы:
Всего голосов 17: ↑17 и ↓0+17
Комментарии7

Публикации

Информация

Сайт
dodo.dev
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия