Аналитика на сайте: какие события отслеживать и как настроить воронку

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

Критичные метрики и триггеры для контроля

• События конверсий: стабильность количества и доли (резкие провалы/скачки - триггер проверки тегов, фильтров и источников трафика).
• Проходимость воронки по ключевым шагам: аномальный отвал на одном шаге - триггер проверки UX/ошибок/скорости/валидности события.
• Доля событий без обязательных параметров (например, отсутствует product_id или form_id) - триггер исправления dataLayer.
• Расхождения между системами (GA4 vs Метрика vs CRM) - триггер проверки атрибуции, времени, дублей и блокировщиков.
• Дубли событий (одно действие даёт 2+ хита) - триггер аудита триггеров в GTM и повторных инициализаций.
• Снижение доли корректных источников/кампаний (utm потеряны) - триггер проверки редиректов, кросс-домена и шаблонов разметки.

Какие пользовательские события обязательно отслеживать

Этот набор подходит, если вы делаете настройку веб аналитики под лидогенерацию или e-commerce и хотите строить сравнимые отчёты по каналам и креативам. Не стоит начинать с десятков микрособытий, если у вас нет владельца данных и процесса контроля: получите шум, а не управляемые выводы.

Минимальный набор для лидогенерации

• Просмотр ключевой страницы (landing/product/service) с параметром page_type.
• Клик по CTA (кнопки "Оставить заявку", "Записаться", "Получить КП") с cta_id, cta_text, placement.
• Старт формы и успешная отправка с form_id, form_type, lead_source.
• Ошибка формы (валидация/сервер) с error_type, field_name.
• Клик по телефону/мессенджеру с contact_type, placement.
• Запрос прайса/файла (скачивание) с asset_id, asset_type.

Минимальный набор для e-commerce

• Просмотр карточки товара с product_id, price, category.
• Добавление в корзину с product_id, qty, value.
• Начало оформления (checkout_start) с cart_value, items_count.
• Выбор доставки/оплаты с shipping_type/payment_type.
• Покупка с transaction_id, value, currency (и списком товаров).

Примеры payload для пользовательских событий

• Клик по CTA: {event: "cta_click", cta_id: "hero_request", placement: "hero", page_type: "service"}
• Отправка формы: {event: "form_submit_success", form_id: "lead_main", form_type: "callback", page_type: "landing"}
• Добавление в корзину: {event: "add_to_cart", product_id: "SKU123", qty: 1, value: 4990, currency: "RUB"}

Событие	Приоритет	Источник данных	Назначение	Минимальные параметры
form_submit_success	Высокий	dataLayer (фронтенд) / бэкенд подтверждение	Основная конверсия, оптимизация рекламы	form_id, form_type, page_type
cta_click	Средний	dataLayer / GTM click	Понимание интереса и точек входа	cta_id, placement, page_type
form_error	Высокий	dataLayer (валидация)	Диагностика потерь, качество лидов	form_id, error_type, field_name
add_to_cart	Высокий	dataLayer (каталог/корзина)	Воронка покупок, ремаркетинг	product_id, qty, value, currency
purchase	Критический	Бэкенд/платёжка + dataLayer	Выручка, ROAS, сверка с CRM	transaction_id, value, currency

Технические события и инфраструктура сбора данных

Чтобы настройка событий в Google Analytics и настройка целей в Яндекс Метрике не "ломались" при релизах, заранее определите инфраструктуру: кто пушит события, где источник истины, как тестируем и как откатываем.

Что потребуется (доступы и инструменты)

• Доступ уровня редактора/админа: GA4, Яндекс Метрика, Google Tag Manager (или другой TMS), доступ к коду/репозиторию.
• Единый слой данных: dataLayer на сайте (или аналог), договорённости по параметрам.
• Отладка: режим Preview/Debug в TMS, DebugView в GA4, просмотр событий в Метрике, логи фронтенда/бэкенда.
• Согласование приватности: баннер согласия/режимы трекинга, запрет передачи персональных данных в параметры событий.

Технические события, которые помогают диагностике

• page_view_extended (расширенный просмотр): page_type, content_group, user_status (не PII).
• js_error: error_message (обрезать/нормализовать), script, page_type.
• api_error: endpoint_group, status_group (например, 4xx/5xx), page_type.
• consent_state: analytics_storage, ad_storage (если применимо), источник баннера.

Примеры payload для технических событий

• Ошибка JS: {event: "js_error", script: "checkout", error_type: "TypeError", page_type: "checkout"}
• Состояние согласия: {event: "consent_state", analytics_storage: "granted", ad_storage: "denied"}

Стратегия именования событий и организация dataLayer

1. Опишите карту событий под воронку, а не под страницы. Начните с 5-15 событий, которые отвечают на вопросы бизнеса: где пользователи "отваливаются" и что влияет на конверсию. Это базис для настройки воронки продаж на сайте и для последующей оптимизации кампаний.
2. Зафиксируйте нейминг: один язык, один стиль, один глагол. Используйте snake_case и глагол+объект: form_submit_success, add_to_cart, checkout_start. Запрещайте дубли по смыслу (например, одновременно lead и request).
3. Определите обязательные параметры и типы. Для каждого события задайте обязательный минимум (строки/числа/булевы) и правила заполнения.
   • Идентификаторы: form_id, cta_id, product_id - только технические, без телефонов/почт.
   • Контекст: page_type, placement, content_group.
   • Ценность: value, currency - если есть деньги/корзина.
4. Соберите dataLayer-спеку и внедрите единый push. События должны отправляться из одного места (утилита/модуль), чтобы избежать дублей и расхождений между командами.
   • Соглашение: один user action → один push.
   • Нормализация: обрезка строк, фиксированные справочники (например, payment_type).
5. Сделайте маппинг в GTM/тегах: GA4 + Метрика. Настройте триггеры на события dataLayer и прокиньте параметры. Здесь обычно выполняют "настройка событий в Google Analytics" (в GA4 - события и ключевые события) и "настройка целей в Яндекс Метрике" (цели по JS-событию/посещению страниц/кликам).
6. Заложите контроль качества и версионирование. Добавьте среду тестирования/стейдж, правила именования версий контейнера, чек тестов перед релизом и быстрый откат.

Быстрый режим

1. Выберите 7-10 событий: 2-3 шага воронки + конверсия + 2 диагностических (ошибка формы, клик по CTA).
2. Заведите единый нейминг и 3-5 обязательных параметров (page_type, form_id/cta_id, value при необходимости).
3. Отдавайте события через dataLayer и ловите их в GTM одним триггером "Custom Event".
4. В GA4 пометьте ключевые события, в Метрике создайте цели по событиям.
5. Проверьте в Debug/Preview и только потом публикуйте контейнер.

Построение воронки: шаги, условия и сегментация

Воронка должна строиться из событий, которые однозначно отражают шаги. Старайтесь не смешивать шаги разных сценариев (например, "заявка" и "покупка") в одну воронку без сегментации.

Шаги для типовой лид-воронки (пример)

1. view_key_page (или page_view с page_type=landing/service)
2. cta_click (placement=hero/price/footer)
3. form_start (form_id=lead_main)
4. form_submit_success (form_id=lead_main)
5. thank_you_view (если есть страница благодарности) или backend_lead_confirmed

Проверка результата: чек-лист

• Каждый шаг воронки - отдельное событие или событие + чёткое условие параметра (без "размытых" кликов по любому месту).
• События приходят в правильном порядке в рамках одной сессии/пользователя (нет "успеха формы" без старта/показа).
• У шагов есть единые идентификаторы (form_id, cta_id), одинаковые в GA4 и Метрике.
• Сегменты определены заранее: новый/возвратный, устройство, канал, кампания, регион, страница входа.
• Разделены сценарии: заявки vs покупки; разные формы - разные form_id.
• Учтены редиректы/кросс-домен (если оплата/виджет на другом домене) и не рвётся сессия.
• Нет дублей шагов из-за повторной инициализации скриптов (SPA/React/Vue) - проверено на навигации.
• Есть план, как сверять финальную конверсию с CRM/бэкендом (хотя бы на уровне уникального ID без персональных данных).

Визуализация и инструменты: какие отчёты собрать в приоритете

Соберите минимальный "набор приборов", чтобы ежедневно видеть здоровье трекинга и динамику воронки. Для промежуточного уровня обычно достаточно стандартных отчётов GA4/Метрики + 1-2 сводных дашборда.

Что собрать в первую очередь

• Отчёт по конверсиям/ключевым событиям с разрезом по источникам/кампаниям.
• Воронка по основному сценарию (лиды или покупки) с сегментацией по устройствам.
• Отчёт по ошибкам формы: частые поля/типы ошибок, страницы.
• Контент/страницы входа: какие страницы реально приводят к шагам воронки.
• Сравнение систем (GA4 vs Метрика) на одном периоде по одинаковым условиям.

Типовые ошибки, из-за которых отчёты "врут"

• Одинаковое событие называется по-разному в разных местах сайта (или в разных контейнерах).
• Параметры передаются строками там, где нужны числа (например, value), и ломают агрегирование.
• В события попадают персональные данные (телефон, email) - это риск блокировок и потери данных; заменяйте на технические ID.
• Срабатывание на "клик по контейнеру", а не на реальное действие (ложные клики по CTA).
• Дубли из-за двух тегов на одном событии (или из-за повторного пуша в dataLayer).
• Отсутствует учёт SPA-навигации: page_view не отправляется, а воронка разваливается.
• Неправильные условия целей в Метрике (слишком широкие правила) и завышение конверсий.
• Не настроены исключения внутреннего трафика/тестов - отчёты загрязняются.

Тестирование, валидация данных и процессы качества

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

Минимальный регламент проверки перед публикацией

1. Пройти сценарий в тестовой среде и убедиться, что dataLayer пушится один раз на действие.
2. Проверить в Preview/Debug: триггеры, параметры, отсутствие дублей.
3. Проверить попадание событий в GA4 DebugView и в просмотр событий Метрики.
4. Сверить 2-3 ключевых события на проде сразу после публикации контейнера.
5. Зафиксировать версию контейнера и изменения в журнале (что добавили/переименовали/удалили).

Альтернативы, когда уместны

• Серверный сбор (server-side) - когда важна устойчивость к блокировщикам и контроль над данными; уместно для крупных проектов и строгих требований безопасности.
• Трекинг по бэкенд-событиям - когда "успех" должен подтверждаться сервером (оплата, создание лида), чтобы не зависеть от фронтенда.
• CDP/единый трекинг-слой - когда много источников и нужна консистентность идентификаторов и событий между продуктами.
• Привлечение подрядчика - когда нет ресурсов на внедрение и контроль качества; в таком случае логично заранее сформулировать ТЗ и при необходимости заказать настройку Google Analytics и Яндекс Метрики с обязательной передачей спеки и схемы событий.

Практические сценарии и короткие решения

Как быстро понять, какие события реально нужны?

Составьте список из одного основного сценария (лид или покупка) и добавьте по одному событию на каждый шаг + одно событие "ошибка". Остальное подключайте только если есть конкретный вопрос, на который это событие ответит.

Можно ли строить воронку только по просмотрам страниц?

Можно, если шаги строго соответствуют уникальным URL и нет SPA/виджетов. Для форм, модалок и AJAX-успехов надёжнее события из dataLayer.

Что выбрать для конверсии: thank-you страница или событие отправки формы?

Надёжнее событие, подтверждённое логикой приложения (успех от сервера), а не просто открытие страницы. Thank-you можно оставить как дополнительный контрольный шаг.

Почему GA4 и Метрика показывают разные цифры по одному и тому же событию?

Чаще всего причины - разные правила сессий/атрибуции, блокировщики, дубли тегов или разные условия фильтрации. Сравнивайте не "в целом", а по одному каналу и одному устройству, плюс проверьте дубль-срабатывания.

Как безопасно делать настройку целей в Яндекс Метрике, чтобы не завысить конверсию?

Используйте цель по конкретному JS-событию с уникальным form_id/goal_id и проверьте, что событие не летит при ошибке формы. Исключите тестовый трафик и внутренние IP (если применимо).

Какая минимальная схема для настройки событий в Google Analytics (GA4) под воронку?

Достаточно: 1) событие входа (page_view с page_type), 2) один микрошаг (cta_click или form_start), 3) конверсия (form_submit_success/purchase) с параметрами. Дальше пометьте конверсию как ключевое событие и используйте исследования в GA4 для воронки.

Когда стоит перестать "делать самому" и привлечь специалиста?

Если нет доступа к коду/релизам, нет владельца данных или постоянно появляются дубли/провалы после обновлений, самостоятельная настройка превращается в бесконечную отладку. Тогда рациональнее зафиксировать ТЗ и заказать настройку Google Analytics и Яндекс Метрики вместе с документацией и регламентом QA.