Проведение А/Б-тестов в Контур.Экстерн

Сергей Лысый
Системный аналитик КЭ.Web. 
Апрель 2026

Что такое А/Б-тест и для чего он нужен

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

Таким образом основное назначение А/Б-теста — свести к минимуму влияние внешних факторов и выделить причинно-следственную связь между изменением и эффектом на измеряемые метрики.

Нужен ли А/Б-тест для вашей задачи

В каких случаях А/Б-тест — это хорошая идея:

• Есть несколько вариантов решения (в том числе развилка «оставить по-старому» / «сделать по-новому»), и нельзя надёжно предсказать заранее, какой вариант будет лучшим.
• Высокая цена ошибки: изменение влияет на выручку, воронку платежного сценария, на ключевой сценарий, на ключевые метрики продукта.
• Нет возможности проверить гипотезу иначе: невозможен UX-тест, недостаточно исторических данных для сравнения или они нестабильны, сезонность или турбулентный период на рынке (нет возможности релевантно сравнить с историческими данными).

В каких случаях А/Б-тест можно не проводить:

• Очевидные улучшения, которые не создают рисков для ключевых метрик и сценариев: багфиксы, улучшение нефункциональных параметров (скорость отклика веб-приложения, скорость ответа сервера, увеличение лимитов и т.п.).
• Есть высокая уверенность в результате: поведение пользователей достаточно хорошо изучено и прогнозируемо через другие инструменты (UX-тест, высокая экспертность, анализ ретроданных, результаты схожих по портрету и сценарию А/Б-тестов).
• Ситуация не подразумевает проверку гипотезы или выбор варианта: изменение необходимо для соответствия внешним требованиям (соблюдение законодательства, безопасность, юридические ограничения), принято волевое решение руководства по реализации и раскатке фичи, изменение является частью более крупной инициативы, которая не может быть разделена на независимые варианты для тестирования.
• Издержки на проведение А/Б-теста выше, чем цена ошибки: небольшие изменения с контролируемым риском, которые проще и быстрее раскатить и докрутить на ходу, чем проводить А/Б-тест.

Основной критерий 1: поможет ли А/Б-тест снизить неопределённость и изменить или подтвердить решение. Если заранее понятно, что результаты А/Б-теста не будут использованы для изменения решения, значит А/Б-тест можно не проводить.
Основной критерий 2: стоимость А/Б-теста ниже стоимости неопределённости. Если дешевле будет включить, посмотреть метрики и обратную связь, и докрутить по ним, чем запускать А/Б-тест, то скорее всего так и стоит сделать.

А/Б-тест и статистический анализ

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

Пример: запустили А/Б-тест двух вариантов формы создания заявки на продажу, за неделю на каждый из вариантов попало 10 тысяч пользователей, в варианте А создано 1000 заявок, совершено 500 продаж, в варианте Б создано 1700 заявок, совершено 900 продаж. Конверсия варианта А: 10% в заявку, из них 50% в продажу; конверсия варианта Б: 17% в заявку, из них 53% в продажу. В этом варианте и без теории вероятностей видно, что вариант Б работает значительно лучше варианта А — даёт больше заявок, и соответственно больше продаж, а количество событий даже на первый взгляд выглядит достаточным, чтобы не переживать о том, что разница между вариантами это удачное совпадение. Разница в конверсии из заявки в продажу (А:50%, Б:53%) небольшая, возможно это случайность, возможно её стоит рассмотреть подробнее как зацепку для повышения конверсии из заявки в продажу, но нет особого смысла изучать её в рамках решения по А/Б-тесту — вариант Б очевидно лучше решает изначально поставленную задачу по конверсии в заявку, и числа достаточно большие, чтобы это было видно без теории вероятностей.

Применение результатов А/Б-теста

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

При подготовке А/Б-теста важно правильно определить генеральную совокупность. Обычно генеральной совокупностью являются пользователи, которые составляют целевую аудиторию продукта или вносимого изменения (фичи), но не всегда. Генеральной совокупностью могут быть технические сущности системы («группа организаций», «пространство», «документооборот»), сущности бизнеса («клиент», «абонент», «организация», «инн-кпп») и прочие варианты. Кроме того, бывает, что заявленный портрет целевой аудитории для некоторой новой фичи делится на подпортреты, например портрет «отправляет отчёты в ФНС» делится на подпортреты «отправляет редко (раз в год)», " отправляет со средней частотой (раз в квартал)" и «отправляет часто (раз в месяц или чаще)», и хотя фича помогает всему портрету целиком, но ядром его целевой являются те, кто отправляет часто; в таком случае может возникать желание проводить А/Б-тест только на ядре целевой, но тогда и экстраполировать результаты можно только на ядро, и нельзя на остальные части портрета. И наоборот — при проведении А/Б-теста на выборке из обобщённого портрета нельзя экстраполировать результаты только на некоторую часть этого портрета; например при выборке из портрета «отправляет отчёты в ФНС» (со всеми подпортретами) и получении в результате некоторого значения, например среднеарифметического по скорости отправки отчёта — это значение можно экстраполировать на генеральную совокупность «отправляет отчёты в ФНС», но нельзя экстраполировать на её отдельную часть, например на подпортрет «отправляет часто (раз в месяц или чаще)». Таким образом при дизайне А/Б-теста первый и очень важный шаг такой:

Сформулировать, на какую аудиторию планируем экстраполировать результат А/Б-теста.

Эта аудитория и будет генеральной совокупностью.

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

Как составить выборку

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

Способы получения репрезентативной выборки

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

select top 6000 UserId, NEWID() as randomValue
from #TargetAudience
order by randomValue

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

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

Этот способ лучше тем, что на начало эксперимента полученные группы будут одинаковы именно по тем метрикам, по которым будем проводить А/Б-тест, и одинаковы именно в том смысле, в котором мы будем их сравнивать — на основе стат.критерия.

Способ реализован в утилите get-similar-groups. Для запуска утилиты нужна таблица со списком всех пользователей целевой аудитории, где для каждого пользователя посчитаны метрики А/Б-теста.

Количество пользователей в группе

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

Для Экстерна в группе рекомендуется иметь 2000 пользователей.

Как определить метрики для А/Б-теста

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

Примеры:

Цель — уменьшить время отправки отчёта. В качестве метрики выбираем время на отправку отчёта. Данные для расчёта метрики в этом случае — таблица с колонками [id отчёта, время на отправку]. Из неё можем посчитать параметры распределения: среднее и медиану времени на отправку отчёта.

Цель — каждый пользователь станет быстрее отправлять отчёты. В качестве метрики выбираем агрегированную метрику (например медиану) времени отправки отчёта на пользователя. Данные для расчёта метрики — таблица с колонками [id пользователя, медиана времени на отправку], которая может быть получена из таблицы [id пользователя, id отчёта, время на отправку отчёта] группировкой по пользователю и расчётом медианы времени на отправку отчёта пользователем. Из таблицы с медианой времени на отправку по пользователю можем посчитать параметры распределения: среднее и медиану.

Примеры из жизни:

Патчинг подписанта: формализация задачи, описание метрик

Как проходило АБ-тестирование виджета

Какую агрегирующую функцию выбрать. Отличие среднего от медианы.

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

Для большинства метрик в КЭ это не так. Типичная форма распределения метрики в КЭ такая:

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

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

Для такой формы распределения среднее арифметическое оказывается смещено к хвосту распределения, и не отражает то, что мы имеем в виду, говоря «в среднем». Медиана лучше отражает это понятие для такого вида распределений.

Медиана - рекомендуемая функция для агрегирования значений.

Какой статистический критерий использовать

Так как большинство параметрических критериев использует среднее арифметическое и дисперсию для расчёта значимости, а делают это они в предположении нормальности распределения, такие критерии не подходят для большинства метрик по КЭ.

Поэтому используем критерий, который не накладывает требование нормальности к данным:

U-критерий Манна – Уитни - рекомендуемый статистический критерий для рассчёта значимости.

Сколько должен длиться А/Б-тест

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

Исходя из предметной области КЭ для А/Б-тест полезно проводить даты, которые охватывают основные этапы сдачи отчётности: межотчётность, период сдачи отчётов, период требований и корректировок.

2 месяца: месяц до отчётности и месяц после — хороший период для проведения А/Б-теста.

Возможны аргументы за то, чтобы проводить А/Б-тест за более короткий срок: фича не привязана к сценарию сдачи отчёта, или сценарий сдачи отчётов выполняется постоянно (например у ОБ). Если аргументы убедительны, то можно сократить срок А/Б-теста.

2 недели: пользователи успеют познакомится с фичей и прожить с ней цикл рабочей недели.

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

Кейсы проведённых А/Б-тестов можно найти в wiki-пространстве К.Экстерна.