Веб-аналитика: события, параметры и проверка данных на сайте

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

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

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

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

Например, кнопка «Получить расчёт» сама по себе мало говорит бизнесу. Если передаются form_name, страница, выбранная услуга и результат отправки, можно отличить открытие формы от успешного обращения. Если CRM позже проставит квалификацию и сделку, появится отдельный слой коммерческого результата. Склеивать эти уровни в один показатель опасно.

Официальные справки Яндекс Метрики и Google Analytics описывают отчёты, события и правила их обработки, но одинаковые слова не означают одинаковую модель. В GA4 есть автоматически собираемые события, события расширенного измерения, рекомендуемые и пользовательские; рекомендуемые имена и параметры открывают предусмотренные продуктом возможности отчётов. В Метрике метод reachGoal сообщает о достижении JavaScript-цели и может передать объект параметров визита; появление этих данных в отчёте «Параметры событий» зависит от способа передачи и настройки отдельной цели. Поэтому общий паспорт события отдельно переводят в схему каждого счётчика, а не копируют имена механически.

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

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

План полезно зафиксировать короткой таблицей:

Такой план не обещает, что цифры ответят на любой вопрос. Он делает видимым, чего именно им не хватает.

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

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

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

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

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

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

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

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

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

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

Полезны четыре контрольных вопроса:

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

Client ID и ClientID — идентификаторы экземпляра браузера в GA4 и Метрике соответственно, а не доказательство личности человека: новый браузер, устройство или очищенные cookies могут дать другую запись. User-ID/UserID задаёт сама компания для известного ей пользователя и должна выдавать уникально и последовательно. В GA4 такой идентификатор не должен содержать сведения, по которым третье лицо может установить личность; Метрика также запрещает передавать телефон, email и другие идентифицирующие данные через обычные параметры и UserID, кроме специально предусмотренных функций сервиса.

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

Cookies, localStorage и псевдонимные идентификаторы не следует автоматически называть анонимными или юридически нейтральными. Баннер или CMP получает выбор пользователя, а consent mode передаёт его состояние Google и меняет поведение тегов; ни один из этих технических механизмов сам по себе не определяет применимое правовое основание. До запуска описывают цель, основание, состав данных, роли платформы и компании, доступы и удаление. Срок в настройке аналитической платформы относится только к охваченному этой настройкой слою данных и не задаёт автоматически сроки для CRM, резервных копий и выгрузок; по № 152-ФЗ каждую копию с персональными данными хранят не дольше, чем требует её цель, если иной срок не установлен законом или договором.

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

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

Она не показывает маржу без данных учёта, не знает причину отказа менеджера и не устанавливает причинность между изменением дизайна и выручкой. Отчёт об источнике распределяет наблюдаемую ценность по заданному правилу. Для ответа «что именно вызвало эффект» нужен эксперимент, контрольная группа или другой корректный дизайн исследования — об этом подробнее в материале про A/B-тестирование.

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

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

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