В A/B-тесте пользователи могут совершать покупки многократно. Почему опасно считать каждую покупку независимым наблюдением?
Покупки одного пользователя связаны между собой, поэтому они не являются независимыми наблюдениями. Если считать их независимыми, размер выборки искусственно завышается, стандартная ошибка занижается, а статистическая значимость может оказаться ложной.
Единицей анализа обычно должна быть единица рандомизации — например, пользователь. Для каждого пользователя считают целевую метрику за период, включая нулевое значение для тех, кто не совершил покупку.
Классическая статистика предполагает, что наблюдения независимы либо что зависимость между ними корректно учтена моделью. В экспериментах это связано с понятием экспериментальной единицы: именно на уровне пользователя, устройства, компании или другого объекта обычно назначают вариант.
В продуктовой аналитике один пользователь часто порождает множество событий: просмотры, сессии, заказы и платежи. Развитие событийной аналитики сделало такую структуру данных повседневной, поэтому методы анализа должны учитывать вложенность событий внутри пользователей.
Предположим, в каждой группе A/B-теста находится по 10 000 пользователей. Вариант B генерирует 30 000 покупок, но эти покупки могут принадлежать всего нескольким активным клиентам.
Если использовать покупки как независимые строки, наблюдений формально станет 30 000, хотя независимых объектов по-прежнему около 10 000 пользователей. Пользователи с большим числом покупок получат непропорционально большой вес, а тест может обнаружить эффект там, где устойчивого изменения пользовательского поведения нет.
Последствие особенно опасно для решений о запуске: команда может выкатить вариант, который увеличивает число повторных покупок у небольшой группы, но не улучшает результат типичного пользователя или даже ухудшает его.
Сначала нужно определить единицу рандомизации и оценочный объект. Если вариант назначался пользователю и пользователь мог видеть только один вариант, основной анализ следует проводить на уровне пользователя.
Для метрики «выручка на пользователя» каждому пользователю присваивают общую выручку за заданный период, включая ноль для пользователей без покупок. Затем сравнивают распределения пользовательской выручки между группами. Так сохраняется правильный вес пользователей и учитывается массовая доля тех, кто ничего не купил.
Если бизнес-метрика действительно относится к отдельной покупке, покупочный уровень можно использовать для описания или моделирования. Но стандартные ошибки нужно корректировать с учётом кластеризации по пользователю: например, применять кластер-робастные стандартные ошибки, бутстрэп по пользователям или модели со случайными эффектами.
Простое агрегирование по пользователю не решает все проблемы. Выручка обычно имеет асимметричное распределение с редкими крупными значениями, поэтому полезно заранее определить период измерения, правила обработки возвратов и выбросов, а также основную метрику и способ оценки неопределённости.
Есть важный компромисс: пользовательский анализ обычно даёт корректное обобщение на пользователей, но может иметь большую дисперсию. Покупочный анализ может быть чувствительнее к изменениям внутри активной аудитории, однако без корректного учёта кластеризации создаёт чрезмерно оптимистичные доверительные интервалы.
Если рандомизация проводилась на уровне компании, семьи или устройства, кластером для оценки неопределённости должен быть именно этот уровень, даже если внутри него много пользователей или событий. Уровень анализа нельзя выбирать только по тому, где находится больше строк данных.
В сервисе подписки тестовый экран оплаты увеличил число транзакций на 4%. При анализе на уровне транзакций результат оказался статистически значимым, и команда рассматривала немедленный запуск.
Рассматривались два варианта. Первый — оставить транзакционный анализ: он прост и хорошо показывает изменения среди уже покупающих пользователей, но предполагает независимость транзакций и может переоценить объём доказательств. Второй — агрегировать данные по пользователю и сравнить число транзакций на пользователя, включая нули; этот подход лучше соответствует рандомизации, но имеет большую вариативность.
Выбрали второй вариант как основной, а транзакционный показатель оставили дополнительной диагностикой. После пересчёта доверительного интервала эффект оказался неопределённым: рост был сосредоточен у небольшой группы часто покупающих клиентов. Релиз не признали доказанно успешным и продолжили тест с заранее заданным периодом наблюдения.
Нет. Оно обязательно не как универсальное правило, а когда нужно получить корректный вывод о пользовательском эффекте и рандомизация выполнена на уровне пользователя. Для событийных или транзакционных метрик можно анализировать строки событий, если статистическая модель явно учитывает зависимость внутри пользователя и соответствует поставленному вопросу.
Тогда нарушается предположение о независимом назначении варианта на уровне пользователя. Нельзя безоговорочно относить все его события к одной группе: часть эффекта может быть вызвана переносом поведения между вариантами. Нужно определить корректную единицу назначения, исключить или отдельно обработать пользователей с нарушением протокола и заранее зафиксировать правило анализа.
Покупка сама может быть следствием воздействия варианта. Если анализировать только купивших, группы сравниваются после фильтрации по переменной, на которую повлиял эксперимент. Это может скрыть ухудшение конверсии или создать искусственную разницу среди оставшихся пользователей. Основной анализ обычно должен включать всех пользователей, которым был назначен вариант, а условные показатели среди покупателей использовать как дополнительные диагностические метрики.