A/B-тестирование на сайте

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

Что такое A/B-тестирование и какие задачи оно решает

A/B-тестирование — метод сравнения двух (или нескольких) вариантов страницы или элемента, при котором трафик разделяется на сегменты, каждому сегменту показывается свой вариант, а результат измеряется по одной согласованной метрике: CR (Conversion Rate — доля посетителей, совершивших целевое действие), CTR (Click-Through Rate — доля кликов от показов), средний чек, выручка на визит, доля отказов. Вариант, давший статистически значимо лучший результат, выбирается в продакшен.

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

Задачи, для которых метод подходит: проверка отдельных гипотез по конверсии (новая кнопка, новое УТП, новая структура карточки), сравнение двух вариантов посадочной перед масштабированием рекламы, тестирование изменений в воронке (упрощение формы, новый шаг подтверждения), проверка ценовых экспериментов. Задачи, для которых метод не подходит без оговорок: оценка SEO-изменений (Google не рекомендует длительное показ разных версий одной страницы по одному URL), оценка эффекта на retention за пределами 1–2 недель, проверка изменений с очень малой ожидаемой разницей при низком трафике.

Зрелый процесс выглядит так: команда формулирует гипотезу, дизайнер и разработчик готовят вариант B, аналитик рассчитывает минимальную выборку и длительность теста, тест запускается, по достижении выборки данные оцениваются на статистическую значимость, по результатам — либо вариант B становится новым основным, либо отклоняется. Каждый шаг — отдельная компетенция, и без любого из них тест превращается в «у нас тестировалось, мы запустили B, конверсия вроде упала».

Виды тестов и этапы проведения

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

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

Виды A/B-тестов

Классический A/B — два варианта одного элемента: исходный (контроль A) и изменённый (B). Самый частый и самый управляемый вариант. Применяется для отдельных гипотез: новая кнопка, новый заголовок, изменённая форма. Требует минимальной выборки и даёт ясный вывод.

A/B/n — три и более вариантов одного элемента. Используется, когда нужно сравнить несколько концепций (три варианта заголовка, четыре варианта дизайна кнопки). Требует выборки в 1,5–2 раза больше классического A/B и более длительного теста, но даёт сравнение не «лучше или хуже», а «какой из вариантов лучший».

MVT (Multivariate Testing, многовариантное тестирование) — одновременная проверка нескольких элементов в разных комбинациях. Например, два варианта заголовка × два варианта изображения × два варианта кнопки = 8 комбинаций. Требует значительной выборки (на каждую комбинацию отдельно), применяется на проектах с большим трафиком от 50 000 визитов в месяц. Даёт информацию о взаимодействии элементов: иногда сочетание В+В даёт результат лучше суммы отдельных В.

Split URL — разные варианты по отдельным URL, переадресация на серверной стороне или на JavaScript-уровне. Применяется при значительных изменениях, когда контроль и тест отличаются по структуре, длине, шаблону. Технически — это сравнение страниц «landing-a» и «landing-b», объединённое разметкой эксперимента. Сложнее в настройке, чем подмена элемента, но единственный путь для тестов разных шаблонов.

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

Этапы проведения теста

Стандартный цикл из семи этапов покрывает все виды тестов. Длительность каждого этапа зависит от трафика и сложности гипотезы, но порядок неизменен.

Минимальная длительность сбора — 2 недели, даже если расчётная выборка набирается за неделю. Причина — недельная цикличность трафика: понедельник и пятница могут отличаться по составу аудитории. Тест меньше полного недельного цикла рискует измерить сезонный шум вместо эффекта правки. Максимальная длительность — 6–8 недель: дальше растут риски внешних факторов (рекламные кампании, сезонность, обновления алгоритмов), которые искажают результат.

Как сформулировать рабочую гипотезу

Гипотеза — основа теста. Плохая гипотеза превращает любой тест в «мы что-то изменили, посмотрим, что получится». Хорошая гипотеза задаёт ожидание результата, объясняет механизм и фиксирует метрику. На зрелом этапе продвижения сайтов работа с гипотезами становится регулярным процессом: банк гипотез пополняется из аналитики, аудита конверсии, опросов клиентов и пользовательских исследований. Стандартный шаблон формулировки — «если изменить X, то Y вырастет на N%, потому что Z».

X — конкретный элемент страницы (заголовок, кнопка, форма). Y — измеримая метрика (конверсия формы, CTR баннера, выручка на визит). N% — ожидаемая величина изменения, ориентир для расчёта выборки. Z — обоснование, основанное на данных предыдущих исследований, тепловых картах, опросах клиентов, аналогичных кейсах или признанных принципах юзабилити.

Примеры рабочих и слабых гипотез

Сравнение двух формулировок показывает разницу. Слабая: «улучшим первый экран». Рабочая: «если заменим обобщённое УТП “надёжно и профессионально” на конкретное “ремонт квартир в Минске за 28 дней с фиксированной сметой”, то конверсия в заявку с первого экрана вырастет на 15–25%, потому что конкретные параметры снимают возражение “обещают одно — делают другое”, выявленное в опросе клиентов за прошлый квартал».

Рабочая гипотеза опирается на данные: количественные (аналитика, тепловые карты) или исследовательские (опросы, user-тестирование, обращения в поддержку). Гипотеза «нужно сделать кнопку красной, потому что красный — цвет действия» — слабая, потому что обоснование общее и не привязано к контексту проекта. Гипотеза «нужно изменить цвет кнопки на контрастный, потому что на тепловой карте видно, что 40% пользователей прокручивают мимо неё, не замечая» — рабочая.

Источники для рабочих гипотез включают: отчёты аналитики (страницы с высоким трафиком и низкой конверсией), тепловые карты (Webvisor в Яндекс Метрике, hotjar-аналоги), записи сессий, опросы клиентов после сделки и отказа от сделки, обращения в поддержку (повторяющиеся вопросы — сигнал о пробелах на сайте), сравнение с конкурентами (особенности, которых нет у проекта), отраслевые исследования юзабилити.

Приоритизация гипотез

В проекте всегда десятки гипотез, тестировать все одновременно невозможно. Приоритизация — стандартный шаг между этапом «список гипотез» и этапом «дизайн теста». Применяются методики PIE (Potential, Importance, Ease) и ICE (Impact, Confidence, Ease), каждая гипотеза оценивается по трём параметрам, и приоритет считается как произведение или среднее.

PIE: Potential — потенциал улучшения метрики (1–10), Importance — важность страницы для бизнеса (1–10), Ease — лёгкость реализации (1–10). ICE: Impact — ожидаемое влияние, Confidence — уверенность в гипотезе (на основе доказательной базы), Ease — лёгкость реализации. Гипотезы сортируются по убыванию итоговой оценки, первыми тестируются с высоким значением.

Типовой набор приоритетов на старте: гипотезы с обоснованием от аналитики + страница с большим трафиком + простая реализация. Откладываются: гипотезы «потому что у конкурентов так» без подтверждения данными, дорогие в реализации концепции, изменения с очень малым ожидаемым эффектом (меньше 5%) при ограниченном трафике.

Расчёт выборки и статистическая значимость

Расчёт выборки — обязательный шаг до запуска теста. Без него тест может остановиться слишком рано (ложноположительный результат) или слишком поздно (потеря времени и трафика). Расчёт опирается на четыре параметра: baseline-конверсия (текущее значение метрики), MDE (Minimum Detectable Effect, минимальный обнаружимый эффект), статистическая мощность теста (обычно 80%), уровень значимости (обычно p ≤ 0,05).

Baseline-конверсия — измеренное значение метрики на текущем варианте A до начала теста. MDE — минимальный размер эффекта, который тест способен обнаружить с заданной мощностью. Чем меньше MDE, тем больше выборка: тест, обнаруживающий разницу в 2%, требует выборки на порядок больше, чем тест на разницу в 20%. Стандартный диапазон MDE для бизнес-тестов — 5–15%.

Калькуляторы и формулы

Для расчёта применяются онлайн-калькуляторы выборки от профильных платформ. Самые известные — калькулятор Эвана Миллера (evanmiller.org/ab-testing/sample-size.html), калькуляторы AB Tasty, Optimizely, VWO. Каждый калькулятор запрашивает baseline, MDE, мощность, уровень значимости и выдаёт минимальный объём выборки на каждый вариант.

Типовой пример: baseline-конверсия 3%, MDE 10% (то есть нужно обнаружить изменение с 3% до 3,3%), мощность 80%, уровень значимости 0,05 — минимальная выборка 30 000 посетителей на вариант, итого 60 000 на тест. При трафике 10 000 в неделю тест займёт 6 недель.

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

Статистическая значимость и доверительные интервалы

p-value (p-значение, вероятность ошибки первого рода) — стандартный показатель статистической значимости. Если p ≤ 0,05, разница считается значимой: вероятность того, что разница случайна, ниже 5%. В строгих исследованиях применяется p ≤ 0,01 (вероятность случайности 1%), в маркетинге для бизнес-решений обычно достаточно p ≤ 0,05.

Доверительный интервал — диапазон, в котором с заданной вероятностью лежит истинное значение разницы между вариантами. Доверительный интервал [+3%; +12%] для MDE означает, что эффект варианта B с 95-процентной вероятностью находится в этом диапазоне. Если интервал пересекает ноль ([−2%; +8%]), разница статистически не значима, даже если средние различаются.

Распространённая ошибка — peeking, преждевременная проверка значимости. Когда команда смотрит на p-value каждый день и останавливает тест в момент, когда p опускается ниже 0,05, фактическая вероятность ошибки растёт до 25–40%. Решение — фиксировать момент проверки заранее (расчётная выборка набрана), не пересчитывать p-value до этого момента или применять методы последовательного анализа (например, mSPRT — Sequential Probability Ratio Test).

Особенности A/B-тестирования на белорусском рынке

Раскрутка сайтов и связанный аудит конверсии на белорусском рынке упираются в особенности рынка: малый трафик в нишах, доли двух поисковых систем, локальные инструменты аналитики. Эти особенности не отменяют методологию A/B-тестирования, но меняют выбор инструментов и подход к статистике.

Размер белорусского рынка по разным оценкам в 16–17 раз меньше российского. Это означает, что классический A/B-тест с расчётной выборкой в десятки тысяч посетителей на проектах с трафиком 3–10 тысяч визитов в месяц становится непрактичным: тест занимает квартал, а к концу теста меняются внешние факторы. Приоритет смещается к исследовательским методам, A/B-тестам только на больших MDE и комбинированному подходу — сочетанию A/B и исследовательских методов.

Поисковые системы и инструменты аналитики РБ

Доли поисковых систем в Беларуси: Google 65–75%, Яндекс 25–30%. Это означает необходимость измерений через два инструмента одновременно — Google Analytics 4 и Яндекс Метрика. У каждого свой подход к A/B-тестированию: GA4 интегрируется с внешними платформами (VWO, AB Tasty, Optimizely), Яндекс Метрика имеет встроенный инструмент «Эксперименты», который запускается без сторонних решений.

«Эксперименты» в Яндекс Метрике на базе технологии Varioqub — нативный модуль для A/B-тестов с автоматическим разделением трафика, целями, расчётом значимости. Подходит для проектов, основная часть трафика которых приходит из Яндекс. Webvisor (запись сессий) в Метрике даёт содержательные данные, дополняющие количественные результаты теста.

Google Optimize, бывший стандартный инструмент Google для A/B-тестов, закрыт 30 сентября 2023 года. Альтернативы для интеграции с GA4 — VWO, AB Tasty, Convert, Optimizely, GrowthBook, PostHog. Выбор зависит от объёма трафика, бюджета и сложности тестов: VWO и AB Tasty — для средних и крупных проектов, GrowthBook и PostHog — open-source альтернативы для команд с собственной разработкой.

Малый трафик и альтернативы A/B-тесту

При трафике до 500–1000 визитов в неделю на тестируемой странице классический A/B-тест статистически не работает: даже большие MDE требуют выборки, которая набирается за квартал. Решение — комбинированный подход с акцентом на исследовательские методы.

Стандартный набор для малого трафика: user-тестирование на 5–8 представителях целевой аудитории с фиксированными задачами (найти товар, оформить заявку), тепловые карты кликов и прокрутки за 4–6 недель наблюдений, опросы клиентов после сделки (3–5 вопросов о причинах выбора, сомнениях, неудобствах). Эти инструменты дают содержательные сигналы о работе элементов сайта без необходимости накапливать статистическую выборку.

Когда A/B-тест всё же запускается на малом трафике, повышается MDE (15–25% вместо 5–10%), сокращается число одновременных тестов, увеличивается длительность каждого. Параллельно — скользящие средние за 8–12 недель для оценки стабильности эффекта после внедрения.

Локальная атрибуция и доверительные сигналы

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

ЕРИП (единое расчётное и информационное пространство) — стандартный канал оплаты для большинства белорусских покупателей. Тесты, связанные с шагом оплаты, обязательно включают вариант с ЕРИП. Сравнение «без ЕРИП vs с ЕРИП» — типовой высокоприоритетный тест для интернет-магазинов и сервисов с прямой оплатой.

Доверительные сигналы — УНП (учётный номер плательщика) в подвале, реквизиты юридического лица, ссылка на регистрацию в ЕГР (Единый государственный регистр юридических лиц и индивидуальных предпринимателей), карточка офиса в Яндекс Картах и Google Maps — типовые элементы для A/B-тестов в задачах работы над E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness — опыт, экспертность, авторитетность, доверие). Сравнение «страница без блока реквизитов» против «страница с блоком реквизитов и сертификатами» даёт прирост 5–15% на YMYL-тематиках (Your Money or Your Life, тематики, влияющие на финансы или здоровье).

SEO-продвижение и контекстная реклама в Cropas

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

Параллельно с органикой работает контекстная реклама с прозрачной сквозной аналитикой: рекламный трафик становится инструментом ускоренного набора выборки для A/B-тестов на новых посадочных. Связка двух источников трафика с общей аналитикой и единым календарём экспериментов формирует устойчивый процесс роста конверсии без зависимости от интуиции маркетолога или подрядчика.

Типичные ошибки при A/B-тестировании

Подборка ошибок собрана по аудитам белорусских и СНГ-проектов в нишах услуг, B2B и интернет-магазинов. Большинство ошибок — методологические и связаны с попытками сократить процесс или пропустить этапы.

• Тест без расчёта выборки. Команда запускает тест «на глаз» и останавливает в момент, когда вариант B показал лучший результат. Фактическая значимость неизвестна, решение принимается по случайному всплеску. Решение — обязательный расчёт выборки до запуска через калькулятор и фиксация момента остановки.
• Peeking — преждевременная проверка значимости. Аналитик смотрит на p-value каждый день и останавливает тест при первом p ≤ 0,05. Фактическая вероятность ошибки в этом сценарии вырастает до 25–40%. Решение — проверка значимости только в момент достижения расчётной выборки или применение последовательных тестов.
• Тест короче одной недели. Тест останавливают через 3–5 дней при достижении выборки. Результат смещён недельной сезонностью: будни и выходные могут давать разные конверсии. Решение — минимум полный недельный цикл, лучше два.
• Параллельные тесты на одних и тех же страницах. На одной странице одновременно тестируются заголовок, кнопка, форма — без MVT-разметки. Эффекты накладываются, и невозможно понять, что именно дало результат. Решение — либо MVT, либо последовательность отдельных тестов.
• Игнорирование сегментации. Тест запускается без разделения по устройствам, источникам, новым/возвращающимся пользователям. Общий результат может быть нейтральным, при этом мобильный сегмент дал +20%, а десктоп — −15%. Решение — обязательная посттестовая сегментация в анализе.
• Слишком малый MDE при малом трафике. На проекте с трафиком 5000 в неделю запускается тест с MDE 3%. Выборка набирается полгода, тест останавливают раньше, результат неинтерпретируем. Решение — увеличение MDE до 10–20% или переход на исследовательские методы.
• Тест без чёткой метрики цели. Команда смотрит сразу на 5–7 метрик и находит «что-то значимое». Один из показателей всегда покажет значимость случайно. Решение — одна основная метрика, зафиксированная до теста.
• Запуск теста во время рекламной кампании или сезонного пика. Внешние факторы могут влиять на состав трафика и метрики. Решение — запуск в стабильный период или учёт внешних факторов в анализе с сегментацией по источникам.
• Отсутствие журнала экспериментов. Тесты проводятся без фиксации гипотезы, выборки, длительности, результата. Через полгода невозможно вспомнить, что тестировалось и с каким исходом. Решение — журнал в формате таблицы с обязательными полями: дата, гипотеза, варианты, выборка, результат, решение.
• Внедрение варианта B без последующего мониторинга. Тест выиграл, B стал основным, никто не следит за метрикой дальше. Эффект мог быть временным или зависеть от сезонности. Решение — мониторинг метрики 4–8 недель после внедрения с сравнением со средним до теста.
• Калька с западных кейсов без локальной проверки. Команда внедряет вариант, который «дал +30% у компании X», без собственного теста. Контекст сайта, аудитории, ниши другой — результат не повторяется. Решение — каждая правка проходит собственный тест, чужие кейсы — только источник гипотез.
• Тестирование на странице с резко падающим трафиком. На странице, попавшей под алгоритмический фильтр поисковой системы, тестирование бессмысленно: данных не накопить. Решение — стабилизация трафика до теста, либо тестирование на других страницах с устойчивым трафиком.

Часто задаваемые вопросы

С какого теста начинать команде, не имеющей опыта A/B-тестирования?

С простого теста с большим ожидаемым эффектом на странице с устойчивым трафиком: заголовок первого экрана, кнопка призыва к действию, форма заявки. Гипотеза формулируется по шаблону «если — то — потому что», MDE задаётся на уровне 10–15%, длительность — 2–4 недели. Первый тест важен не только для результата, но и для отладки процесса: расчёта выборки, настройки инструмента, фиксации результата в журнале экспериментов. Через 3–4 первых теста процесс выходит на регулярный режим, и дальше можно тестировать гипотезы с меньшим MDE и более сложные сценарии. На зрелом этапе раскрутка сайтов идёт в связке с регулярным календарём тестов: 2–4 эксперимента в месяц, ведение журнала, накопление корпоративной базы знаний.

Какой бюджет нужен на инструмент A/B-тестирования для среднего проекта?

Для проектов с трафиком до 50 000 визитов в месяц подходят бесплатные и условно-бесплатные инструменты: «Эксперименты» Яндекс Метрики (бесплатно, неограниченно), GrowthBook и PostHog в self-hosted версии (бесплатно, требуют разработчика для установки), бесплатные тарифы VWO и Convert на ограниченное число посетителей. Для проектов с трафиком от 50 000 коммерческие платформы — VWO, AB Tasty, Optimizely — дают расширенные возможности (MVT, сегментация, интеграции). Стоимость в коммерческих тарифах привязана к объёму трафика и числу одновременных экспериментов, ориентир — от базовых до расширенных тарифов для среднего проекта. Для большинства бизнес-задач достаточно бесплатных и среднебюджетных решений.

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

Отрицательный результат — это полноценный результат, не провал. Тест без значимости даёт информацию о том, что гипотеза не подтвердилась с заданным MDE, и сужает дальнейшие направления поиска. В отчёте руководству это формулируется так: «гипотеза не подтвердилась, эффект меньше MDE 10% или статистически не отличим от нуля; следующая гипотеза в журнале — X, обоснование Y». Регулярный отчёт по тестам — таблица «гипотеза, исход, что сделано дальше» — снимает у руководства иллюзию, что каждый тест должен давать прирост. По индустриальной практике 30–50% тестов не подтверждают гипотезу или показывают нейтральный результат, и это нормальная пропорция.

Можно ли использовать A/B-тестирование для SEO-изменений?

С серьёзными оговорками. Google рекомендует не показывать разные версии страницы по одному URL длительное время — это может классифицироваться как клоакинг (выдача разного контента поисковым роботам и пользователям). Для тестирования SEO-эффектов применяются методики, в которых разные варианты разделены по разным URL (split URL с canonical-разметкой), либо когортный анализ — изменения вносятся на части страниц сайта, не на всех, и эффект сравнивается между когортами. Полноценный A/B-тест на ранжирование требует значительного объёма страниц (от 100 однотипных), специальной методологии и принимается как направление аудита позиций, не как обычный A/B. Для оценки конверсии в рамках уже стабильного органического трафика обычные A/B-инструменты подходят без оговорок.

Что делать, если результаты в Google Analytics и Яндекс Метрике расходятся?

Расхождение — нормальное явление, связанное с разной моделью атрибуции, разными правилами фильтрации трафика, разными определениями сессии. Типичное расхождение в показателях конверсии — 15–25%. При проведении теста выбирается одна основная система измерений (та, что используется для отчётов по проекту), и решение принимается по её данным. Вторая система — для перекрёстной проверки направления изменения: если в обеих системах вариант B показывает рост, доверие к результату выше; если в одной растёт, а в другой падает — требуется отдельная диагностика причин расхождения. На проектах с большим вкладом обеих поисковых систем рекомендуется работать с обоими инструментами параллельно и принимать решение только при совпадении направления.

Как часто можно перетестировать одно и то же изменение?

Перетест разумен через 6–12 месяцев или после значимых изменений: новая аудитория, новые рекламные источники, обновление продукта, изменение сезонности. Результат, полученный год назад, не гарантированно сохраняется: аудитория обновляется, ожидания смещаются, поведенческие нормы меняются. На зрелом проекте раз в год проводится ревизия ключевых ранее победивших изменений — повторный тест против актуального состояния. Это не откат изменения — это подтверждение, что эффект сохраняется. Если перетест показывает, что бывший вариант B больше не превосходит A, это сигнал к новой итерации гипотез на этом элементе.

Что важнее — статистическая значимость или практическая значимость?

Оба показателя нужно оценивать вместе. Статистическая значимость (p-value) говорит, реален ли эффект; практическая значимость говорит, стоит ли его внедрения. Тест может дать статистически значимое улучшение на 0,3% при p = 0,02 — реально, но не оправдывает затрат на внедрение, поддержку, переобучение команды. Стандартная практика — задавать минимальную практическую значимость до теста (например, «внедряем только при росте больше 5% при p ≤ 0,05»). Это снимает соблазн внедрять косметические победы и держит фокус на изменениях с реальным влиянием на бизнес.

Как быть с тестами, которые показали разный результат на мобиле и десктопе?

Разделение результата по устройствам — стандартный шаг анализа. Если общий тест нейтральный, но на мобиле сильный рост, а на десктопе — спад, разумно внедрить вариант B только для мобильной версии. Это технически реализуется через условное отображение (responsive-логика) или через отдельные шаблоны. Дальше — мониторинг обоих сегментов 4–8 недель для подтверждения устойчивости эффекта. Иногда расхождение по устройствам подсказывает гипотезу следующего теста: «что именно в варианте B работает на мобиле, но не работает на десктопе» — отдельная задача для исследовательской работы через user-тестирование на двух устройствах.