E-commerce события в Метрике: что и как отправлять

E-commerce события превращают обычную статистику в воронку. Вы видите не только визиты, но и то, что человек смотрел, добавлял в корзину и покупал.

Если события настроены наполовину, отчёты выглядят правдоподобно, но решения по ним принимать нельзя. Ниже — что отправлять и где чаще всего ошибаются.

Зачем нужны e-commerce события

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

• Строить воронку от карточки до покупки.
• Сравнивать выручку по каналам.
• Находить товары с высоким интересом и низкой покупкой.
• Оценивать эффект изменений в checkout.
• Связывать рекламу с реальными заказами.

Базовые события

Для интернет-магазина достаточно небольшого набора. Главное — отправлять его стабильно и с одинаковыми параметрами.

Часть отчётов строится на цели purchase. Если она не передаётся или передаётся дважды, выручка в Метрике расходится с CRM.

Параметры, которые нельзя терять

Одинаковые идентификаторы должны использоваться во всех системах. Если в Метрике товар имеет один id, а в CRM другой, сквозная аналитика разваливается.

• id товара или SKU.
• Название товара.
• Цена за единицу.
• Количество.
• Валюта.
• Категория или раздел.
• Идентификатор заказа.
• Способ оплаты и доставки, если нужно.

Как отправить событие

Событие отправляется через JavaScript-вызов Метрики или через dataLayer, если используется Tag Manager. Для purchase лучше дублировать серверной отправкой, чтобы не зависеть от браузера.

• Вызов ym с параметрами ecommerce.
• Передача dataLayer в Tag Manager.
• Серверная отправка purchase.
• Проверка в режиме отладки.
• Логирование ошибок отправки.

Воронка e-commerce

События должны складываться в последовательность. Если человек смотрит товар, но событие detail не отправляется, воронка начинается с пустого места.

• Просмотр каталога.
• Просмотр карточки.
• Добавление в корзину.
• Начало оформления.
• Оплата.
• Покупка.

Между началом оформления и покупкой полезно добавить шаги checkout, если платформа позволяет. Это помогает увидеть, где именно теряются заказы.

Согласованность с CRM и 1С

Метрика показывает поведение, CRM — статусы сделок, 1С — фактическую оплату и отгрузку. Сверять нужно на уровне идентификатора заказа.

• Один номер заказа во всех системах.
• Статусы отмены и возврата.
• Оплата и отгрузка отдельно.
• Источник первого визита.
• Дата и время заказа.

Как проверить отправку

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

Типичные ошибки

• Событие purchase отправляется на каждой странице.
• Нет проверки успешной оплаты.
• Цена передаётся строкой с валютой.
• Количество всегда равно единице.
• События дублируются при обновлении.
• Не учитываются возвраты и отмены.
• Разные id товара в системах.
• События отправляются до согласия пользователя.
• Нет тестового заказа после релиза.

Приватность и согласие

E-commerce события содержат данные о поведении. Если аналитика подключена через consent-режим, события должны отправляться только после согласия или в обезличенном виде.

• Не передавайте email и телефон в параметрах.
• Не отправляйте события до согласия.
• Документируйте состав данных.
• Проверьте настройки хранения.
• Оставьте возможность отключить трекер.

Что смотреть в отчётах

Начните с воронки и расхождения выручки. Если Метрика показывает больше заказов, чем CRM, ищите дубли и тестовые оплаты. Если меньше — проверьте, не теряется ли purchase.

• Конверсия по шагам.
• Выручка и число покупок.
• Средний чек.
• Доля брошенных корзин.
• Расхождение с CRM.
• Товары-лидеры по просмотрам и покупкам.

Чек-лист настройки

Итог

E-commerce события нужны не для красивых графиков, а для решений. Если данные расходятся с заказами, сначала чинят передачу событий, а потом строят дашборды.

События для разных платформ

На Bitrix, OpenCart, Laravel и готовых SaaS набор модулей отличается. Важно не название модуля, а стабильность и одинаковые параметры.

• Готовый модуль e-commerce.
• Собственная отправка через API.
• Tag Manager и dataLayer.
• Серверная отправка purchase.
• Сверка с CRM.
• Логи ошибок отправки.

Как связать события с рекламой

Рекламные системы должны видеть не клики, а заказы. Для этого цели и события передаются в кабинеты, а выручка сверяется с CRM.

• Цель purchase в Метрике.
• Передача целей в рекламные кабинеты.
• UTM и источник заказа.
• Стоимость привлечения.
• Возвраты и отмены.
• Сверка по номеру заказа.

Атрибуция заказов

Пользователь редко покупает в первый визит. Если учитывать только последний клик, часть каналов будет недооценена.

• Первый источник.
• Последний источник.
• Модель с несколькими касаниями.
• Прямые заходы.
• Повторные визиты.
• Офлайн-заказы.

Офлайн и телефонные заказы

Часть заказов приходит по телефону или в мессенджер. Если их не связывать с веб-аналитикой, картина будет неполной.

• Источник звонка.
• Номер заказа.
• Менеджер и дата.
• Сумма и статус.
• Причина обращения.
• Связь с рекламной кампанией.

Регламент после релиза

Любое изменение checkout или каталога может сломать события. Проверка должна быть частью релизного процесса.

Что делать с данными

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

• Еженедельная сверка с CRM.
• Разбор расхождений по заказам.
• Проверка воронки checkout.
• Анализ товаров с высоким интересом.
• Контроль дублей после релиза.
• Обновление целей при изменении сайта.
• Документация по событиям.

Как отлаживать события

Начните с одного тестового заказа. Если он не появился в отчёте, ищите проблему по шагам, а не меняйте весь код сразу.

• Проверьте вызов счётчика.
• Посмотрите параметры в отладке.
• Сравните с документацией.
• Проверьте, нет ли блокировщика.
• Посмотрите серверные логи.
• Сверьте номер заказа с CRM.
• Повторите тест после исправления.

Частые расхождения

Если Метрика показывает больше покупок, чем CRM, скорее всего есть дубли или тестовые оплаты. Если меньше — purchase теряется или отправляется не всегда.

• Дубли purchase.
• Тестовые заказы.
• Возвраты и отмены.
• Оплата без подтверждения.
• Разные часовые пояса.
• Потерянные события на мобильном.
• Заказы вне сайта.

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

Держите короткую документацию по событиям: название, когда отправляется, какие параметры обязательны и кто отвечает за проверку. Это экономит часы при смене подрядчика или платформы.

События и скорость сайта

Тяжёлые счётчики и лишние скрипты замедляют магазин. Аналитика не должна стоить конверсии, особенно на мобильном.

• Асинхронная загрузка.
• Минимум сторонних скриптов.
• Проверка на медленной сети.
• Контроль размера бандла.
• Отложенная загрузка.