Как настроить pop-up для сбора лидов: сценарии показа и проверка влияния на конверсию

Pop-up для сбора лидов показывают, если посетитель проявил интерес, и ограничивают частоту показов и отключают для посетителей, которые уже оставили заявку. Результат оценивают по тому, сколько обращений добавилось по сравнению с контрольной группой, которой окно не показывали. До такого эксперимента нельзя гарантировать, что pop-up сохранит или повысит общую конверсию сайта.

Здесь pop-up, или всплывающее окно, — это элемент интерфейса поверх страницы либо рядом с ее содержимым. Лид-форма внутри окна собирает данные для следующего контакта. Лидом считается обращение, а квалифицированным лидом — обращение, которое соответствует согласованным критериям отдела продаж. Добавочный эффект — это число заявок, которые сайт получил благодаря сценарию и не получил бы без него.

Когда pop-up приносит добавочные лиды, а не перехватывает существующие заявки

Собственная конверсия pop-up отвечает на узкий вопрос: какая доля увидевших окно отправила размещенную в нем форму. При этом метрика не показывает, оставили бы эти люди заявку через встроенную форму, чат или контакты на странице.

Например, окно на странице цен может собирать обращения пользователей с уже сформированным намерением. Если pop-up перехватил заявки у основной формы, его отчет покажет рост, хотя общая лидогенерация сайта останется прежней. Поэтому в числителе учитывают уникальных посетителей с заявкой или квалифицированным лидом, а в знаменателе — всех пользователей, включенных в эксперимент.

Как считать конверсию лид-формы

Сначала рассчитывают CR_form — долю пользователей, которые успешно отправили форму после фактического показа окна:

CR_form = U_submit_success / U_impression × 100%

Где:

• CR_form — конверсия лид-формы внутри pop-up;

• U_submit_success — число уникальных пользователей с событием успешной отправки;

• U_impression — число уникальных пользователей, которым действительно показали окно;

• 100% — множитель, который переводит долю в проценты.

При этом высокий CR_form помогает сравнивать версии формы. Для решения о запуске дополнительно нужны общая конверсия сайта и данные о качестве обращений.

Как определить добавочный эффект

Чтобы оценить весь сценарий, команда рассчитывает CR_site — общую конверсию пользователей, назначенных в вариант. В расчет входят и те, у кого триггер показа не сработал:

CR_site = U_any_lead / U_assigned × 100%

Где:

• CR_site — общая конверсия сайта в заявку для варианта эксперимента;

• U_any_lead — число уникальных пользователей с принятой заявкой через любой канал сайта;

• U_assigned — число уникальных пользователей, закрепленных за вариантом;

• 100% — множитель, который переводит долю в проценты.

Затем тестовый вариант сравнивают с контрольной группой по формулам ΔCR и Lift:

ΔCR = CR_test − CR_control; Lift = (CR_test − CR_control) / CR_control × 100%

Где:

• ΔCR — абсолютное изменение общей конверсии в процентных пунктах;

• Lift — относительное изменение общей конверсии;

• CR_test — общая конверсия группы с pop-up;

• CR_control — общая конверсия контрольной группы без pop-up;

• 100% — множитель, который выражает относительное изменение в процентах.

Кому и на каких страницах показывать pop-up

Сегмент для показа формируют по доступным признакам: источнику трафика, странице входа, текущему URL, поведению в этом и прошлых визитах, этапу жизненного цикла известного пользователя. Источник помогает понять ожидания посетителя, страница — его текущую задачу, поведение — степень интереса.

Так, посетителю из поиска сначала нужен материал, обещанный выдачей. Пользователь на продуктовой странице оценивает, подходит ли ему решение, а на странице цен — сопоставляет тарифы и условия покупки. Во втором случае намерение оставить заявку или перейти к покупке обычно выражено сильнее. Единый призыв оставить телефон стирает различия между этими задачами.

Матрица B2B-сценариев

Чтобы настроить сценарий, в матрице связывают аудиторию, контекст, оффер и ограничения. Для конкретного сценария сначала формулируют гипотезу о значениях frequency cap — ограничениях частоты для одного пользователя. Универсального отраслевого норматива для них нет.

Когда посетителя исключают из показа

Посетителя исключают из показа, если pop-up мешает основной задаче или не предлагает уместного продолжения:

• До доступа к основному содержимому страницы;

• Сразу после перехода из поиска, пока посетитель не получил обещанный контент;

• После успешной отправки формы, относящейся к той же задаче;

• Во время заполнения встроенной формы, общения в чате или работы с другим диалоговым элементом;

• Для клиента или лида на этапе, которому оффер уже не соответствует;

• При отсутствии предложения, которое продолжает задачу конкретного сегмента.

Такой подход согласуется с разбором pop-up Nielsen Norman Group: ранние модальные запросы на подписку относятся к проблемным UX-паттернам (типовым решениям пользовательского интерфейса), для которых стоит искать менее блокирующие варианты. Четкие правила показа позволяют оценивать сценарий по наблюдаемым действиям пользователя.

Как выбрать триггер: время, прокрутка, несколько страниц, бездействие или exit intent

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

Алгоритм выбора триггера по силе намерения

Первоначальный триггер выбирают по его связи с задачей страницы:

1. Выбирают действие, по которому видно, что пользователь изучил содержимое: просмотрел блок, открыл тариф, перешел к кейсу или вернулся на коммерческий URL;

2. Выбирают самый поздний наблюдаемый сигнал, после которого у пользователя остается время на полезное следующее действие;

3. Сочетают условия, если один сигнал может означать разные действия пользователя, например учитывают текущий URL вместе с просмотром связанного кейса;

4. Задают отдельную логику для мобильных и десктопных устройств;

5. Сравнивают результаты показа окна с результатами контрольной группы, которой окно не показывают.

В этой схеме задержка по времени работает как технический фильтр от мгновенного показа, но не заменяет контекстный сигнал. Глубина прокрутки сильнее связана с содержанием длинной страницы. Несколько релевантных URL указывают на изучение решения, если аналитика учитывает состав страниц. Exit intent подходит для десктопного теста, когда интерфейс надежно распознает движение к выходу.

Как ограничить повторные показы и исключить уже сконвертировавшихся посетителей

Frequency cap ограничивает число показов одному пользователю за визит или период. После закрытия окна, взаимодействия с ним либо конверсии новый показ блокируют на период подавления. Ограничение частоты и период подавления нужно сохранять между визитами, иначе система будет считать каждый заход первым.

Как выбрать стартовое ограничение частоты

Для B2B-сайтов нет универсальной частоты. Стартовая конфигурация зависит от четырех свойств сценария:

• Цикл повторных визитов. Период подавления должен отделять повторные визиты во время выбора от нового цикла интереса;

• Ценность оффера. Узкое предложение для одного контекста требует строгого ограничения за его пределами;

• Уровень намерения. Более сильный новый сигнал может снова разрешить показ после прошлого закрытия, если задача пользователя изменилась;

• История реакции. Закрытие без взаимодействия, начатое заполнение, ошибка и успешная отправка требуют разных правил.

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

Техническая схема подавления после конверсии

После подтвержденной отправки система останавливает показы. Если инфраструктура может связать идентификаторы, система загружает статус известного пользователя при другом визите или на другом устройстве:

1. Форма получает подтверждение сервера и отправляет событие submit_success с идентификаторами сценария, варианта и пользователя;

2. Сайт записывает first-party-признак — собственный статус в cookie, local storage (хранилище данных внутри браузера) или серверном профиле, например lead_submitted=true;

3. Инструмент показа проверяет признак до события eligibility и исключает пользователя;

4. CRM — система управления отношениями с клиентами — или CDP — платформа объединения клиентских профилей — возвращает актуальный этап известного лида;

5. Система снимает или продлевает подавление по заранее установленному правилу, которое учитывает этап жизненного цикла.

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

Как связать оффер и поля формы с задачей посетителя

Оффер должен продолжать действие, которое посетитель совершает на странице. Читателю статьи подойдет материал или консультация по раскрытой проблеме, посетителю продукта — демонстрация выбранной функции, пользователю страницы цен — расчет или обсуждение условий. Общий призыв «оставьте контакты» не объясняет результат отправки.

Поэтому из формулировки оффера посетитель должен понять, какой результат получит, какие данные потребуется передать, кто и каким способом с ним свяжется. В этом случае предложение персонализируют по известным признакам пользователя. Обращение по имени само по себе задачу не решает.

Какие поля оставлять в лид-форме

Каждое поле выбирают с учетом конкретного следующего действия:

• Имя помогает персонализировать контакт, если команда действительно его использует;

• Телефон нужен для согласованного звонка;

• Рабочая почта нужна для отправки материала или продолжения переписки;

• Компания, роль, размер проекта или задача нужны, если эти сведения влияют на маршрутизацию обращения либо квалификацию;

• Свободный комментарий полезен, когда посетителю требуется описать запрос, который нельзя выразить выбором.

Короткую форму пользователю проще заполнить. Число полей нельзя выбирать по универсальному шаблону. Дополнительные сведения оправданы, когда они влияют на маршрут обращения, подготовку ответа или критерии квалифицированного лида. Если отдел продаж все равно уточняет данные при первом контакте, команда решает, стоит ли ради ранней квалификации усложнять форму.

Чем мобильный pop-up должен отличаться от десктопного

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

В частности, рекомендации Google Search по interstitial советуют избегать окон, которые перекрывают основной контент, и использовать компактные элементы, сохраняющие доступ к странице. Google считает, что pop-up поверх содержимого и отдельный interstitial (полноэкранный блок поверх контента), который приходится закрывать перед просмотром страницы, затрудняют доступ.

Как выбрать формат окна

Кроме формата различается и логика показа. На десктопе exit intent (признак намерения покинуть страницу) можно определять по движению курсора к области выхода. На сенсорном экране такого движения нет. Нажатие кнопки «Назад», прокрутка и бездействие служат другими сигналами, поэтому мобильный сценарий проектируют и анализируют отдельно.

Какие события передавать в аналитику и CRM

Словарь событий должен позволять восстановить путь пользователя от допуска к сценарию до итогового статуса лида. Каждое событие передает общий experiment_id, variant_id, scenario_id, устойчивый идентификатор пользователя и время. По идентификатору формы можно отличить pop-up от встроенных форм.

При интерпретации событие close не считают отказом от оффера. Пользователь может продолжить чтение, воспользоваться встроенной формой или вернуться позже. Аналитика хранит закрытие как отдельное действие и учитывает последующие заявки через все каналы сайта.

Как связать pop-up с квалифицированным лидом

После успешной отправки сайт передает в CRM идентификаторы пользователя, формы, сценария, эксперимента и варианта. CRM сохраняет их в карточке обращения или связанной таблице атрибуции. При смене статуса CRM либо CDP возвращает событие квалификации в аналитическое хранилище.

Чтобы данные можно было сопоставлять, система использует единое правило дедупликации (удаления повторно учтенных обращений). Если один пользователь или одна компания повторно отправляет форму, это не должно автоматически создавать несколько дополнительных лидов. До теста команда решает, что считать одним результатом: человека, компанию, обращение или потенциальную сделку (коммерческую возможность). Это определение должно быть одинаковым для тестовой и контрольной групп.

Как проверить влияние pop-up на общую конверсию сайта

Корректный A/B-тест сравнивает группу с pop-up с контрольной группой без окна; обе относятся к одной допустимой аудитории. Если рандомизацию (случайное распределение по группам) проводят до показа, в анализе остаются и пользователи тестового варианта, у которых триггер не сработал. Так эксперимент позволяет оценить влияние всего правила показа, включая охват аудитории сценарием.

План A/B-теста с контрольной группой

До запуска протокол фиксирует параметры эксперимента:

1. Аудитория. Команда описывает страницы, источники, устройства, статусы пользователя и исключения;

2. Единица рандомизации (объект случайного распределения по группам). Обычно ею служит устойчивый идентификатор пользователя. Если в B2B несколько сотрудников могут влиять друг на друга, единицей может стать компания;

3. Варианты. В контрольной группе pop-up не показывают, а в тестовой показывают одну зафиксированную версию сценария;

4. Целевая метрика. Команда определяет, что считать целевым результатом: дополнительную заявку, квалифицированный лид или коммерческую возможность;

5. Защитные метрики. Протокол учитывает общую конверсию, дальнейшее взаимодействие с содержимым и основным CTA, ошибки формы, доступность контента и другие критичные показатели;

6. Базовая конверсия. Команда оценивает, какая доля сопоставимой аудитории изначально достигает результата;

7. MDE. Минимально обнаруживаемый эффект — это наименьшее изменение, ради которого сценарий имеет смысл запускать;

8. Статистические параметры. Уровень ошибки первого рода ограничивает риск ложного положительного решения, статистическая мощность задает вероятность обнаружить запланированный эффект;

9. Выборка и длительность. Расчет учитывает базовую конверсию, MDE, распределение групп, параметры ошибки, полный цикл повторных визитов и созревания лида;

10. Правило решения. Команда заранее определяет требования к целевой метрике, качеству лидов и допустимому изменению каждой защитной метрики.

При этом слишком маленькая выборка может пропустить существующий эффект даже при корректном анализе. Расчет зависит от того, считают ли эффект абсолютным или относительным, и от возможной корреляции наблюдений (взаимозависимости результатов измерений). Эти условия подробно разбирает работа о расчете выборки онлайн-экспериментов.

Поэтому выборку рассчитывают выбранным заранее методом или проверяемым калькулятором. Для расчета указывают базовую конверсию, абсолютный либо относительный MDE, уровень ошибки первого рода, мощность и доли распределения трафика. Если целевых метрик несколько, нужно контролировать вероятность ложноположительных результатов. Для защитных метрик может потребоваться большая выборка, потому что их вариативность отличается.

Дополнительно Microsoft Research предлагает оценивать экспериментальные метрики по чувствительности, достоверности, эффективности, диагностируемости, интерпретируемости и инклюзивности. Для pop-up такая проверка отсеивает показатели, которые быстро меняются, но слабо отражают коммерческий результат.

Как закрепить пользователя за вариантом

После рандомизации система назначает вариант один раз и хранит решение в first-party cookie, серверном профиле или платформе экспериментов. Идентификатор авторизованного пользователя или согласованный идентификатор в платформе клиентских данных (CDP) позволяет закрепить за пользователем тот же вариант при следующих визитах. Если прежний идентификатор недоступен, система применяет одно заранее установленное правило и не распределяет активного участника случайным образом заново.

По этой причине событие assignment должно возникать до impression. Иначе один пользователь может сначала попасть в контрольную группу, затем получить окно при другом визите, и результаты групп смешаются. Анализ ведут по первоначальному назначению, даже если участник тестовой группы не дождался триггера.

Целевые и защитные метрики

Целевая метрика измеряет результат, ради которого запускают сценарий. Защитная метрика показывает, какой ущерб для пользовательского опыта, основной воронки или качества данных допустим.

“Ship if the treatment is significantly superior on at least one success metric and significantly non-inferior on all guardrail metrics.”

Mårten Schultzberg, Sebastian Ankargren, Mattias Frånberg, авторы материала Confidence by Spotify

В этой методологии вариант выпускают, если он статистически лучше хотя бы по одной success-метрике и статистически не хуже по всем guardrail-метрикам. Для pop-up целевой метрикой может быть прирост квалифицированных лидов. Защитными метриками могут служить общая конверсия сайта, завершение основной формы, доступ к контенту и ошибки отправки.

Мобильный и десктопный трафик анализируют отдельно, если это заранее предусмотрено дизайном. Сегментный анализ не должен превращаться в поиск случайно выигравшей подгруппы после теста. Если решение зависит от устройства, команда заранее фиксирует гипотезы, выборку и правило множественных сравнений (одновременной проверки нескольких гипотез).

Когда сценарий запускать, дорабатывать или отключать

Решение принимают, одновременно учитывая добавочные заявки, их квалификацию и защитные метрики. Собственная конверсия окна остается диагностическим показателем и не заменяет итоговый критерий.

Если общая конверсия падает, проблема может быть связана с маршрутом пользователя, основной формой или обработкой обращения. Найти такие потери помогает разбор о том, как путь до формы влияет на конверсию в заявку.

Пример настройки pop-up для B2B-страницы

Допустим, нужно проверить pop-up с предложением расчета для посетителей страницы цен B2B-продукта. Эксперимент проводят, не предполагая заранее, каким будет результат: задают аудиторию, логику показа, события и критерий решения.

Сегмент, триггер и оффер

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

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

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

Подавление и аналитика

После закрытия окна система записывает, как долго будет действовать подавление. Более сильный сигнал может вернуть пользователя в допустимую аудиторию только по правилу, зафиксированному до теста. Событие submit_success сразу устанавливает признак конверсии, а позднее CRM обновляет статус квалификации.

Дальше по цепочке событий восстанавливают путь пользователя:

1. eligibility подтверждает соответствие сегменту;

2. assignment закрепляет контрольный или тестовый вариант;

3. impression фиксирует фактический показ в тестовой группе;

4. interaction, close, submit_attempt, submit_error и submit_success описывают работу с формой;

5. downstream_lead и lead_qualified возвращают коммерческий результат.

Эксперимент и критерий решения

Контрольная группа проходит тот же маршрут без pop-up и сохраняет доступ к встроенной форме. Основным результатом считают долю пользователей с квалифицированным лидом среди всех, кого назначили в контрольную или тестовую группу. К защитным показателям относятся общая конверсия в заявку, использование основного призыва к действию (CTA), продолжение работы со страницей и количество ошибок при заполнении формы.

Перед запуском команда определяет базовую конверсию, MDE (minimum detectable effect) — минимальный коммерчески значимый эффект, который должен выявить тест, — параметры статистической ошибки, необходимый размер выборки и допустимый предел снижения метрики. Команда также рассчитывает длительность теста с учетом времени, за которое в CRM формируется итоговый статус лида. Сценарий запускают, если тест подтверждает добавочные квалифицированные лиды и все защитные ограничения соблюдены.

Заключение

Результат pop-up можно оценивать по приросту квалифицированных лидов при допустимых значениях защитных метрик, если тест сравнивает сопоставимые группы и сохраняет назначение пользователя между визитами. Конверсия лид-формы показывает реакцию на окно, но не доказывает, что общая лидогенерация выросла. Контекстный оффер, технические исключения и связь аналитики с CRM позволяют оценить результат сценария по итоговому коммерческому статусу.