Разведите сведения, которые отвечают на разные вопросы
Источник показывает, откуда посетитель пришёл. Страница входа показывает, что он открыл первым. Страница заявки показывает, где решил обратиться. Это разные сведения, и полезно хранить их отдельно.
Например, человек пришёл из поиска в статью, прочитал кейс и оставил заявку на странице услуги. Если сохранить только последний адрес, путь через статью потеряется. Таблица ниже помогает выбрать поля для сайта и CRM.
Таблицу можно прокрутить по горизонтали.
| Сведение | На какой вопрос отвечает |
|---|---|
| Источник и канал | Откуда пришёл посетитель? |
| Кампания | Где была размещена внешняя ссылка? |
| Страница входа | С чего начался визит? |
| Страница заявки | Где посетитель решил обратиться? |
Не угадывайте источник прямого возврата
Посетитель открыл статью из Google, а на следующий день вернулся напрямую. Это два известных касания. Показывайте их отдельно, если выбранная система учёта позволяет сохранить историю.
Прямой визит без меток не доказывает, что человек раньше не встречал сайт в поиске или чате. Если источник неизвестен, так и запишите. Правило, по которому заявка относится к первому или последнему касанию, согласуйте для всего отчёта.
Привяжите атрибуцию к принятому запросу
Проверяйте источник у принятой заявки в CRM, а не только у нажатия кнопки. Открытие страницы благодарности само по себе не доказывает, что обращение сохранено.
При повторной отправке после ошибки должна находиться исходная заявка с прежними сведениями об источнике. Новые метки не должны незаметно менять её историю. Отсутствие счётчика аналитики не должно мешать отправить обращение.
Как проверить путь от статьи до заявки
В учебном маршруте посетитель приходит из Google на статью о CRM, затем открывает услугу и отправляет форму. В заявке должны сохраниться статья как страница входа, услуга как место обращения и исходная кампания. Переход внутри сайта не должен менять источник.
Проверьте маршрут целиком, включая повторную отправку после ошибки. Одна заявка не должна превращаться в две, а изменение меток между попытками не должно подменять исходный источник. Если браузер запрещает хранение данных, полную историю переходов сохранить удаётся не всегда. Сначала проверьте эти условия на тестовых данных, затем отдельно проверьте доставку в рабочую CRM.
Что известно о переходах из ИИ-сервисов
Показ ссылки в ответе ИИ не означает, что человек открыл сайт или отправил заявку. Переход может прийти без referrer, то есть без адреса сайта-источника. Читатель также может вернуться с другого устройства. В этих случаях полного пути клиента в отчёте не будет.
Таблицу можно прокрутить по горизонтали.
| Наблюдение | Что оно подтверждает | Чего не подтверждает |
|---|---|---|
| Показ ссылки в отчёте ИИ-поиска | Показ, учтённый этим отчётом | Переход и обращение конкретного человека |
| Визит с распознанным доменом ИИ-сервиса | Источник, который удалось распознать | Все ИИ-переходы и полный путь клиента |
| Принятая заявка из статьи | Отправку с этой страницы и сохранённые данные источника | Влияние всех предыдущих прочтений |
| Прямой визит без меток | Источник не удалось определить | Отсутствие знакомства с сайтом через ИИ |
Сопоставляйте отчёты по одному периоду и страницам, учитывая разные часовые пояса и способы агрегации. В CRM храните фактическую страницу заявки и известный источник. Если клиент сам назвал ИИ-сервис, это можно учитывать отдельным ответом клиента, отдельно от данных о переходе.
Для оценки качества обращения перейдите к метрикам обработки заявок; число показов само по себе такого качества не устанавливает.