🆎 Что делать, если классическая схема A/B-эксперимента не работает

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

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

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

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

Когда все просто: классический A/B

Базовая схема A/B-теста кажется предельно ясной. Мы делим аудиторию на группы, как правило, по хешу от user_id, и каждой группе показываем свою версию продукта. Одна получает контроль, другая — новую фичу.

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

Когда все ломается: общий ресурс

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

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

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

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

Альтернатива №1: временное разбиение

Когда разбиение по пользователям не дает независимости, можно переключиться на разбиение по времени. Простейший вариант — запускать контрольный алгоритм в одни часы, а тестовый — в другие. Например, с 12:00 до 15:00 работает контроль, а с 15:00 до 18:00 — тест.

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

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

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

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

Альтернатива №2: кластерные тесты

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

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

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

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

Гибридный подход

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

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

Как выбрать схему A/B-эксперимента

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

Чтобы этого не произошло, важно начинать не с запуска, а с понимания. Как устроена ваша система? Конкурируют ли пользователи за общий ресурс? Влияют ли они друг на друга напрямую или через инфраструктуру? Если таких взаимодействий нет — используйте классическую схему с разбиением по user_id. Если есть — подберите вариант, который максимально изолирует группы: временное чередование, кластеры, гибрид.

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

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