Как настроить события и воронки в Google Analytics и Яндекс.Метрика для интернет-магазина

Кому это нужно и что задаём в результате

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

Мы пройдём от подготовки — какие доступы и данные нужны — до проверки результатов. Это не просто набор кликов в интерфейсе: важна дисциплина в наименованиях, согласованность параметров (идентификаторы товаров, суммы, валюта) и тестирование на тестовых заказах. Без этого воронки будут давать искажённые данные.

Если у вас уже есть счётчики GA4 и Яндекс.Метрика, руководство поможет унифицировать события; если нет — мы опишем минимальные шаги по установке счётчиков и контейнеров тегов. Следуйте последовательности: подготовка → реализация → тестирование → запуск → мониторинг.

Что подготовить до настройки

Соберите доступы: администраторские права в Google Analytics (GA4), доступ к аккаунту Google Tag Manager (если используете), логин и права на счётчик Яндекс.Метрики, доступ к коду сайта или к системе управления (1С-Битрикс, WordPress и т.п.). Без правильных прав вы не сможете проверить DebugView/режим отладки и оперативно править теги.

Подготовьте технические данные: схема dataLayer или аналогичного объекта, в котором передаются параметры товаров (product_id, name, price, quantity, currency, transaction_id). Для корректных воронок критично, чтобы transaction_id был уникален и передавался в момент успешной оплаты.

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

• Доступы: GA4, GTM, Яндекс.Метрика, FTP/панель сайта
• dataLayer: образец JSON с товарами и транзакцией
• Список URL/условий для шагов воронки

Проектирование событий и стандартная таксономия

Прежде чем внедрять теги, пропишите «таксономию» — список событий и параметров, которые вы будете отправлять в оба сервиса. Используйте понятные короткие названия: например view_item, add_to_cart, begin_checkout, purchase; для Яндекс.Метрики используйте человекочитаемые имена целей. Важно, чтобы смысл событий был одинаковым в обеих системах.

Для каждого события укажите обязательные параметры: идентификатор товара (product_id), цену (price), количество (quantity), currency и transaction_id для покупок. Отдельно опишите пользовательские параметры, которые вам нужны для сегментации — источник, промокод, тип доставки. Эта документация — основной артефакт при тестировании и передаче правкам.

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

• Пример обязательных событий: view_item, add_to_cart, begin_checkout, purchase
• Параметры: product_id, price, quantity, currency, transaction_id
• Дополнительно: promo_code, shipping_type, user_id (если есть)

Реализация в Google Tag Manager и GA4 — последовательность действий

Реализация через Google Tag Manager упрощает поддержку: один контейнер управляет отправкой событий в GA4. Последовательность работ выглядит так: 1) подготовка dataLayer и проверка на тестовой странице; 2) создание переменных в GTM для параметров из dataLayer; 3) настройка триггеров (например, событие dataLayer 'add_to_cart' или просмотр страницы с определённым URL); 4) создание тега GA4 Event и привязка переменных; 5) тест в режиме предварительного просмотра; 6) публикация контейнера.

В GA4 после поступления событий отметьте ключевые события как конверсии (Conversions). Для воронок используйте отчёты «Исследования» → воронка (Explorations → Funnel), где можно задать последовательность шагов на основе приходящих событий или представлений страниц. Убедитесь, что времена ожидания и настройки включают корректное окно конверсии.

Не забывайте включать debug-режим: для GA4 используйте DebugView (в реальном времени будут видны события с вашего браузера), а в GTM — режим предварительного просмотра. Записи в DebugView позволят увидеть, какие параметры доходят до GA4 и в каком формате, и быстро исправить ошибки в триггерах или переменных.

Настройка событий и целей в Яндекс.Метрике

В Яндекс.Метрике есть два основных подхода: установка счётчика и отправка событий через hit/goal или использование Яндекс.Тега/Manager. Для ecommerce чаще применяют отправку целей reachGoal по событиям из dataLayer: например ym('reachGoal', 'add_to_cart', {id:..., price:...}). Альтернативно, можно настроить счётчик так, чтобы фиксировать шаги по URL страниц подтверждения этапа.

Цели в Метрике можно делать двух типов: «событие» (по вызову reachGoal) и «визит по URL». Для воронок используйте отчёт «Цели → Конструктор целей» или «Воронки» внутри отчёта, задавая последовательность шагов. Убедитесь, что для события покупки передаётся уникальный номер заказа: это позволит анализировать глубину конверсии и устранить дубли.

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

Контрольные точки перед публикацией (чек-лист)

Перед публикацией изменений проверьте базовые контрольные точки: корректность dataLayer (структура и названия полей), наличие transaction_id для покупки, одинаковые единицы измерения цен и валюта, правильные триггеры и отсутствие конфликтов между старыми и новыми тегами. Без этих проверок данные в воронках могут оказаться некорректными.

Используйте чек-лист, который пройдёт разработчик и аналитик: 1) все события приходят в DebugView/Preview; 2) параметры приходят с ожидаемыми значениями; 3) нет дублирующихся событий при одном действии; 4) тестовые транзакции отображаются и в GA4, и в Яндекс.Метрике; 5) фильтрация внутреннего трафика настроена корректно. Не публикуйте изменения до прохождения всех пунктов.

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

• Проверка dataLayer на нескольких страницах
• DebugView в GA4 и предварительный просмотр в GTM
• reachGoal в Яндекс.Метрике с передачей transaction_id
• Отсутствие дублирования событий
• Сопоставление тестовой транзакции в обеих системах

Тестирование: сценарии и инструменты

Тестирование должно покрывать все критичные пути: просмотр товара, добавление в корзину, изменение количества, оформление заказа и успешная оплата. Для каждого сценария выполните набор тест-кейсов: с промокодом/без, разной валютой, разным количеством товаров, возвратом/ошибкой платежа. Зафиксируйте ожидаемые значения параметров для каждой проверки.

Инструменты: режим предварительного просмотра GTM, DebugView в GA4, консоль Яндекс.Метрики (проверка reachGoal в консоли), Network в DevTools (проверка запросов collect/gtm и ym). Также используйте реальные тестовые заказы в песочнице платёжного шлюза или симуляции callback, чтобы убедиться, что transaction_id поступает после успешной оплаты.

Идея тестирования — не только увидеть события, но и проверить их полноту и непротиворечивость. Проведите параллельную проверку: данные в интерфейсах аналитики против серверных логов или export'а заказов. Это выявит проблемы с округлениями, несоответствием валют и потерей параметров на стороне фронтенда.

Запуск и первичный мониторинг после публикации

После публикации тега публикуйте поэтапно: сначала частичное развертывание (например, 5–10% трафика или только тестовые пользователи), наблюдайте DebugView и отчёты в реальном времени. Это снижает риск широкого распространения ошибок и даёт возможность быстро откатить изменения при необходимости.

В первые дни запуска следите за метриками совпадения: число событий add_to_cart и просмотров карточек, коэффициенты конверсии между шагами, количество транзакций и средний чек. При больших расхождениях между GA4 и Яндекс.Метрикой проверьте фильтрацию трафика, настройки конверсий и момент отправки transaction_id (иногда он приходит до подтверждения оплаты и затем не обновляется).

Настройте простые оповещения или сводные дашборды, чтобы видеть аномалии: резкий спад/рост событий, пропадающие транзакции или массовые 400/500 ошибки при отправке тега. Быстрая реакция на изменения важнее идеального набора показателей в день запуска.

Распространённые ошибки и способы их устранения

Дублирование событий. Часто встречается, когда тег срабатывает и на самом событии JavaScript, и в GTM. Решение: стандартизируйте канал отправки (либо GTM, либо ручной вызов), используйте флаги в dataLayer и проверяйте уникальность события по transaction_id.

Неполные или неверные параметры. Это приводит к некорректной агрегации по товарам и суммам. Проверяйте структуру dataLayer на всех типах страниц, следите за типами данных (числа vs строки) и обязательно тестируйте граничные случаи: null, пустые строки, специальные символы в названиях товаров.

Фильтрация тестового трафика и проблемы с согласиями пользователей. Если у вас есть модуль согласия (cookie banner), события могут блокироваться до подтверждения согласия. Планируйте описывать поведение при отказе от cookie и предусматривать серверные измерения или поставку агрегированных данных для корректного анализа.

Документация и передача в сопровождение

Составьте краткую техническую документацию: список событий, их названия и назначение, описание передаваемых параметров, примеры dataLayer для каждого сценария, список используемых триггеров и переменных в GTM, а также инструкции по откату. Это сократит время на обслуживание и последующие правки.

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

Планируйте ревью через 1–2 недели после запуска: сравнение данных с бизнес-источниками (CRM/1С/биллинг), корректировка параметров и расширение трекинга для сегментации рекламных каналов и A/B-тестов.

Частые вопросы