Опасная ошибка в A/B: вы “тестируете” интерфейс, но оптимизируете метрику, которая меняется от приватности

Опасная ошибка в A/B: вы “тестируете” интерфейс, но оптимизируете метрику, которая меняется от приватности

Я всё чаще вижу, как команды проводят A/B-тесты по всем правилам — рандомизация есть, сегменты соблюдены, длительность — ок. А потом удивляются, что “победитель” ведёт себя хуже в реальных продажах или выручке. Моя версия причины обычно одна: в тесте оптимизируют метрику, которая в эпоху privacy-first атрибуции (серверная передача событий, MMM, incrementality) живёт своей жизнью.

Как это выглядит на практике. Допустим, вы делаете тест баннера на главной и оптимизируете “конверсию в заявку”. В отчёте — lift есть. Но если вы после релиза смотрите сквозную воронку (MQL→SQL→закрытая сделка) через RevOps-дашборды, картина ломается: доля заявок растёт, а качество падает. Не потому что баннер плохой, а потому что “заявка” становится шумнее из‑за того, что трекинг и приписывание (атрибуция) перестают быть стабильными во времени и между каналами.

Один наблюдаемый эффект из наших внедрений: после перехода части событий на server-side сборку и изменения таймингов срабатываний (даже без смены логики маркетинга) доля “последний клик” в отчётах может заметно просесть, а распределение источников внутри одной и той же вариации — поменяться. В результате тест измеряет не поведение пользователя “здесь и сейчас”, а то, насколько корректно ваша аналитика связала событие с сессией.

Что я делаю, когда хочу вылечить тесты, а не “перетестировать до победы”:

— Оптимизирую не самый верхний прокси, а метрику с меньшим вкладом атрибуции. Для B2B это часто шаги, которые ближе к намерению: например, заполнение ключевых полей с валидацией, просмотр страницы с продуктовой ценностью, действия в калькуляторе/конфигураторе. Не идеал, но устойчивее, чем “лид как таковой”.
— Включаю анализ качества вариаций по downstream-сигналам, даже если это занимает неделю. VWO/Optimizely обычно умеют быстро проверить CTR и конверсии, но “истина” в B2B — в SQL и закрытии сделки.
— Обязательно проверяю инкрементальность через дизайн эксперимента: если у меня есть основания думать, что изменения в трафике/каналах влияют на долю событий, я добавляю подход, близкий к incrementality — сравнение с контролируемыми когортами, а не слепое доверие к uplift по последнему клику.
— Сверяю воронку в Google-экосистеме только после того, как убедился, что в тесте одинаково работает событие и одинаково обрабатываются consent-режимы. Google Optimize уже не в фокусе многих команд, но принцип контроля событий в тесте актуален всегда.

Моё правило: если эксперимент “побеждает” только по метрике, которая зависит от атрибуции, это не оптимизация — это подгонка под измерение. Хотите тесты, которые выдерживают 2026 реальность? Тогда сначала стабилизируйте измерение и только потом спорьте с результатами.