Большинство проектов, которые к нам приходят, уже имеют разметку GA4, но данные в отчётах не совпадают с реальностью. Конверсии удваиваются, микроконверсии не отслеживаются, а атрибуция размазывает бюджет. Причина — неправильное проектирование событий и отсутствие кастомных параметров. Мы настроили аналитику для 50+ проектов за 5 лет работы и знаем, как избежать этих ошибок. После внедрения правильно спроектированных событий точность данных достигает 95%, а стоимость лида снижается на 20% за счёт корректной атрибуции.
Как GA4 отличается от Universal Analytics и почему это важно?
В UA целью было посещение страницы или достижение определённого условия. GA4 считает конверсиями события. Каждое событие может быть помечено как конверсионное, и оно сразу участвует в атрибуции. Но есть нюанс: GA4 считает несколько конверсий одного типа в сессии. Если нужно учитывать только первую регистрацию, это потребует дополнительного параметра или фильтрации.
| Характеристика |
Universal Analytics |
Google Analytics 4 |
| Сущность конверсии |
Цель (goal) |
Событие (event) |
| Повторные конверсии |
По умолчанию 1 на сессию |
Несколько по умолчанию |
| Модель атрибуции |
Last Click |
Data-Driven или Last Click |
| Кастомные параметры |
Ограничено |
До 50 кастомных измерений |
Почему Data-Driven Attribution точнее Last Click и когда её использовать?
Модель атрибуции по умолчанию в GA4 — Data-Driven (при 1000+ конверсий в месяц). Она распределяет ценность между касаниями, а не отдаёт всё последнему клику. Тесты показывают, что DDA повышает точность атрибуции на 30% по сравнению с Last Click. Если данных меньше, GA4 автоматически переключается на Last Click. Мы рекомендуем переходить на DDA при достаточном объёме — это даёт более реалистичную картину.
Как правильно спроектировать конверсии?
Мы начинаем с аудита воронки: определяем, какие действия пользователя действительно значимы — отправка формы, клик на номер телефона, оформление заказа. Затем для каждого действия создаём отдельное событие с уникальным названием. Например, generate_lead для лида, purchase для покупки. В названиях используем snake_case без пробелов. Типичная ошибка — смешивание нескольких действий в одном событии, что приводит к задвоению и размытию атрибуции.
Базовая разметка конверсионных событий
Конверсии отправляются через gtag.js или GTM. Пример — отправка формы:
gtag('event', 'generate_lead', {
event_category: 'lead',
event_label: 'contact_form',
value: 1,
currency: 'RUB',
form_name: 'main_contact',
page_section: 'footer',
});
Покупка:
gtag('event', 'purchase', {
transaction_id: 'ORDER-789',
value: 14500,
currency: 'RUB',
items: [{ item_id: 'SKU-001', name: 'Pro Plan', price: 14500, quantity: 1 }],
});
Важно передавать ценность в параметре value и валюту.
Кастомные конверсии через GTM и Data Layer
Если сайт использует GTM, настройка упрощается. Создаём триггер, например, на отправку формы или переход на страницу спасибо. Затем тег с типом «Google Analytics: GA4 Event». Проверяем через Preview и DebugView. Так можно разметить любую конверсию за несколько минут. Для передачи динамических данных (ID пользователя, сумма заказа) используем dataLayer. Обязательно очищаем ecommerce: null перед следующим событием, чтобы не пересекались данные.
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: orderId,
value: totalAmount,
currency: 'RUB',
items: cartItems,
},
user_id: currentUser?.id,
});
window.dataLayer.push({ ecommerce: null });
| Параметр |
GTM |
gtag.js |
| Время настройки одного события |
10–15 мин |
15–30 мин |
| Требуется правка кода |
Нет (если dataLayer) |
Да |
| Гибкость |
Высокая (триггеры, переменные) |
Средняя |
Настройка в интерфейсе GA4 и атрибуция
События, которые начали поступать, нужно отметить как конверсии: Admin → Events → Mark as conversion. Параметры событий регистрируем в Custom Definitions. Лимит — 50 кастомных измерений на свойство. Для атрибуции GA4 по умолчанию использует Data-Driven Attribution (если данных достаточно). Модель можно сменить в Attribution Settings. Для импорта в Google Ads связываем аккаунты и выбираем нужные конверсии. После этого конверсии доступны для стратегий «Целевая цена за конверсию». Обратите внимание: при смене модели атрибуции данные за прошлые периоды пересчитываются автоматически — это может вызвать временные расхождения.
Отладка и проверка
Используйте DebugView в GA4 для реального времени. В консоли браузера проверьте dataLayer и gtag. Расширение Tag Assistant помогает видеть все hits.
Подробнее о Tag Assistant
Tag Assistant — это расширение Chrome от Google, которое показывает все срабатывающие теги (GA4, GTM, Google Ads) на странице. Оно подсвечивает ошибки, например дублирование тегов или отсутствие нужных параметров. Рекомендуем при каждом изменении в GTM прогонять через него проверку.
Что входит в нашу работу
- Аудит текущей маркировки GA4 и выявление ошибок
- Проектирование событий под бизнес-воронку
- Настройка GTM или gtag.js для отправки конверсий
- Регистрация кастомных параметров и измерений
- Настройка атрибуции и импорт в Google Ads
- Передача токенов (client_id, session_id) в CRM при необходимости
- Обучение команды заказчика работе с отчётами
- Документация по всем настроенным событиям
Мы гарантируем точность данных: после сдачи вы получите отчёты, в которых цифры совпадают с реальными действиями пользователей. Закажите аудит текущей разметки — оценим и предложим план доработок. Получите консультацию по настройке конверсий.
Сроки
Разметка 3–5 ключевых конверсий в коде + GTM-теги — 1 день. Настройка кастомных параметров и Data Layer — 4–6 часов. Настройка атрибуции и связка с Google Ads — 2–3 часа.
Настройка веб-аналитики: GA4, GTM, Яндекс.Метрика и Amplitude
Мы часто видим: конверсия 1.2 %, трафик растёт, а конверсия стоит. Маркетолог смотрит в Google Analytics и говорит: «пользователи уходят с шага 2 оформления заказа». Разработчик открывает тот же шаг — ошибок нет, в Sentry тишина. Значит, дело не в JS-баге, а в UX или в кривых данных, которые показывает аналитика. Аналитика ломается незаметно: событие перестало трекаться после редеплоя — никто не заметил; GTM-тег стреляет дважды — данные задвоились; фильтр GA4 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.
После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 50 000 сессий в день, где дедупликация purchase вернула 20 % неверно приписанных конверсий.
Почему события GA4 дублируются и как это исправить?
Universal Analytics закрыт, его место заняла событийная модель GA4. В ней нет фиксированных хитов страниц и транзакций — только события с параметрами. Это гибче, но требует правильного дизайна событий.
Автоматические события GA4 собирает сам: page_view, scroll, click, session_start. Рекомендуемые события нужно реализовать самостоятельно: purchase, add_to_cart, begin_checkout, view_item. Google ожидает конкретную схему параметров — если передать product_id вместо item_id, данные попадут в GA4, но не в стандартные отчёты e-commerce. Кастомные события для специфики проекта: filter_applied, video_progress, form_step_completed. Кастомные параметры необходимо зарегистрировать в GA4 Admin → Custom definitions, иначе они не будут доступны в отчётах.
Частая ошибка — событие purchase с дублями. Причина: тег срабатывает на странице /thank-you, пользователь обновляет страницу — второй purchase уходит в GA4. Решение: на бэкенде генерируем уникальный transaction_id и передаём в событие. GA4 de-duplicates по нему (в теории — проверяйте через DebugView). Правильная атрибуция экономит до 20 % рекламного бюджета, который раньше уходил на неверно приписанные конверсии.
Как настроить data layer, чтобы не потерять данные?
GTM — инструмент для управления тегами без деплоя кода. Но «без кода» не значит «без архитектуры». Data Layer — основа всего. Передаём данные из приложения в GTM через dataLayer.push(). Структура: event + контекстные данные. Для e-commerce: перед открытием страницы продукта — push с данными товара. GTM-тег читает из dataLayer, не из DOM.
window.dataLayer = window.dataLayer || [];
dataLayer.push({
event: 'view_item',
ecommerce: {
items: [{
item_id: 'SKU-12345',
item_name: 'Название товара',
price: 1990.00,
currency: 'RUB'
}]
}
});
Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-Side для чувствительных данных — отправка с сервера, не с браузера, обходит блокировщики рекламы, не теряет данные.
Как Яндекс.Метрика дополняет веб-аналитику?
Для российской аудитории Метрика обязательна — особенно Вебвизор. Запись сессии пользователя, который бросил корзину, часто даёт ответ быстрее, чем неделя анализа воронки. Цели в Метрике: событийные (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) или автоматические (клик по кнопке, посещение страницы). Связка с CRM через Метрика Плюс — передача офлайн-конверсий. Наш опыт: в 8 из 10 проектов после настройки Метрики находили скрытые баги в UX, которые не показывали другие системы.
Что даёт product analytics в Amplitude?
Amplitude — продуктовый инструмент, в отличие от маркетинговых GA4 и Метрики. Он заточен под анализ поведения пользователей внутри продукта: воронки, ретеншн, user paths. Amplitude подходит для SaaS-продуктов, мобильных приложений и любых сервисов с зарегистрированными пользователями, где важно понять, как проходят онбординг, на каком шаге уходят, какие фичи используют чаще. Ключевые концепции: identify (связать анонимного пользователя с userId после авторизации), group (аккаунт в B2B SaaS), когорты для удержания. Amplitude Chart — воронка шагов за последние 30 дней с разбивкой по источнику.
Мониторинг качества данных
Аналитика без мониторинга — чёрный ящик. Настраиваем:
- GA4 Realtime — проверяем после каждого деплоя, что ключевые события приходят
- Alerting в GA4 — аномалия в количестве событий
purchase (резкое падение = что-то сломалось)
- GTM Preview в staging-окружении перед продакшеном
- Ручные тесты воронок раз в неделю — просто пройти путь покупателя и проверить, что всё трекается
Что проверяем после каждого деплоя
- Все ли рекомендуемые события присутствуют в DebugView
- Нет ли задвоений (считаем количество
purchase на 100 сессий)
- Не изменилась ли структура dataLayer после обновления фронтенда
Что входит в работу
| Компонент |
Описание |
| Аудит текущих тегов |
Проверка существующих GTM-тегов, dataLayer, дублей и ошибок |
| Дизайн событийной схемы |
Документация: список событий, параметры, триггеры |
| Настройка GA4 + GTM |
Создание конфигурации, тегов, Custom definitions |
| Яндекс.Метрика |
Установка счётчика, создание целей, настройка Вебвизора |
| Amplitude (опционально) |
Настройка клиентского и серверного SDK, когорты |
| QA и мониторинг |
Тестирование в Preview Mode, Alerting |
| Обучение и передача |
Доступы, инструкция по добавлению новых событий, консоль |
Процесс и сроки
- Аудит текущих тегов и данных (2 дня)
- Дизайн событийной схемы (2 дня)
- Разработка Data Layer и настройка тегов (3–5 дней)
- QA в Preview Mode и на staging (2 дня)
- Деплой и настройка дашбордов (1 день)
| Сценарий |
Срок |
| Базовая настройка GA4 + GTM |
1 неделя |
| Полный e-commerce tracking + Метрика |
2–3 недели |
| Server-side GTM + Amplitude |
3–5 недель |
Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.
Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.