Почему я сначала проверяю способ измерения, а потом предлагаю менять сайт
Фраза «сайт не даёт заявок» для меня означает, что нужно проверить весь путь обращения. Человек мог нажать кнопку, получить ошибку, отправить форму или написать в мессенджер. В отчёте эти действия иногда оказываются под одним названием. Я хочу разобраться с этим до обсуждения нового первого экрана, цвета кнопок и переезда на другую платформу.
Какое действие назвали заявкой
Я начинаю с определения результата. Клик по кнопке показывает интерес к действию. Успешная отправка формы означает, что система приняла данные. Реальное обращение нужно найти у получателя и проверить отдельно. Разговор с подходящим заказчиком находится ещё дальше. Если назвать всё это заявками, понять причину изменений будет трудно.
Поэтому мне нужна расшифровка каждой цели: где она установлена, что её запускает и какое действие пользователь успел выполнить. Само название в Метрике ничего не доказывает. Цель с названием «Отправка заявки» вполне может срабатывать при нажатии кнопки, даже когда обязательное поле осталось пустым.
Что подтверждает успешная форма
У конструктора сайта есть собственные события. Например, Tilda позволяет запустить обработчик после успешной передачи данных в сервис приёма форм. На него можно опереться, когда нужно учитывать принятые отправки. Клик и попытка отправить форму для такой проверки не подходят.
После этого я отдельно проверяю путь до получателя. Успех на странице не подтверждает, что письмо оказалось в нужном ящике, заявка появилась в CRM и её прочитал менеджер. Здесь нужны разные проверки и понятный ответственный за каждую. Иначе проблема доставки легко превращается в претензию к дизайну.
Можно ли сравнивать два периода
Перед сравнением я смотрю, одинаково ли собирались данные. Если в одном месяце цель считала клики, а в другом только успешные формы, прямое сравнение процентов введёт в заблуждение. Нужно обозначить дату изменения и разделить периоды по способу измерения. Я также проверяю знаменатель: все визиты, пользователи и посетители формы дадут разные показатели конверсии.
Согласие на аналитику тоже влияет на доступные данные. Если счётчик запускается после разрешения посетителя, отчёт ограничен этим условием. Отсутствие события в аналитике само по себе не означает, что человек не обращался. Поэтому количество отправок полезно сопоставлять с заявками у получателя, сохраняя различия между этими источниками.
Что я проверяю перед правкой страницы
Мне нужен простой контрольный сценарий. Нажатие кнопки с незаполненными полями не должно становиться успешной заявкой. Одна принятая отправка должна давать одно событие. Если тот же человек позже отправил новую задачу через ту же форму, она тоже должна учитываться. Защита от дублей не должна навсегда отключать форму в статистике.
Для такой проверки не нужно передавать в аналитику имя, email или описание задачи. Достаточно факта успешной отправки. Значения полей остаются в предназначенном для обращений сервисе. Контрольную отправку я предлагаю заранее пометить как тест, а затем отдельно проверить событие в аналитике и получение заявки. В отчёте её нужно отделить от запросов клиентов.
Когда у меня появляется основание менять сайт
После проверки измерения можно обсуждать сам путь пользователя. Видно ли предложение на телефоне, понятно ли назначение формы, работают ли поля и сообщение об отправке. Воспроизводимую ошибку я считаю приоритетом. Для остальных изменений мне нужна гипотеза с наблюдаемым результатом.
Например, если человек не понимает, что получит после обращения, я начну с текста рядом с формой. Затем проверю тот же сценарий и сравню данные за сопоставимые периоды. Это позволит объяснить результат правки и решить, что проверять дальше.
Что проверить
Перед изменениями сайта я проверяю событие, доставку обращения и сопоставимость данных. Это помогает выбрать правку с понятной причиной и способом проверки.
Обсудить задачу