Смещение цели: почему «конверсия» в A/B тестах B2B чаще всего врет

Смещение цели: почему «конверсия» в A/B тестах B2B чаще всего врет

В B2B я всё чаще вижу одну и ту же картину: эксперимент ставят на “лид” или “заявку”, а потом искренне удивляются, что продажи не растут. На моей практике это повторяется в проектах с длинными циклами (MQL/SQL → сделка) и особенно там, где маркетинг и продажи уже живут в модели RevOps (общая ответственность за выручку). Проблема не в инструменте. Проблема в том, что “конверсия” в интерфейсе — это суррогат (замещающая метрика), который легко оптимизируется, но плохо предсказывает выручку.

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

Как это проявляется в цифрах. В одном из недавних кейсов мы наблюдали рост формы-события примерно на 18% в варианте A/B, но доля MQL (маркетинговых квалифицированных лидов) относительно трафика не улучшилась, а SQL (продажи-квалифицированные лиды) даже слегка просел. В итоге win по “лидам” превратился в loss по выручке — и это было видно уже на уровне качества, но не в самой цели эксперимента.

Что я считаю правильным подходом (и это ближе к логике Optimizely и VWO, чем к “выбрать любую конверсию”):
— ставить основную цель ближе к экономическому исходу: не “заявка”, а “квалифицированное действие” (например, демо с определённым намерением/профилем, заполнение поля, влияющего на маршрутизацию в продажах, или достижение этапа, который коррелирует с SQL)
— использовать промежуточные метрики как guardrail (ограничитель), а не как цель: например, CTR и заполнение формы можно оставить, чтобы не сломать UX, но победителем должен быть сигнал, который маркетинг не стыдится перед RevOps
— закладывать задержку: в B2B атрибуция “сегодня кликнул — завтра купил” часто не работает. Я предпочитаю A/B с проверкой во “временных окнах” по факту передачи в CRM, даже если инструмент показывает эффект быстро

Уточнение про Google Optimize: сейчас многие команды смотрят на “архитектуру экспериментов” через призму того, что быстрее, чем когда-либо, важна интеграция с данными и серверная логика. Если вы не можете честно сопоставить событие эксперимента с CRM-качеством, то вы тестируете не рост, а поведение интерфейса.

Моё мнение простое: если цель теста не проходит проверку “а улучшится ли она для SQL/выручки через нормальное время”, то это не эксперимент — это оптимизация по картинке. Выбирайте цель так, чтобы её было неудобно “дешево обыгрывать” и легко защищать на уровне бизнеса.

Параллельный взгляд на тему — @TikTokAdsManual