«Я думала, что “настроить A/B‑тест форм” — это просто сделать две версии и включить статистику, а потом получила заявки, которые невозможно было сопоставить с вариантом теста, и CRM, где всё смешалось: рассказываю, как сделала корректный A/B‑тест без потери лидов и искажений аналитики»

У меня был лендинг фитнес‑курса: WordPress, одна большая форма заявки на первом экране, поп‑ап с бонусом, интеграция с CRM (где хранится статус заявки и источник), виджет обратного звонка, аналитика (Яндекс Метрика + Google Analytics). Клиент сказал: «Протестируй два варианта формы: в одном попроси только имя и телефон, в другом — ещё и цель тренировок. Нужно понять, какая конвертит лучше, но чтобы заявки не терялись, а CRM не ломалась». Я кивнула, а внутри всё сжалось: «А если обе формы будут отправлять данные в одну воронку и я не пойму, какая именно версия принесла лид? Если CRM не сможет различать варианты, а менеджеры будут видеть заявки без привязки к тесту? Если поп‑апы начнут перекрывать друг друга и пользователь не сможет отправить ни одну форму? Если аналитика соберёт всё в кучу, и мы не увидим реальную конверсию по вариантам? Если я случайно запущу два теста одновременно и получу кашу из данных?»

До этого я либо вообще не делала A/B‑тесты (думала: «Это задача маркетолога»), либо делала «на коленке»: создавала копию формы, включала её на той же странице, не помечала источник, а потом вручную пыталась сопоставить заявки с вариантами по времени. В одном проекте так и случилось: обе формы отправляли заявки в одну CRM‑воронку, и мы неделями разбирали, какой вариант реально конвертил. Тогда я поняла: A/B‑тест — это не «две формы», а сквозная идентификация варианта на уровне формы → отправки → CRM → аналитики, плюс контроль, чтобы формы не конфликтовали. Панель Timeweb с бэкапами, поддоменами, логами и phpMyAdmin дала мне безопасную среду, чтобы всё протестировать и не потерять лиды.

Чего я боялась больше всего

Перед запуском теста я честно выписала свои главные страхи:

Смешать заявки из разных вариантов. Что обе формы будут слать данные в одну и ту же воронку CRM, и я не смогу понять, какой вариант конвертит.
Сломать UX и получить конфликты. Что поп‑апы и формы начнут перекрывать друг друга, пользователь не сможет ничего отправить, и конверсия упадёт.
Исказить аналитику. Что в Яндекс Метрике и GA данные соберутся в общую кучу, и я не увижу реальную конверсию по каждому варианту.
Потерять часть заявок. Что из‑за конфликта скриптов или дублей отправки часть лидов просто не уйдёт в CRM.
Не заметить ошибку вовремя. Что тест будет идти неделю, а я пойму, что данные собираются неправильно, только когда клиент попросит отчёт.

С этим списком я пошла в панель Timeweb и составила план: бэкап → тест на поддомене → разметка вариантов → проверка отправки и CRM → контроль аналитики → перенос на основной сайт.

Шаг 1: сделать бэкап и подготовить тестовую площадку

В панели Timeweb я:

Нажала «Создать резервную копию» для файлов и базы. Статус «Готов» — теперь я могла откатиться за 10–15 минут.
Создала поддомен test-fit.site.ru и развернула туда копию сайта.
В wp-config.php прописала новый домен и проверила, что сайт открывается.
Отключила внешние интеграции (CRM, вебхуки, отправку писем), чтобы не создавать дубли заявок на тесте.
Зафиксировала текущие метрики: конверсию формы, количество заявок в сутки, скорость загрузки страницы.

Это была моя «песочница»: любые эксперименты с A/B‑тестами я делала сначала здесь, а не на основном сайте.

Шаг 2: выбрать способ разделения трафика и пометить варианты

Я рассмотрела три варианта и выбрала тот, который лучше подходил под задачу и удобство контроля:

Плагин A/B‑тестов с автоматическим разделением. Удобно, но не всегда даёт гибкую передачу меток в CRM.
Ручная разметка через JS/cookie. Гибко, но легко ошибиться и потерять данные.
Разделение через URL‑параметр + редирект. Самый прозрачный вариант: пользователь попадает на /landing?variant=A или /landing?variant=B, и вся логика строится вокруг этого параметра.

Для этого проекта я выбрала URL‑параметр: он сразу виден в логах, в аналитике и в данных формы, а значит, я точно не потеряю привязку к варианту.

Шаг 3: подготовить два варианта формы и добавить сквозную метку

Я действовала по такой схеме:

Создала два варианта формы:
- Вариант A: только имя и телефон.
- Вариант B: имя, телефон и цель тренировок (выпадающий список).
Добавила в каждую форму скрытое поле variant, которое автоматически подставляло значение из URL‑параметра:
Проверила, что скрытое поле отправляется вместе с заявкой. Это была моя гарантия: даже если CRM не умеет различать варианты, я всегда смогу отфильтровать заявки по полю variant.
Разнесла логику поп‑апов и форм, чтобы они не перекрывали друг друга: если на странице есть форма A, поп‑ап не показывается; если форма B — поп‑ап показывается только через 15 секунд.

Важно: я не делала две формы одновременно на одной странице без контроля видимости — это гарантированный конфликт и падение конверсии.

Шаг 4: настроить CRM и аналитику под варианты теста

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

В CRM: создала отдельные воронки/теги для каждого варианта (variant_A, variant_B) и настроила автоматическое присвоение тега на основе поля variant. Если CRM не умеет этого, я добавила промежуточный шаг: вебхук, который передаёт variant и уже на стороне CRM создаёт нужный тег.
В Яндекс Метрике: настроила цели и сегменты по URL‑параметру, чтобы видеть конверсию отдельно для /landing?variant=A и /landing?variant=B.
В Google Analytics: добавила параметр variant как кастомное измерение (custom dimension) и настроила отчёты по нему.
В логах и error.log: убедилась, что нет ошибок отправки форм и конфликтов JS, которые могут приводить к потере заявок.

Шаг 5: проверить, что заявки корректно попадают в CRM и не дублируются

На тестовой версии я прошла по чек‑листу:

Отправка из варианта A. Заполнила форму, убедилась, что заявка уходит, в ней есть поле variant=A, и в CRM она попадает с нужным тегом.
Отправка из варианта B. То же самое, но с variant=B и дополнительным полем «цель тренировок».
Поп‑апы и перекрытие. Проверила, что формы не конфликтуют, а поп‑ап появляется только в нужном сценарии.
Консоль браузера (F12 → Console). Не должно быть ошибок JS, связанных с формами, скрытыми полями или отправкой.
Логи сервера (error.log в панели Timeweb). Если есть ошибки подключения к базе, таймауты или проблемы с вебхуками — сразу видно.
Проверка дублей. Отправила несколько тестовых заявок и убедилась, что в CRM нет дубликатов и все заявки имеют чёткую привязку к варианту теста.

Только когда все сценарии работали стабильно, я переносила настройки на основной сайт.

Шаг 6: запустить тест на основном сайте и контролировать метрики

На основном сайте я:

Развернула те же формы и логику, что и на тесте.
Настроила редиректы/ссылки, чтобы трафик делился между /landing?variant=A и /landing?variant=B примерно 50/50.
Сразу посмотрела графики нагрузки в панели Timeweb: CPU должен быть стабильным, а всплесков ошибок — не быть.
Проверила Core Web Vitals: добавление JS и логики не должно сильно замедлять страницу.
Настроила ежедневный контроль: если резко вырастет количество ошибок 500 или всплеск 404 — сразу отключить тест и откатиться.

Результат: тест шёл 7 дней, конверсия по варианту B оказалась выше на 18 %, заявки чётко разделялись по вариантам, CRM не путалась, а аналитика показывала реальную картину.

Где я чуть не ошиблась (и что панель подсказала)

Хотела сделать две формы на одной странице одновременно. Думала: «Так проще». Поддержка подсказала: «Формы будут конфликтовать, а конверсия упадёт. Лучше разделение по URL и контроль видимости».
Не добавляла скрытое поле с меткой. Думала: «В аналитике всё видно». Но без метки в самой заявке CRM не могла различать варианты. Панель и практика подсказали: метка должна быть в данных заявки.
Не проверяла дубли заявок. Думала: «Форма отправляется один раз». Но из‑за JS‑ошибок или двойного клика заявки могли дублироваться. Пришлось добавить защиту от повторной отправки и проверку в логах.
Игнорировала логи. Думала: «Если заявки уходят, значит, всё ок». Но в error.log были таймауты вебхуков, которые могли приводить к потере лидов. Панель помогла быстро увидеть проблему.
Не тестировала поп‑апы отдельно. Думала: «Если форма работает, значит, и поп‑ап ок». Но они перекрывали форму и мешали отправке. Панель с тестовым поддоменом помогла быстро увидеть конфликт.

Что реально помогло на Timeweb

Бэкапы в один клик. Я могла откатиться за минуты, если тест ломал формы или CRM.
Поддомены для тестов. Развернула копию сайта и проверяла A/B‑тест без риска для конверсий.
Файловый менеджер и phpMyAdmin. Удобно править конфиги, проверять таблицы и быстро исправлять ошибки.
Графики нагрузки (CPU, запросы). Сразу видно, даёт ли тест лишнюю нагрузку или создаёт всплески ошибок.
Логи (error.log, access.log). В них видно, какие запросы идут, есть ли ошибки интеграции и не теряются ли заявки.
Поддержка. Когда сомневалась, как правильно передать метку в CRM или где искать проблему с дублями, в чате быстро подсказывали безопасный вариант.

Практические советы, чтобы сделать A/B‑тест форм без потери лидов

Если вы тоже планируете A/B‑тест:

Всегда делайте бэкап перед любыми действиями. На Timeweb это пара кликов, а откатиться можно за минуты.
Сначала тестируйте на копии сайта. Любые A/B‑настройки — только на тестовой версии.
Выбирайте прозрачный способ разделения трафика. URL‑параметр или плагин с чёткой передачей меток — это спасает от каши в данных.
Добавляйте сквозную метку в саму заявку. Даже если аналитика соберётся неправильно, у вас будет поле в заявке, по которому можно всё разделить.
Разделяйте воронки/теги в CRM по вариантам теста. Так менеджеры сразу видят, из какого варианта пришёл лид.
Контролируйте конфликты форм и поп‑апов. Не делайте две формы одновременно без логики видимости.
Проверяйте не только отправку, но и получение заявок в CRM. Иногда форма работает, а вебхук ломается.
Следите за дублями и защитой от повторной отправки. Один пользователь не должен отправлять одну и ту же заявку дважды.
Контролируйте логи и метрики. Если появляются ошибки или растёт нагрузка — сразу разбирайтесь.
Держите реестр параметров теста. Какие варианты, какие URL, какие теги в CRM — это экономит часы при разборе результатов.

Сейчас я спокойно запускаю A/B‑тесты: знаю, что у меня есть бэкап, тестовая площадка, понятные инструменты контроля и чёткий план, чтобы не потерять лиды и не исказить аналитику. А клиент получает реальные результаты теста: конверсия по каждому варианту, чистые данные в CRM, отсутствие дублей, понятный отчёт и решение, какую форму оставить. И всё это благодаря тому, что я перестала надеяться на «одну волшебную галочку» и начала действовать системно. А Timeweb даёт для этого все нужные инструменты: бэкапы, поддомены, файловый менеджер, графики, логи и поддержку, которая помогает не сломать конверсии в погоне за статистикой.