Правильная настройка веб-аналитики строится от целей бизнеса: выбираете GA4 и/или Яндекс.Метрику, проектируете архитектуру событий, внедряете события через GTM, помечаете ключевые события как конверсии, проверяете качество данных и только затем подключаете сквозную аналитику из CRM и рекламных систем. Так вы избегаете «мусорных» метрик и получаете измеримые решения.
Перед началом: что проверить в проекте
- Определены бизнес-результаты (лиды/заказы/оплаты/заявки) и «что считается успехом» для каждого.
- Есть доступы: GA4 property, GTM container, сайт/код, Яндекс.Метрика, рекламные кабинеты, CRM.
- Согласован список событий и конверсий, их названия и правила срабатывания (без двусмысленностей).
- Единая стратегия идентификаторов: client_id/user_id/номер сделки, правила передачи (с учетом приватности).
- Настроены UTM-метки и стандарты нейминга кампаний (иначе источники будут «грязными»).
Выбор модели сбора данных: GA4 или Яндекс.Метрика
| Цель | Действия (подготовка) | Критерии успешности |
|---|---|---|
| Выбрать базовый стек аналитики | Составьте список отчетов, которые нужны (воронка, источники, e-commerce, формы), и где вы будете принимать решения (GA4/Метрика/BI). | Понятно, какой инструмент «главный» и почему; нет дублирования ради дублирования. |
| Понять требования к приватности и данным | Зафиксируйте, какие данные нельзя собирать (PII), где хранятся данные, кто имеет доступ. | События не содержат персональные данные; доступы ограничены ролями. |
| Согласовать метод внедрения | Решите: через GTM, через код, серверный сбор (если нужен), какие окружения (prod/stage). | Есть один источник правды по внедрению; изменения проходят через контроль версий/согласование. |
Кому подходит GA4. Если вы строите аналитику вокруг событий, хотите гибкую модель параметров, интеграции с Google-рекламой и единый подход для web+app. «Настройка GA4» почти всегда имеет смысл как базовый слой событий и конверсий.
Кому подходит Яндекс.Метрика. Если важны вебвизор/карты, быстрые цели по кликам/скроллу, удобная диагностика поведения. «Настройка Яндекс Метрики» уместна как независимая проверка данных и инструмент UX-диагностики.
Когда не стоит делать. Не начинайте «настройку веб аналитики под ключ», если не определены конверсии и нет стандарта UTM/нейминга: вы получите отчеты без управляемости. Не внедряйте события «на всякий случай» - это усложняет поддержку и размывает конверсии.
Архитектура событий: схема, наименования и приоритеты
| Цель | Действия (подготовка) | Критерии успешности |
|---|---|---|
| Собрать требования к событиям | Опишите сценарии: просмотр, поиск, добавление в корзину, отправка формы, звонок, оплата, ошибки; для B2B - этапы лида. | Каждое событие привязано к решению/гипотезе; нет «событий ради событий». |
| Зафиксировать нейминг и параметры | Определите шаблоны имен: event_name (латиница, snake_case), набор параметров (например, form_id, product_id, value, currency, page_type). | Названия стабильны; параметры повторно используются и не дублируют смысл. |
| Расположить события по приоритету | Разделите на уровни: бизнес-конверсии, микро-конверсии, поведенческие события, диагностические события (ошибки). | Первыми внедряются бизнес-конверсии; остальные - после стабилизации качества данных. |
| Подготовить доступы и инструменты | Проверьте доступ к GTM, GA4, отладчику (Preview), среде тестирования; согласуйте, кто правит dataLayer. | Есть ответственные; изменения воспроизводимы; правки не делаются «в обход». |
Минимально рабочая схема для intermediate: фиксируйте (1) событие, (2) триггер (что именно считается действием), (3) параметры, (4) где проверяем (GTM Preview/DebugView/Realtime), (5) статус (план/в работе/в проде).
Реализация событий в GA4: настройка, теги и параметры
| Цель | Действия (подготовка) | Критерии успешности |
|---|---|---|
| Подготовить GTM и базовую конфигурацию | Создайте/проверьте контейнер GTM, добавьте GA4 Configuration (или Google tag), включите необходимые переменные. | Базовые page_view и параметры страницы приходят в GA4 без дублей. |
| Подготовить источники данных для событий | Определите: события из dataLayer (предпочтительно), клики/видимость элементов (как временное решение), серверные события (если нужно). | Для критичных событий есть детерминированный триггер, а не «клик по классу». |
| Определить правила приватности | Запретите передачу PII в параметрах (email/телефон/ФИО), проверьте URL на наличие персональных данных. | В отладке параметры обезличены; в URL нет чувствительных данных. |
- Проверьте, что у вас есть доступ Edit в GA4 и Publish в GTM.
- Согласуйте список событий и параметров (это ускорит «настройка целей и событий GA4» и уменьшит переделки).
- Подготовьте тестовые сценарии: отправка формы, тестовый заказ, оплата/ошибка оплаты, возврат на thank-you.
- Определите, где будет источником правды value и currency (особенно для e-commerce).
-
Создайте/проверьте GA4 property и поток данных (Web data stream).
В GA4 откройте Admin → Data streams → Web и убедитесь, что домен и параметры потока корректны. Дальше вы будете проверять поступление событий через Realtime/DebugView.- Не включайте лишние автособытия, если они конфликтуют с вашим неймингом; лучше осознанно оставить минимум и добавить нужное руками.
-
Настройте базовый тег в GTM (Google tag / GA4 Configuration).
Добавьте тег, укажите Measurement ID, триггер All Pages. Это основа «настройка GA4» для сайта.- Если на сайте уже стоит gtag/GA - проверьте, нет ли двойной отправки page_view (GTM + код).
-
Определите источник событий: dataLayer в приоритете.
Для надежных событий (покупка, лид) лучше пушить объект в dataLayer и ловить его Custom Event в GTM. Это снижает риск поломки при редизайне.- Пример логики: dataLayer.push({event: 'lead_submit', form_id: 'calc', lead_type: 'b2b'}).
-
Создайте триггеры GTM под каждое ключевое действие.
Для dataLayer - Trigger type: Custom Event (event name = lead_submit). Для кликов/видимости используйте CSS-селекторы только когда dataLayer недоступен.- Критичные события не завязывайте на Click Text и нестабильные классы - это ломается чаще всего.
-
Создайте GA4 Event теги и передайте параметры.
В теге GA4 Event задайте event_name и добавьте параметры (form_id, value, currency, item_id и т.д.). Это и есть практическая часть «настройка целей и событий GA4».- Параметры должны быть однотипными: не смешивайте number и string для одного и того же параметра.
-
Отладьте в GTM Preview и GA4 DebugView до публикации.
Запустите Preview, пройдите сценарий на сайте, проверьте, что теги срабатывают один раз и с правильными параметрами. В GA4 убедитесь, что событие видно в DebugView.- Если событие срабатывает дважды - проверьте, нет ли повторного триггера или дублирующего пикселя в коде.
-
Опубликуйте контейнер и проверьте Realtime на боевом трафике.
После публикации повторите сценарий без режима Debug, убедитесь, что событие видно в Realtime и параметры заполнены.- Зафиксируйте версию GTM и кратко опишите изменения в комментарии к релизу.
Конверсии и цели: правила, описание и имплементация
| Цель | Действия (подготовка) | Критерии успешности |
|---|---|---|
| Определить, что считать конверсией | Сформулируйте правила: событие + условия (например, lead_submit только при status=success). | Конверсия однозначно воспроизводима и не накручивается техническими действиями. |
| Согласовать описания и владельцев | Для каждой конверсии зафиксируйте смысл, где возникает, кто отвечает за корректность (маркетинг/продукт/разработка). | Любой участник команды понимает, что измеряется и где чинить при сбое. |
| Синхронизировать GA4 и Метрику | Сопоставьте: GA4 conversions ↔ цели Метрики, чтобы отчеты не противоречили друг другу. | В обоих инструментах одинаковая логика, различаются только методики подсчета. |
- В GA4: ключевые события помечены как Conversions (Admin → Events/Key events) и не содержат лишних дублей.
- Для каждой конверсии есть правило «одно действие пользователя = одно срабатывание» (дедупликация по thank-you, transaction_id, lead_id).
- События разделены: attempt (попытка) и success (успех), конверсией является только success.
- Параметры конверсии стабильны: value/currency передаются одинаково во всех сценариях.
- В «настройка Яндекс Метрики» цели созданы так, чтобы не зависеть от внешнего вида кнопок (предпочтительно по dataLayer/событию, либо по URL thank-you как fallback).
- UTM-метки и авторазметка не конфликтуют; источники не попадают в (not set) из-за редиректов/обрезки параметров.
- Внутренние переходы не перезаписывают source/medium (проверены редиректы, трекинговые ссылки, платежные страницы).
- Есть тестовый протокол: как проверить конверсию вручную и где смотреть результат (GA4 Realtime/Reports, Метрика «Конверсии»).
Сквозная аналитика: интеграция данных из CRM и рекламных источников
| Цель | Действия (подготовка) | Критерии успешности |
|---|---|---|
| Сшить онлайн-события с CRM | Определите идентификатор связки (lead_id/deal_id) и точки передачи (форма/коллтрекинг/чат). | У каждой сделки есть источник и связанный визит/сессия (на уровне вашей модели). |
| Подключить рекламные расходы | Согласуйте, откуда берете cost (кабинеты/коннектор/выгрузки) и как маппите кампании на UTM. | Расходы сопоставляются с кампаниями без ручных костылей в отчетах. |
| Определить конечные метрики | Зафиксируйте: выручка/маржа/прибыль, окно атрибуции, статус сделки (успешно/проиграно), возвраты. | Отчеты отвечают на вопросы CAC/ROMI в рамках принятой модели, а не как получится. |
«Сквозная аналитика настройка» чаще всего ломается не на интеграции, а на несовместимых правилах нейминга и идентификаторов. Проверьте типовые ошибки:
- Нет общего ключа связки. В CRM не сохраняется client_id/user_id/utm, поэтому лиды нельзя корректно связать с визитами.
- UTM-метки не стандартизированы. Одинаковые кампании размазаны по разным написаниям, отчеты требуют ручной нормализации.
- Редиректы/промежуточные домены съедают параметры. После перехода на оплату/поддомен UTM теряются, источник становится прямым.
- Дубли сделок и событий. Одна заявка создается несколько раз (повторная отправка формы/ошибка сети), а аналитика считает это разными лидами.
- Смешаны попытки и успехи. В сквозные отчеты попадают незавершенные заявки, из-за чего падает качество атрибуции.
- Разные окна атрибуции в системах. Сравнивают цифры из разных моделей, получают ложные выводы, что аналитика не сходится.
- Не описан процесс обновления статусов. Продажи меняют этапы сделки задним числом без логики, историчность метрик ломается.
- Непрозрачные коннекторы. Интеграция не логирует ошибки и пропуски, поэтому невозможно отладить расхождения.
Тестирование, мониторинг и поддержка настроенной аналитики
| Цель | Действия (подготовка) | Критерии успешности |
|---|---|---|
| Сделать контроль качества регулярным | Опишите регламент: что проверяем после релиза, кто отвечает, где фиксируем инциденты. | Проблемы находят до того, как они попадут в управленческие отчеты. |
| Снизить риск поломок при изменениях сайта | Переведите критичные события на dataLayer, версионируйте GTM, держите тестовую среду. | Редизайн не ломает конверсии; изменения откатываются по версиям. |
| Упростить поддержку под ключ | Соберите документацию: карта событий, список конверсий, UTM-стандарт, схема интеграций, чек тестов. | Новый специалист может поддерживать «настройка веб аналитики под ключ» без расследований, что где было. |
Альтернативы и когда они уместны:
- Серверный сбор (server-side tagging). Уместен, когда нужно больше контроля над передачей данных и устойчивость к блокировкам; требует дисциплины в идентификаторах и инфраструктуре.
- Только dataLayer + минимум автособытий. Уместно для проектов с частыми изменениями интерфейса: меньше «магии» кликов, больше стабильности.
- Две независимые системы (GA4 + Метрика) как взаимная валидация. Уместно, когда важно быстро находить сбои: расхождения сигнализируют о проблеме внедрения или источников.
- BI-слой поверх (выгрузки/коннекторы). Уместно, когда нужны единые отчеты по расходам, CRM и аналитике; важно заранее описать модель данных и правила обновления.
Типичные проблемы при внедрении и способы их устранения
Почему события в GA4 видны в DebugView, но не появляются в отчетах?
Проверьте, что событие отправляется без ошибок в боевом режиме и не фильтруется правилами. Для ключевых событий убедитесь, что вы пометили его как конверсию и не используете разные имена для одного действия.
Почему конверсии считаются вдвое больше, чем реальных заявок?
Ищите дубли: два тега, два триггера, повторное срабатывание на перезагрузке thank-you. Для заявок используйте success-событие и дедупликацию по lead_id/transaction_id.
Почему после внедрения пропали корректные источники трафика?
Проверьте редиректы, обрезку UTM, переходы на поддомены и платежные страницы. Убедитесь, что внутренние ссылки не перезаписывают source/medium и что UTM-стандарт соблюдается во всех кампаниях.
Почему цели в Метрике срабатывают, но в GA4 аналог не совпадает?
Сверьте логику триггеров: в Метрике цель могла быть по клику, а в GA4 - по факту успеха формы. Приведите оба инструмента к одной бизнес-логике и оставьте клик только как диагностический сигнал.
Почему сквозная аналитика не связывает сделки с визитами?
Почти всегда нет общего идентификатора или он не сохраняется в CRM. Добавьте сохранение client_id/user_id/utm на первом касании и передавайте lead_id обратно в события для контроля связки.
Почему после редизайна перестали работать кликовые события?
Клики по CSS-классам нестабильны: классы и DOM меняются. Перенесите критичные события в dataLayer и используйте Custom Event-триггеры, чтобы дизайн не влиял на измерения.
