Настройка Яндекс Метрики

Настройка Яндекс Метрики начинается с вопроса, какие действия сайта действительно важны бизнесу. Установка кода даёт базовый сбор, но не объясняет качество заявок и причины потерь. Определяем события, источники и контрольные примеры, затем проверяем, что аналитика отражает фактическое поведение сайта, а не только нажатия кнопок.

Счётчик и действующие подключения

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

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

Цели для заявок и коммерческих действий

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

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

Источники, UTM и отчёты

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

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

Электронная коммерция

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

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

Как проверяем результат

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

Результат настройки Метрики — схема событий, работающие цели, доступы и инструкция проверки. Для оценки нужны адрес сайта, CMS, текущий счётчик и список важных действий. Если цель — оценивать продажи и прибыль после обработки заявки, понадобится связь с CRM и отдельный контур сквозной аналитики.

Вопросы перед началом работ

Можно настроить цели без программиста?

Для части простых условий достаточно интерфейса Метрики или возможностей CMS. Подтверждённая отправка сложной формы, SPA и ecommerce часто требуют изменения кода. До оценки проверяем доступные события сайта.

Почему цель срабатывает, а заявки нет?

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

Будет ли Метрика видеть всех посетителей?

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

Нужно создавать новый счётчик?

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

Почему данные расходятся с CRM?

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