В идеальном мире мы всегда рандомизируем пользователей по user_id и считаем метрики на уровне пользователя. На практике есть много ситуаций, где такой подход нарушает SUTVA и даёт завышенную значимость. В этих кейсах приходится переходить к кластерной рандомизации.
Вы тестируете изменение цены доставки в разных городах. Формально можно рандомизировать по пользователям: часть жителей города A попадает в тест, часть — в контроль. Но в реальности пользователи живут в общем ценовом окружении: обсуждают цены с друзьями, сравнивают с конкурентами, видят наружную рекламу.
Если внутри одного города часть людей платит по старой цене, а часть по новой, возникает сильный spillover: поведение пользователей зависит не только от их treatment-статуса, но и от того, что происходит вокруг. Гораздо естественнее рандомизировать целиком города, чтобы все жители одного города жили в одной ценовой реальности.
Логистическая команда тестирует новый алгоритм распределения заказов по курьерам. Если рандомизировать по заказам, один и тот же курьер в одной смене может обслуживать и тестовые, и контрольные заказы. Тогда treatment для части заказов изменяет загрузку курьеров для всех остальных заказов.
В результате время доставки заказов из «контроля» зависит от того, сколько тестовых заказов попало в ту же курьерскую зону. Правильнее рандомизировать зоны или курьеров целиком, чтобы вся нагрузка внутри кластера менялась согласованно.
Образовательный продукт запускает новый формат уроков. Если рандомизировать по ученикам внутри класса, учитель будет одновременно вести старую и новую программу, ученики будут обсуждать разные версии, домашние задания перемешаются — сильнейшая интерференция.
Похожая картина в ритейле: промо-материалы, выкладка товаров, обучение персонала — всё это делается на уровне магазина или региона, а не отдельного покупателя. Поэтому рандомизировать имеет смысл классы, школы, магазины, регионы, а не индивидуальных людей внутри них.
В социальных сетях, маркетплейсах и мессенджерах пользователи связаны графом. Treatment для одного пользователя (новый формат постов, другой алгоритм ранжирования, новая схема комиссий для продавцов) почти всегда меняет окружение других пользователей.
Если рандомизировать по user_id в такой среде, эффект «перетекает» из теста в контроль: друзья, коллеги, продавцы и покупатели одновременно участвуют в эксперименте с разными статусами. Это систематически нарушает SUTVA и делает наивную интерпретацию эффекта некорректной.
Правило: как только между пользователями появляются сильные взаимодействия (география, логистика, классы, социалка, маркетплейс) — задумывайтесь о кластерной рандомизации, даже если кажется, что user-level split проще технически.
Единица рандомизации — объект, которому назначается treatment (город, магазин, курьерская зона, класс, пользователь). Единица анализа — объект, на уровне которого вы считаете метрику и строите статистический тест (пользователь, заказ, сессия, город).
В простом user-level A/B-тесте эти уровни совпадают: мы рандомизируем по пользователям и считаем, например, выручку на пользователя. В кластерных экспериментах часто рандомизация и анализ оказываются на разных уровнях, и именно здесь начинаются типичные ошибки.
Представьте гео-эксперимент: 20 городов, в 10 подняли цены (тест), 10 оставили как есть (контроль). Всего 1 000 000 пользователей. Аналитик выгружает все чеки пользователей и запускает обычный t-test по 1M наблюдений. Формально N огромный, p-value почти нулевой.
Но реальный источник вариации — различия между 20 городами, а не между миллионом пользователей. Эффективный размер выборки ≈ 20, а не 1M. Если правильно учесть кластерную структуру, типичная ошибка первого рода (ложноположительные) может вырасти до 30–50% вместо ожидаемых 5%.
Маркетплейс тестирует новый алгоритм ранжирования по кластерам «продавец» или «регион», но метрику считает на уровне показов (impressions) или кликов по товарам. Показы одного и того же продавца или региона внутри кластера сильно скоррелированы.
Если запустить наивный t-test по показам, он будет считать, что каждый показ — независимое наблюдение, и сильно занизит дисперсию. Правильная единица анализа здесь — кластер (продавец, регион, магазин) с агрегированной метрикой, либо использование cluster-robust стандартных ошибок.
ICC (Intraclass Correlation Coefficient) показывает, какую долю общей вариации метрики объясняет принадлежность к одному и тому же кластеру. Это число от 0 до 1.
Допустим, у вас 10 городов по 100 000 пользователей в каждом. Если ICC близок к нулю, то пользователи внутри одного города не более похожи друг на друга, чем пользователи из разных городов — каждый новый пользователь добавляет почти независимую информацию.
Если ICC высок (например, из-за сильных региональных различий), то пользователи внутри одного города похожи: уровень спроса, сезонность, конкуренция. Тогда добавление ещё 10 000 пользователей из того же города почти не увеличивает информацию — вы, по сути, всё ещё имеете «один и тот же» кластер.
Пусть общая дисперсия метрики разбивается на компоненту «между кластерами» и «внутри кластеров»:
Чем больше σ²between относительно общей дисперсии, тем выше ICC и тем сильнее кластерный эффект.
| Контекст | ICC |
|---|---|
| Города, одна страна | 0.001–0.01 |
| Магазины розничной сети | 0.01–0.05 |
| Классы в школе | 0.05–0.20 |
| Курьерские зоны | 0.01–0.05 |
| Районы мегаполиса | 0.005–0.02 |
Кластерная структура данных раздувает дисперсию стандартных оценок. Эту инфляцию удобно описывать через design effect (DEFF) и эффективный размер выборки.
Здесь m — средний размер кластера (число пользователей в городе/магазине/классе), n — общее число наблюдений (пользователей).
Пусть у вас гео-эксперимент с 20 городами и 1 000 000 пользователями. Средний город даёт m = 50 000 пользователей. Из pre-period оценили ICC ≈ 0.05.
Тогда:
На практике из-за неоднородности кластеров и более реалистичных ICC часто говорят в терминах «эффективный N ≈ число кластеров». В грубом приближении для множества реальных гео-экспериментов 1M пользователей в 20 городах превращаются в neff ≈ 2000 и, в пределе, в те самые 20 точек на уровне городов.
Чем выше DEFF, тем меньше реальный power эксперимента и тем больше MDE (минимальный детектируемый эффект) при фиксированном горизонте. Эксперимент, который на бумаге выглядит сверхмощным при user-level предпосылках, в реальности может быть почти бессмысленным при кластерной структуре.
Правило: перед запуском гео- или кластерного эксперимента обязательно оцените ICC по pre-period и скорректируйте power-анализ через design effect. Никогда не планируйте мощность, игнорируя кластеры.
Когда рандомизация или естественная структура данных кластерная, наивные стандартные ошибки (SE), которые предполагают независимость наблюдений, становятся некорректными. Есть два базовых подхода к корректному inference.
Мы строим метрики на уровне кластера (город, магазин, класс), а не на уровне пользователя. Например, считаем средний чек по каждому городу, а затем сравниваем 10 тестовых городов с 10 контрольными с помощью t-test по 20 наблюдениям.
Это простой и прозрачный подход: каждая точка в анализе соответствует независимому кластеру, предпосылка независимости становится куда более реалистичной.
Второй путь — использовать регрессию на уровне пользователей, но с кластерно-устойчивыми SE (cluster-robust / cluster-sandwich). В этом случае сами коэффициенты регрессии не меняются, но их стандартные ошибки пересчитываются с учётом внутрикластерной корреляции.
При небольшом числе кластеров (например, 10–20 городов) обычные асимптотические формулы для cluster-robust SE ведут себя плохо. Тогда используют более аккуратные методы, например, wild cluster bootstrap, который даёт более корректные p-value и доверительные интервалы.
| Ситуация | Рекомендуемый подход |
|---|---|
| Мало кластеров (< 30), агрегируемая метрика (средний чек, CR) | Агрегация до кластера + t-test / permutation test |
| Много кластеров (50+), нужны ковариаты и регрессия | Регрессия с cluster-robust SE по кластерам |
| Мало кластеров и сложная модель, важны точные p-value | Wild cluster bootstrap поверх регрессии |
| Гео-эксперимент с сильной неоднородностью кластеров | Агрегация + randomization inference (перестановки treatment между кластерами) |
Перед запуском и анализом кластерного эксперимента пройдитесь по следующему чеклисту.