Веб-аналитика и CRO: как превратить трафик сайта в заявки

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

CRO — это системное улучшение доли пользователей, которые выполняют целевое действие. Оно начинается не с замены цвета кнопки, а с качества данных и понимания намерения пользователя.

Определить реальную конверсию

На сервисном сайте есть несколько уровней:

1. микроцель — просмотр кейса, калькулятора, цены;
2. начало формы;
3. успешная отправка;
4. валидный контакт;
5. MQL;
6. SQL;
7. договор.

Если оптимизировать только form_submit, спам и нецелевые обращения будут выглядеть успехом.

Формулы:

CR формы = успешные отправки / сессии посадочной × 100%.

CR в MQL = MQL / сессии посадочной × 100%.

CR в продажу = сделки / SQL × 100%.

План измерения

До установки событий составляют таблицу:

lead_id помогает сверять веб-аналитику с CRM и удалять дубли. Персональные данные не следует передавать в GA4 и рекламные системы.

Контроль качества данных

Каждое событие проверяют по четырём условиям:

• срабатывает в правильный момент;
• не дублируется;
• имеет нужные параметры;
• совпадает с фактом в CRM.

Еженедельная сверка:

• отправки сайта;
• записи backend;
• лиды CRM;
• валидные обращения.

Разница более нескольких процентов требует расследования: блокировщики, повторная отправка, ошибки интеграции, тестовые лиды или некорректный триггер.

Исследование поведения

Количественные данные показывают «где», но не всегда «почему». Совмещайте:

• путь пользователя;
• записи сессий при соблюдении приватности;
• карты кликов и скролла;
• ошибки frontend/backend;
• поисковые запросы внутри сайта;
• интервью с продажами;
• короткие опросы;
• ручное тестирование сценария.

GA4 Path exploration позволяет исследовать, какие шаги пользователи выполняют до и после выбранного события, и находить циклы, указывающие на застревание.

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

Используйте ICE или PXL, но не подменяйте оценкой доказательство.

ICE = Impact × Confidence × Ease.

Пример:

• проблема: 38% пользователей мобильной формы получают ошибку телефона;
• гипотеза: маска и понятная подсказка сократят ошибки;
• влияние — 8/10;
• уверенность — 9/10, потому что есть логи;
• простота — 8/10;
• ICE = 576.

Гипотеза «сделать кнопку зелёной» без данных получает низкую уверенность.

Что проверять на посадочной

Первый экран

• кто получает результат;
• какой результат;
• чем подход отличается;
• какой следующий шаг;
• есть ли доказательство рядом.

Структура

• один главный интент;
• логика от задачи к решению;
• понятные заголовки;
• конкретный состав работ;
• кейсы рядом с утверждениями;
• снятие рисков и возражений.

Форма

• минимум обязательных полей;
• понятные labels, а не только placeholder;
• телефон/Telegram как удобный контакт;
• сохранение введённого при ошибке;
• понятное сообщение после отправки;
• быстрый ответ компании;
• корректная мобильная клавиатура.

Доверие

• настоящая команда;
• юридические и контактные данные;
• измеримые кейсы с периодом;
• политика конфиденциальности;
• отсутствие неподтверждённых гарантий.

Сегментация анализа

Средняя конверсия скрывает причины. Разрезайте данные по:

• устройству;
• новой и возвращающейся аудитории;
• источнику и кампании;
• географии;
• посадочной;
• услуге;
• скорости страницы;
• варианту формы;
• качеству лида.

Если desktop конвертирует 3,4%, а mobile — 0,9%, общий показатель не подскажет, что нужно исправлять мобильный сценарий. Если органика даёт меньше форм, но больше SQL, нельзя сравнивать каналы только по CPL.

Статистическая осторожность

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

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

Не запускайте несколько крупных изменений на одном трафике без возможности разделить эффект. Для B2B часто лучше последовательная программа с качественным анализом MQL, чем формальный A/B-тест по кликам.

Дашборд руководителя

Он должен отвечать на пять вопросов:

1. Сколько целевого спроса пришло?
2. Какая доля превратилась в валидные лиды?
3. Каково качество по услугам и каналам?
4. Где теряется больше всего ценности?
5. Как изменения повлияли на pipeline и валовую прибыль?

Показатели: сессии, CR в lead/MQL/SQL, скорость ответа, pipeline value, CAC, валовая прибыль, доля ошибок форм и Core Web Vitals. Клики по кнопке без связи с CRM не являются результатом бизнеса.

Скорость и стабильность

Google рекомендует оценивать Core Web Vitals по порогам: LCP до 2,5 секунды, INP менее 200 мс, CLS менее 0,1. Это не «магические SEO-баллы», а показатели восприятия загрузки, отзывчивости и стабильности.

В кейсе Rakuten 24 улучшение Core Web Vitals сопровождалось ростом конверсии на 33,13% и выручки на посетителя на 53,37%. Это результат конкретного бизнеса, а не универсальный прогноз, но он показывает, почему скорость надо связывать с экономикой.

Практические меры:

• качественное изображение нужного размера, а не исходник 6000 px;
• WebP/AVIF;
• заданные размеры;
• preload только критичного ресурса;
• минимизация сторонних скриптов;
• отложенная загрузка ниже первого экрана;
• удаление скрытых старых блоков;
• контроль шрифтов.

Эксперимент или до/после

A/B-тест нужен, когда трафика достаточно для разумной длительности. Для небольшого B2B-сайта чаще полезнее:

1. исправить очевидную ошибку;
2. сравнить одинаковые периоды;
3. контролировать источники и сезонность;
4. анализировать не только форму, но и MQL/SQL;
5. документировать изменение.

Нельзя завершать тест в момент, когда вариант «вышел вперёд» на один день. Нужны заранее заданные метрика, минимальный эффект, длительность и критерий остановки.

Модель влияния на выручку

Допустим:

• 10 000 целевых сессий;
• конверсия в заявку 1,8%;
• 50% заявок — MQL;
• 20% MQL становятся продажами;
• валовая прибыль сделки 180 000 ₽.

Базово: 10 000 × 0,018 × 0,50 × 0,20 = 18 продаж, или 3 240 000 ₽ валовой прибыли.

После улучшения конверсии до 2,2% при неизменном качестве: 22 продажи, или 3 960 000 ₽. Разница — 720 000 ₽. Модель показывает предел эффекта, но перед решением нужно проверить, не ухудшилось ли качество лидов.

30-дневный цикл CRO

Неделя 1

• аудит событий;
• сверка с CRM;
• мобильное тестирование;
• скорость и ошибки;
• базовая воронка.

Неделя 2

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

Неделя 3

• реализация 2–3 гипотез;
• QA;
• запуск эксперимента или контролируемого изменения;
• мониторинг ошибок.

Неделя 4

• анализ результатов;
• проверка MQL/SQL;
• документирование;
• следующий backlog.

Чек-лист

• [ ] Основная конверсия совпадает с CRM.
• [ ] Есть отдельные показатели form start и submit.
• [ ] Лиды размечены по качеству.
• [ ] Ошибки формы записываются.
• [ ] Телефон и CTA отслеживаются.
• [ ] Проверены мобильные сценарии.
• [ ] Известны Core Web Vitals.
• [ ] Гипотезы имеют данные и ожидаемый эффект.
• [ ] Решения принимаются по бизнес-метрике.

CRO приносит пользу, когда превращает мнение в проверяемую цепочку: сигнал → гипотеза → изменение → измерение → решение. Тогда рост конверсии становится не разовой удачей, а повторяемым процессом.

Типичные ошибки CRO

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

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