Яндекс Метрика: какие события сайта превращаются в данные

На сайте может быть аккуратная форма, понятный каталог и стабильный поток посетителей, а в отчёте — десятки «конверсий». Это ещё не означает, что отдел продаж получил десятки нормальных обращений. Человек мог нажать кнопку дважды, форма могла отправить событие до ответа сервера, сотрудник мог проверить страницу сам. Большую часть событий сайта Метрика получает от счётчика в браузере; их можно дополнять серверными и офлайн-данными через предусмотренные сервисом способы. Смысл этим событиям придаёт настройка, а коммерческий результат подтверждают уже другие системы.

Метрика — продукт Яндекса для веб-аналитики. На страницы сайта устанавливают код счётчика. Он передаёт сведения о просмотрах и настроенных событиях, после чего сервис объединяет действия в визиты и строит отчёты. Маркетолог видит источники трафика, поведение посетителей, достижения целей и записи отдельных сессий в Вебвизоре. Для такой работы важно отдельно понимать роль cookies в браузере и границы хранения идентификаторов.

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

Цель в Метрике — условие, которое выполнил посетитель, а не обещание, что компания получила клиента.

Полезно различать несколько сущностей, которые в бытовом разговоре часто называют одним словом «посещение».

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

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

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

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

В официальной документации Яндекса описаны разные типы целей и способы передавать достижения через JavaScript, API или загрузку данных. Конкретные названия типов, лимиты и элементы интерфейса следует проверять в Справке Метрики перед настройкой: продукт меняется быстрее, чем энциклопедическая статья.

С июня 2026 года параметры событий можно использовать как условия целей, а несколько условий объединять в мультицель через «ИЛИ». Сами параметры существуют независимо от целей и могут использоваться в отчётах. В них, UTM-метках, URL и заголовках страниц нельзя передавать напрямую идентифицирующие сведения: это ограничено условиями сервиса.

Хорошая настройка цели начинается не в кабинете аналитики, а с определения события, которое бизнес готов считать состоявшимся.

Для интернет-магазина добавление в корзину и оплаченный заказ — разные цели. Данные Ecommerce передаются в настраиваемый глобальный JavaScript-контейнер, по умолчанию window.dataLayer; событие покупки стоит отправлять после подтверждения заказа, а не по клику на кнопку. Для сложной B2B-услуги скачивание презентации может быть микроконверсией, отправка технического задания — обращением, а квалифицированная возможность появится только после разговора. Все события полезны, если не смешивать их уровни.

Метрика группирует визиты по источникам: поиск, реклама, социальные сети, переходы с сайтов, прямые заходы и другие категории. UTM-метки позволяют передать в ссылке название кампании, объявления или материала. Это помогает сравнивать каналы, но не делает атрибуцию безошибочной.

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

Ошибки возникают и проще:

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

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

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

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

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

Перед созданием большого дашборда возьмите один важный сценарий. Например, запрос коммерческого предложения.

Сначала договоритесь, что считать:

Затем выполните тест с отдельной UTM-меткой. Проверьте событие в браузере, достижение цели в Метрике, запись на стороне сайта и карточку в CRM. У всех звеньев должен быть общий технический идентификатор или другой устойчивый способ сверки.

Для такой связки Метрика рекомендует сохранять ClientID в отдельном поле сделки: его можно получить методом getClientID и передать вместе с формой в CRM. Это случайный идентификатор браузера, а не гарантированно уникальный человек; его нельзя использовать как единственный идентификатор клиента, и доступ к полю должен быть ограничен задачей сопоставления.

Повторите сценарии с ошибкой обязательного поля, двойным нажатием, медленной сетью и повторной отправкой. Цель «успешная заявка» не должна срабатывать при отказе сервера. Две попытки одного человека не должны автоматически становиться двумя коммерческими возможностями.

После теста сравните данные за обычный период:

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

Метрика показывает поведение на сайте, но не знает всей себестоимости, возвратов, разговора с менеджером и причин отказа. Даже передача офлайн-конверсий не превращает её в финансовую систему: сервис получает те события и значения, которые подготовил бизнес.

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

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

Счётчик, формы, идентификаторы, записи сессий и передача сведений в CRM требуют конкретной цели, применимого основания, минимизации данных, сроков, правил доступа и мер защиты. Федеральный закон № 152-ФЗ задаёт общую рамку, но обязанности зависят от состава данных и процесса. Нельзя помещать телефон, email, имя или другие напрямую идентифицирующие сведения в UTM-метки, URL, заголовки страниц и произвольные параметры Метрики; для передачи данных из CRM используют только предусмотренные сервисом функции и отдельно проверяют правовое основание.

Метрика полезна, когда отчёт приводит к проверяемому действию:

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

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

Яндекс Метрика становится полезной не тогда, когда на сайте появился счётчик, а когда команда одинаково понимает визит, событие, цель и коммерческий результат. Начните с одного важного сценария, пройдите его вручную и сверьте все системы. После этого можно усложнять отчёты, сегменты и автоматическую оптимизацию.

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