Четыре события, которые называют заявкой
Нажатие на кнопку означает намерение. Отправка формы — попытку передать данные. Подтверждение сервера — приём обращения на определённом этапе. Разговор с менеджером может установить, что задача подходит компании. Эти события связаны, но не заменяют друг друга.
Допустим, посетитель нажал «Отправить», не заполнив обязательное поле. Если цель срабатывает на нажатие, реклама уже получила конверсию, хотя менеджеру нечего обрабатывать. Другой посетитель оставил обращение успешно, но его браузер заблокировал аналитический скрипт. В почте письмо есть, а в веб-аналитике этого события может не быть.
Поэтому название цели должно описывать её точную границу. «Обращение принято сервером» содержательнее, чем «Лид». Если система подтверждает лишь постановку письма в очередь, так и назовите событие. Доставку в ящик, появление карточки в системе и оплату заказа нужно проверять отдельно.
Сначала словарь, затем настройка
Составьте короткую схему измерений. Для каждого события укажите момент отправки, источник подтверждения и ответственного за проверку. Начало заполнения помогает найти затруднение в форме; принятое обращение показывает технический результат; квалификация объясняет коммерческое качество. Универсальной цели на все случаи здесь нет.
Например, событие lead_accepted можно отправлять после ответа сервера об успешном приёме. Это условное имя: важно, чтобы оно одинаково использовалось в коде и настройках счётчика. В Яндекс Метрике для запрограммированных событий предусмотрен метод reachGoal; порядок настройки описан в официальной справке. Сам метод не определяет, какое действие бизнес должен считать результатом.
Систему управления взаимоотношениями с клиентами — CRM — полезно сделать источником сведений о дальнейшей работе. В ней можно хранить статус обращения и согласованные данные об источнике. В аналитические события не нужно переносить имя, телефон, переписку или весь адрес страницы с произвольными параметрами. Состав передаваемых данных проектируют отдельно от удобства отчёта.
Одна контрольная заявка вместо десяти догадок
Проверку лучше начать с обычного открытия посадочной страницы. Если аналитика на сайте зависит от согласия посетителя, явно разрешите её для своего теста. Посмотрите, загружается ли библиотека счётчика и проходит ли запрос просмотра. Наличие кода счётчика на странице ещё не доказывает, что браузер смог его выполнить.
После этого отправьте согласованную тестовую заявку и сопоставьте три факта: интерфейс сообщил об успехе; обращение появилось у ответственного; событие цели ушло и затем появилось в отчёте. Заранее отметьте время проверки и тестовое происхождение обращения, чтобы оно не попало в оценку качества рекламных клиентов.
При расхождении ищите первый отсутствующий шаг. Не загрузилась библиотека — проверяйте сетевой ответ и блокировки. Форма сообщает ошибку — проверяйте приём обращения. Запрос события ушёл, но отчёт пуст — проверьте номер счётчика, идентификатор цели, период, фильтры и актуальные сведения сервиса о задержках обработки. Одинаковый симптом может иметь разные причины.
Блокировщик в браузере владельца не доказывает, что счётчик не работает у всех посетителей. Но и успешный тест на одном устройстве не означает полного охвата аудитории. Проверка с другого устройства помогает отделить локальную проблему от общей; обходить отказ посетителя от аналитики ради красивой статистики не следует.
Откуда пришёл клиент — отдельный вопрос
Работающая цель ещё не связывает обращение с нужной рекламой. Проверьте, что источник входа сохраняется до отправки формы и связывается с обращением. Для этого заранее определяют допустимые метки, срок хранения и правила передачи в систему учёта. Внутренние переходы не должны подменять исходный источник новой рекламной меткой. После смены домена отдельно проверяют конечные адреса объявлений и поведение перенаправлений.
Атрибуция — правило, по которому результат относят к источнику трафика. Человек мог впервые узнать о компании из рекламы, вернуться через поиск и написать позже. Два отчёта с разными правилами могут распределить один результат по-разному. Прежде чем искать ошибку, сравните период, модель атрибуции и то, что именно считается конверсией.
Идеального равенства между количеством писем и целей может не быть: есть повторные обращения, несколько событий в одном визите, отказ от аналитики и обращения по другим каналам. Нужен регулярный разбор понятных расхождений. Большой необъяснённый разрыв — основание исследовать сбор данных, а не автоматически объявлять один из отчётов правильным.
Дешёвая заявка может оказаться дорогой
Возьмём условный расчёт, не результаты рекламной кампании. На направление А потратили 20 000 рублей и получили 20 обращений. На Б — столько же и 10 обращений. По цене обращения А выглядит лучше: 1 000 рублей против 2 000.
Теперь добавим согласованный критерий качества: клиенту подходит услуга, география и минимальный состав работ. В А ему соответствуют четыре обращения, в Б — пять. Стоимость подходящего обращения составляет уже 5 000 и 4 000 рублей. Это меняет вопрос к рекламе, но ещё не выбирает победителя: обращений мало, а продажи и стоимость исполнения неизвестны.
Для следующего решения нужны одинаковые правила квалификации, причины отказов и связь с завершёнными сделками. Переходить к автоматической оптимизации по квалифицированным обращениям или продажам стоит после проверки передачи событий, качества данных и требований выбранной стратегии. Пока события ненадёжны, система может старательно искать людей, которые нажимают кнопку, — и совсем не обязательно тех, чью задачу компания умеет решить.