Яндекс Карты и сайт: как проверить путь клиента и учитывать обращения

Проверяйте весь путь: карточка, страница, контакт, обращение

Сначала определите задачу маршрута. Человек может хотеть уточнить услугу, узнать условия посещения, позвонить или отправить описание своей ситуации. Для проверки выберите одно действие и пройдите его так, как это сделал бы посетитель.

Запишите четыре точки: откуда человек начал, куда попал, какой способ связи выбрал и чем подтвердился результат. У каждой точки свой источник данных. Если подтверждённого обращения в системе нет, оставьте результат открытым; нажатие на контакт ещё не объясняет, состоялся ли разговор.

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

Не задавайте цель «все показатели должны совпасть». Полезнее заранее договориться, что означает каждое событие и какие выводы оно позволяет сделать. Так в отчёте не появится подмена: «нажали на телефон» превратилось в «получили клиента».

Куда попадает человек из карточки

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

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

Откройте маршрут на телефоне. Посмотрите, читаются ли условия, можно ли найти контакт и не мешают ли продолжению всплывающие блоки. Для проверки формы используйте согласованный тестовый сценарий, чтобы не создавать ложные рабочие обращения. В нашей учебной проверке реальных отправок нет.

Адреса, режим работы и переезды требуют отдельного источника актуальных данных. Если у вас сеть, используйте правила поддержания страниц филиалов. В этом материале мы проверяем переход и учёт результата, не пересобирая справочник точек.

Что видно в карточке, на сайте и в CRM

Яндекс описывает автоматический счётчик, связанный с организацией в Бизнесе. Он собирает действия пользователей на сервисах Яндекса. Например, событие перехода на сайт означает нажатие соответствующей кнопки в профиле. Нажатие на телефон или значок звонка — отдельное действие; оно не подтверждает состоявшийся разговор. Этот автоматический счётчик не регистрирует поведение посетителей на вашем сайте. Источник: статистика организации в сервисах Яндекса.

Для практической сверки разделите сведения на три группы:

Для сетевой организации не предполагайте, что автоматически получили независимый счётчик каждой точки: справка Яндекса указывает на общий автоматический счётчик по филиалам сети. При анализе уточняйте охват конкретного отчёта. Источник: условия сбора статистики организации.

Отдельно учитывайте платное размещение. Вкладка рекламной статистики Яндекс Бизнеса доступна при активной рекламной кампании и описывает её результаты. Возможности этого раздела нельзя обещать всем владельцам бесплатной карточки. Уточняйте, какой продукт подключён и какие именно данные показаны. Источник: статистика рекламной кампании Бизнеса.

Связь сайта с CRM тоже требует настройки и корректных идентификаторов. Передача статусов сделки позволяет отделить обращение от дальнейшего результата, однако одна UTM-метка не создаёт эту интеграцию. Общее устройство передачи обращений рассмотрено в материале об интеграции сайта с CRM. Технический источник: данные CRM в Метрике.

Как договориться о метках и сохранить их на переходе

UTM-метки — параметры ссылки, с помощью которых можно описать источник перехода для аналитики. Метрика формирует по ним отдельный отчёт. Названия значений нужно согласовать внутри команды: источник, тип размещения, кампанию или конкретную ссылку. Источник: отчёт «Метки UTM».

Для учебного маршрута используем такую ссылку:

https://example.test/services/repair/?utm_source=yandex&utm_medium=maps&utm_campaign=profile_main

Здесь yandex, maps и profile_main — наша условная конвенция. Это не обязательная схема Яндекса, не обещание автоматического попадания в категорию «Карты» и не инструкция заменить уже используемые значения. Сначала посмотрите действующие отчёты и договорённости, затем выберите совместимый вариант.

Метрика различает регистр значений меток. Например, два варианта написания источника могут оказаться разными значениями в отчёте. Поэтому полезно хранить согласованное написание и проверять его при подготовке ссылки. Источник: вопросы об UTM-метках.

Перед изменением ссылки проверьте, допускает ли выбранное поле карточки или размещение такой адрес и есть ли у вас право его редактировать. Если изменить ссылку нельзя, зафиксируйте это ограничение. Используйте доступную статистику профиля и сведения счётчика сайта, сохраняя неизвестный источник там, где связь не установлена.

Проверяйте именно конечный адрес. Если сайт перенаправляет посетителя и теряет метки, исходная разметка ещё не обеспечивает наблюдаемость перехода. Такой сценарий указан и в справке Метрики. Источник: проблемы с учётом UTM.

Если в адресе уже есть параметры, добавляйте новые корректно, сохраняя нужный контекст и якорь раздела. В учебном наборе отдельный маршрут содержит service=repair и #price. Не подменяйте существующую метку молча: сначала выясните, для чего она используется. Не включайте в параметры имена клиентов, телефоны, email или описание частной ситуации — для обозначения источника они не нужны.

Учебный маршрут и таблица сверки

Возьмём вымышленную компанию с одной точкой обслуживания. Все ссылки ведут на зарезервированный учебный домен example.test; скрипт не открывает его и не обращается к Яндексу. Для пяти маршрутов заданы исходный адрес, ожидаемая страница и конечный адрес.

Два маршрута сохраняют страницу и параметры. В одном переход ведёт к другой точке, ещё в одном пропадают метки, в последнем меняется значение источника. Отдельный корректный маршрут показывает, как сохранить уже существующий параметр и якорь. Проверка находит расхождение с заданным правилом; она не узнаёт автоматически, какую страницу бизнес действительно хотел использовать.

Теперь посмотрим на девять вымышленных записей о действиях:

Для одного из двух уникальных обращений мы вручную задали проверенную учебную связь с маршрутом. Для второго источник неизвестен. Итог примера — одно обращение с заданной связью и одно с неизвестным источником. Скрипт не достраивает связь только потому, что рядом существует посещение с меткой.

Это намеренно маленький набор для проверки правил. Он не отражает реальную долю обращений с Карт и не является моделью вероятности покупки. Нельзя делить число записей из разных источников и объявлять результат конверсией без согласованного определения, охвата и способа связывания.

Как повторить проверку

В учебном пакете маршрутов и обращений находятся CSV, ожидаемые результаты, скрипт и лист проверки. Распакуйте архив и выполните:

python3 verify.py

Нужен Python 3.10 или новее, без сторонних библиотек. При успехе вывод содержит PASS_EDUCATIONAL_REPLAY, два уникальных обращения, одно обращение с заданной связью и одно с неизвестным источником. Проверяются также потеря и подмена меток, повторные записи, сохранение параметров и якоря.

Связи в данных заданы вручную исключительно для примера. Реальная интеграция ClientId и CRM здесь не проверяется. Поле с «проверенной связью» не появляется автоматически из UTM. Для самостоятельного прохода по вашему маршруту используйте лист сверки карточки, сайта и обращений.

Что делать, если цифры не сходятся

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

Проверьте период и источник каждой выгрузки. Для рекламы уточните продукт и состав отчёта. Для сайта проверьте, что счётчик работает на конечной странице и что выбранные параметры доходят до неё. Для CRM посмотрите, где и каким способом фиксируется источник обращения.

Затем разберите несколько конкретных расхождений. Человек мог нажать на телефон прямо в Картах и не посетить сайт. В другом случае он мог перейти на страницу и связаться позднее иным способом. Это возможные объяснения для проверки, а не установленная причина именно ваших цифр. Если данных недостаточно, сохраните неизвестность и обозначьте, что нужно проверить.

Если счётчик зависит от согласия

Уточните, когда на вашем сайте запускается аналитика. Если счётчик загружается только после согласия посетителя, переход из карточки без такого согласия может не попасть в отчёт сайта. Действие в профиле при этом проверяется в другом источнике. Не записывайте отсутствие визита как отсутствие интереса или обращения.

В согласованном тестовом сценарии отдельно пройдите маршрут до согласия и после него. Зафиксируйте, в каком состоянии запускается счётчик и какие события доступны. Это проверка вашей настройки; она не требует обходить выбор посетителя или включать аналитику всем. Если сведения о визите отсутствуют, сохраните ограничение в сверке, а источник обращения — неизвестным, пока нет подтверждённой связи.

Если человек сменил устройство или браузер

Рассмотрите маршрут, в котором человек посмотрел карточку с телефона, а позднее открыл сайт и отправил запрос с компьютера. Не объединяйте эти действия только по близкому времени или похожей задаче. В справке Метрики ClientID описан как идентификатор браузера: в двух разных браузерах у одного человека будут разные ClientID. Источник: ClientID и UserID в Метрике.

Проверьте, есть ли в вашей системе разрешённый и проверяемый способ связать эти действия, и сохраните основание связи. Одна UTM-метка не подтверждает, что два устройства принадлежат одному человеку. Если связи нет, оставьте источник неизвестным; не приписывайте обращение Картам автоматически. Учебный скрипт такую связь между устройствами не устанавливает.

Завершите разбор короткой записью: какой маршрут проверен, где возникло расхождение, какими данными оно подтверждено и кто выполняет следующий шаг. Отдельно ведите удобство пути и качество измерения. Так вы не будете чинить работающую страницу только из-за несопоставимых отчётов и не пропустите реальную ошибку ссылки за общим ростом действий в профиле.

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