Содержание 10 разделов ↘
Низкая конверсия — не диагноз. Иногда сайт действительно мешает покупателю, а иногда изменилась структура трафика, сезон, товарный ассортимент или способ подсчёта цели. Этот порядок проверки подходит и B2B-сайту с заявками, и интернет-магазину; конкретные целевые действия для них будут разными.
В конце у вас будет реестр подтверждённых проблем с приоритетом, ответственным и способом проверки исправления — не список общих пожеланий «сделать современнее».
Выберите одну конечную цель для диагностики
Сначала сформулируйте, что именно ухудшилось: оплаченные заказы, принятые заявки, назначенные встречи или подтверждённые звонки. Нажатие кнопки, открытие формы и успешная покупка — разные события. Считайте конверсию как число сессий или пользователей с целевым действием, делённое на согласованную базу; базу явно указывайте в отчёте.
Отделяйте обращения от новых клиентов. Если заявок стало больше, но доля пригодных для продаж упала, проблема может быть в качестве трафика или форме, а не в количестве посетителей.
| Этап | Событие | Где проверить |
|---|---|---|
| Визит | Сессия или пользователь | Веб-аналитика |
| Намерение | Открытие карточки, выбор тарифа, начало формы | События и путь |
| Обращение | Успешно принятая форма / звонок | Сервер, коллтрекинг, CRM |
| Продажа | Оплата либо согласованный статус сделки | CRM и платёжные данные |
Убедитесь, что аналитика считает реальное действие
Проведите тестовую отправку формы и проверьте три следа: сообщение об успехе для пользователя, запись на сервере или в CRM и событие в аналитике. В справке Метрики описаны требования автоматического отслеживания форм; для нестандартных JavaScript-форм автоматическая цель может не подойти.
Не объявляйте каждое срабатывание цели подтверждённой заявкой. При ошибке валидации пользователь мог лишь попытаться отправить данные. Разведите «начало формы», «попытка», «успешно принята сервером» и «валидное обращение». Проверьте не только браузерный отчёт, но и реальные записи без передачи персональных данных в открытые отчёты.
Если события расходятся с CRM, сначала исправьте измерение. Сравнивать конверсию версий сайта по неверной цели бессмысленно.
Разбейте трафик на сопоставимые группы
Общая конверсия может снижаться при стабильной эффективности каждой группы, если выросла доля менее готовой аудитории. Отдельно сравните устройства, новые и повторные визиты, брендовый и небрендовый поиск, рекламу, прямые заходы и ключевые посадочные страницы. Не сравнивайте только абсолютные заявки при разных объёмах.
В периоде А было 800 целевых визитов с конверсией 5% и 200 ознакомительных с конверсией 1% — 42 обращения на 1 000 визитов (4,2%). В периоде Б пришли 400 целевых и 600 ознакомительных визитов при тех же конверсиях сегментов — 26 обращений (2,6%). Конверсия сайта в целом снизилась, хотя внутри обеих групп не изменилась. Числа условные; это иллюстрация влияния структуры трафика.
Чтобы сделать вывод, проверьте, что группы действительно сопоставимы по географии, устройствам, страницам и бизнес-предложению.
Пройдите путь пользователя собственными руками
Откройте основные страницы на обычном телефоне и настольном компьютере. Повторите сценарий для человека, который впервые слышит о компании: от рекламного обещания или поискового запроса до подтверждения обращения. Не ориентируйтесь только на удачную главную страницу.
- Понятно ли за первые секунды, что компания предлагает и кому?
- Совпадает ли обещание в объявлении с первым экраном?
- Есть ли цена или прозрачный принцип её расчёта, сроки, ограничения и причины доверять компании?
- Видна ли следующая кнопка на мобильном без мешающих элементов?
- Можно ли завершить форму без ошибок при медленном соединении?
- Понятно ли, что делать после отправки, и не теряется ли обращение?
Записывайте не мнение «выглядит устаревшим», а наблюдение: «на ширине 360 px кнопка подтверждения перекрыта всплывающим окном».
Проверьте скорость и устойчивость интерфейса
Сначала проверьте реальную загрузку основного содержимого и отзывчивость интерфейса на мобильных устройствах, затем — технические показатели. Google описывает Core Web Vitals как важную часть оценки удобства страницы, но предупреждает, что идеальные показатели сами по себе не гарантируют высоких позиций в поиске.
Для бизнеса главное — не число в инструменте, а наблюдаемый сбой: кнопка срабатывает с задержкой, содержимое смещается перед нажатием, телефонная форма зависает. Сопоставляйте лабораторную проверку с поведением настоящих пользователей, особенно на слабых устройствах и соединениях.
Исследуйте формы, ошибки и завершение покупки
Для формы измерьте долю начавших заполнение, столкнувшихся с ошибкой и завершивших отправку. Проверьте маску телефона, подсказки, обязательность полей, текст согласия, ответ сервера, сообщения об ошибках и повторные отправки. Для интернет-магазина добавьте корзину, доставку, оплату, доступность способа получения и итоговую стоимость.
Исследование Baymard Institute о сценариях оформления заказа показывает, что даже распространённые интернет-магазины сохраняют заметные проблемы удобства. Эти результаты не являются прямой оценкой конверсии вашего сайта: локальную причину нужно подтвердить тестированием и данными.
| Симптом | Что проверить | Не делать автоматически |
|---|---|---|
| Форму часто начинают и редко заканчивают | Ошибки, обязательные поля, отказ сервера | Удалять все поля без понимания квалификации |
| Много переходов в корзину, мало оплат | Доставка, финальная цена, способ оплаты | Списывать всё на дизайн кнопки |
| Хорошие лиды, мало продаж | Ответ менеджеров, сроки, наличие товара | Покупать больше трафика |
Проверьте обещание, цену и качество аудитории
Если технических препятствий не найдено, переходите к содержанию. В сложной B2B-продаже человеку нужны требования к проекту, диапазон сроков, описание этапов и способ квалифицированного разговора. В товарном B2C чаще решают наличие, доставка, возврат, цена и отзывы, которым можно доверять.
Не копируйте лид конкурента без проверки: знакомая формулировка может привлечь не вашу аудиторию. Сравните реальные вопросы покупателей с тем, что объясняет сайт. Если большинство лидов отваливается из-за минимального объёма заказа, укажите этот порог до формы, а не прячьте его у менеджера.
Ранжируйте гипотезы по доказательству и риску
Соберите backlog с полями «сегмент → наблюдение → источник доказательства → предполагаемая причина → изменение → ожидаемый сигнал → ответственный». В приоритет ставьте критические поломки, затем массовые препятствия и только потом косметику.
| Гипотеза | Доказательство | Проверка эффекта |
|---|---|---|
| Форма не работает в конкретном браузере | Воспроизводимая ошибка и журнал сервера | Доля успешно принятых форм |
| Стоимость доставки появляется в конце | Отзывы пользователей и выходы со стадии оплаты | Доля оплаченных корзин по сопоставимым сегментам |
| Для B2B непонятен минимальный проект | Повторяющиеся вопросы в звонках | Качество обращений и доля подходящих проектов |
Не превращайте каждую рекомендацию в A/B-тест. Явную техническую поломку исправляют сразу; спорное изменение интерфейса тестируют там, где хватит трафика и времени. Не объявляйте «победу» по единичным заказам.
Зафиксируйте результат до запуска редизайна
- Проверьте соответствие аналитических целей подтверждённым обращениям.
- Сохраните сопоставимые сегменты за одинаковый период.
- Воспроизведите путь на мобильном и десктопе.
- Проверьте формы, скорость и технические ошибки.
- Соберите вопросы клиентов, отказы и несоответствие предложения.
- Исправьте подтверждённые поломки и измерьте изменения.
- Только после этого решайте, нужен ли отдельный эксперимент или большой редизайн.
Итог — диагностическая карта с приоритетами и измерениями. Для более подробного разбора поля ввода и качества обращения используйте материал о форме заявки. Редизайн без диагноза может сделать сайт красивее, но не устранить причину потери покупателей.
Шаблон протокола проверки и приёмки исправления
Каждую проблему оформляйте как самостоятельную запись, иначе команда быстро перейдёт к спорам о вкусе. Хорошая запись связывает наблюдение с доказательством и заранее определяет, как вы поймёте, что проблема устранена.
| Поле | Что записать | Пример формулировки |
|---|---|---|
| Где | URL, устройство, браузер, путь входа | Страница услуги, мобильный экран 390 px |
| Что произошло | Воспроизводимое действие и результат | После отправки форма показала ошибку, но CRM создала запись |
| Доказательство | Скриншот, запись теста без персональных данных, журнал события | Три последовательных контрольных отправки |
| Предполагаемая причина | Версия, которую ещё надо подтвердить | Несогласованная обработка успешного ответа сервера |
| Ответственный | Разработчик, аналитик, редактор или владелец продукта | Один исполнитель и дата |
| Приёмка | Однозначный тест до и после | Один успешный ответ сервера, одна запись CRM, одна цель |
| Наблюдение результата | Числитель, знаменатель, период, сегмент | Доля реально принятых форм на мобильных |
Чтобы не подменять исследование эмоцией, отмечайте уровень уверенности: подтверждённая поломка, вероятная причина с данными или идея без проверки. Для последней категории сначала собирают сведения, а не заказывают полноценный редизайн.
Изменение конверсии после исправления оценивают на сопоставимом трафике. Если одновременно изменились бюджет рекламы, цены и сезонность, не приписывайте весь рост новому экрану. Малые выборки не позволяют уверенно оценивать небольшие улучшения.
