Чтобы настроить ecommerce в Яндекс Метрике, нужно включить электронную коммерцию в параметрах счётчика, указать название контейнера данных и передавать в него сведения о просмотрах товаров, добавлениях в корзину и покупках. После проверки событий Метрика начнёт формировать отчёты по товарам, заказам и выручке.
В статье разобран весь процесс: какие данные подготовить, как связать сайт со счётчиком, какие события отправлять, как проверить покупку и что делать, если заказы не появляются в отчётах. Инструкция подходит для интернет-магазинов, сервисов бронирования и других сайтов, где пользователь оформляет измеримый заказ.
Что требуется для настройки электронной коммерции
Ecommerce в Метрике — это механизм передачи структурированных данных о товарах и заказах. В отличие от обычной цели «Спасибо за заказ», электронная коммерция показывает состав покупки, количество товаров, стоимость, категории, бренды и идентификатор транзакции.
Для настройки понадобятся:
- установленный и работающий счётчик Яндекс Метрики;
- доступ к настройкам счётчика;
- доступ к коду сайта, CMS или системе управления тегами;
- стабильные идентификаторы товаров и заказов;
- понимание структуры каталога, цен, скидок и валюты;
- возможность оформить тестовый заказ.
Перед внедрением определите ответственного за данные. Маркетолог формулирует требования к отчётам, разработчик или специалист по системам управления тегами реализует передачу событий, а аналитик проверяет соответствие заказов данным CMS или CRM.
Настройку можно выполнить через готовый модуль CMS, напрямую в коде сайта или через систему управления тегами. Готовый модуль сокращает объём разработки, но его всё равно необходимо тестировать: расширение может передавать не все поля, использовать внутреннюю цену без скидки или повторно отправлять покупку после обновления страницы.
Шаг 1. Подготовьте карту данных и событий
Сначала зафиксируйте, какие действия пользователей и характеристики товаров должны попадать в Метрику. Если начать сразу с технического внедрения, часть полей часто приходится переименовывать или добавлять после запуска.
Минимальная воронка интернет-магазина включает четыре действия:
- Просмотр карточки товара. Пользователь открыл страницу конкретного товара.
- Добавление в корзину. Товар добавлен с выбранным количеством и вариантом.
- Удаление из корзины. Пользователь убрал товар или уменьшил количество.
- Покупка. Заказ успешно создан, а сайт получил его уникальный идентификатор.
Дополнительно можно передавать показы товаров в списках, клики по карточкам, просмотры внутренних промоблоков и другие поддерживаемые действия. Расширенный набор полезен для анализа каталога, но не должен откладывать запуск основных событий.
| Поле | Что передавать | Требование к данным |
|---|---|---|
| id | Артикул или системный идентификатор товара | Один и тот же товар должен иметь одинаковый ID во всех событиях |
| name | Понятное название товара | Не менять название между корзиной и покупкой без причины |
| price | Фактическую цену единицы товара | Передавать числом, без символа валюты и пробелов |
| quantity | Количество единиц | Передавать числом; для добавления и удаления — изменившееся количество |
| category | Категорию или путь по каталогу | Использовать единую структуру на всём сайте |
| brand | Бренд или производителя | Передавать только при наличии достоверного значения |
| variant | Размер, цвет, тариф или другую модификацию | Значение должно соответствовать выбранному варианту |
| currencyCode | Код валюты, например RUB | Использовать стандартный буквенный код валюты |
Отдельно определите правило расчёта стоимости. Например, будет ли price содержать цену после скидки, а доставка учитываться в общей выручке отдельно. Главное требование — единообразие. Если в корзине передавать цену до скидки, а в покупке после скидки, сравнение этапов воронки станет некорректным.
Идентификатор заказа должен быть уникальным и постоянным. Номер сессии, время покупки или название товара для этой задачи не подходят. При повторном открытии страницы подтверждения сайт не должен создавать новую транзакцию с другим ID.
Шаг 2. Включите ecommerce в настройках Метрики
Откройте нужный счётчик Яндекс Метрики, перейдите в его настройки и активируйте опцию электронной коммерции. В параметрах укажите название JavaScript-контейнера, из которого счётчик будет получать данные. Обычно используется стандартное название dataLayer.
Название необходимо согласовать с технической реализацией. Если в Метрике указан dataLayer, а сайт отправляет объекты в другой массив, события не будут собираться. При нестандартном названии контейнера оно должно полностью совпадать во всех местах, включая регистр символов.
Контейнер желательно создать до загрузки счётчика. Такой порядок снижает риск потери событий, которые происходят сразу после открытия страницы. Особенно это важно для быстрых переходов, одностраничных приложений и событий, инициируемых во время загрузки интерфейса.
После сохранения настроек убедитесь, что счётчик установлен на всех шагах воронки: в каталоге, карточке товара, корзине, оформлении и на странице успешного заказа. Если оформление проходит на другом домене или поддомене, заранее проверьте междоменное отслеживание и сохранение визита при переходе.
Само включение опции ecommerce не создаёт события автоматически. Метрика только начинает слушать указанный контейнер. Сайт, модуль CMS или система управления тегами должны поместить в контейнер объекты установленной структуры.
Шаг 3. Настройте передачу товарных событий
Данные передаются в контейнер в виде объектов ecommerce. Внутри объекта указываются валюта, тип действия и массив products с характеристиками товаров. Синтаксис зависит от способа внедрения, но логика остаётся одинаковой.
Для добавления товара структура должна содержать ecommerce, currencyCode, действие add и массив products. В объекте товара передаются как минимум стабильный идентификатор или название, а для полезной аналитики — также цена и количество. Например, при добавлении двух единиц товара SKU-123 необходимо отправить ID SKU-123, фактическую цену одной единицы и quantity со значением 2.
Событие должно описывать реальное изменение. Если пользователь увеличил количество в корзине с двух до трёх, в add следует передать одну добавленную единицу, а не всё новое количество. Аналогичное правило действует для remove: передаётся количество удалённых единиц.
Основные требования к каждому действию:
- Просмотр товара. Отправляется после открытия полноценной карточки, а не при каждом появлении товарной плитки в каталоге.
- Добавление. Срабатывает после подтверждённого изменения корзины. Если сервер отклонил действие, отправлять событие не нужно.
- Удаление. Учитывает удалённое количество. Полное удаление позиции и уменьшение количества должны обрабатываться корректно.
- Покупка. Отправляется только после успешного создания заказа и получения его ID.
Для покупки используется действие purchase. В actionField указывается уникальный id транзакции, а в products — все приобретённые позиции. Дополнительные поля заказа могут содержать выручку, скидку, налог, доставку или купон, если соответствующие значения доступны и передаются по единому правилу.
Не следует отправлять purchase по нажатию кнопки «Оформить заказ». Платёж или создание заказа могут завершиться ошибкой. Надёжнее формировать событие после ответа серверной части, подтверждающего, что заказ зарегистрирован.
При оплате после оформления возможны две модели учёта. Первая фиксирует все созданные заказы. Вторая отправляет покупку только после подтверждённой оплаты. Выбор зависит от бизнес-модели и должен быть явно отражён в названии показателя и дальнейшей сверке. Метрика не сможет самостоятельно определить, что ранее созданный заказ отменён или возвращён, если сайт не передаёт соответствующие данные другим способом.
Для одностраничных приложений нельзя полагаться только на загрузку HTML-страницы. Просмотр карточки и покупку нужно отправлять при смене состояния интерфейса или после успешного ответа API. Также необходимо исключить повторный запуск одного события при перерисовке компонента.
Шаг 4. Проверьте настройку до запуска
Тестирование нужно проводить на уровне браузера, Метрики и системы заказов. Наличие объекта в контейнере ещё не означает, что в нём правильные значения и что счётчик смог обработать событие.
- Откройте сайт в чистой сессии браузера без блокировщиков рекламы.
- Перейдите из каталога в карточку товара и проверьте событие просмотра.
- Добавьте товар в корзину, измените количество и удалите одну единицу.
- Оформите тестовый заказ с несколькими товарами, скидкой и доставкой, если такие сценарии поддерживаются.
- Проверьте содержимое контейнера через инструменты разработчика или режим предварительного просмотра системы управления тегами.
- Сопоставьте ID, названия, цены, количество и валюту с данными на сайте.
- После обработки данных найдите тестовую транзакцию в ecommerce-отчётах Метрики.
- Обновите страницу успешного заказа и убедитесь, что покупка не отправилась повторно.
Для безопасной проверки можно использовать отдельный тестовый счётчик. Если тест проводится в рабочем счётчике, заказ должен иметь узнаваемый ID, чтобы его можно было учитывать при сверке. Данные Метрики не следует рассматривать как редактируемую базу заказов: ошибочно отправленные события могут повлиять на отчёты.
Особое внимание уделите денежным значениям. Цена должна передаваться числом, десятичный разделитель — в формате, который ожидает техническая схема, а валюта — отдельным кодом. Строка вида «4 990 ₽» не подходит в качестве числового значения.
После технической проверки сравните показатели за полный день или другой сопоставимый период. Сверяйте количество уникальных ID заказов, сумму товарных позиций и распределение по валютам. Небольшие расхождения возможны из-за блокировщиков, запрета аналитических cookies, переходов между устройствами и технических особенностей оплаты. Крупное систематическое отклонение обычно указывает на ошибку внедрения.
Типичные ошибки и способы исправления
| Проблема | Возможная причина | Что проверить |
|---|---|---|
| Отчёты ecommerce пустые | Опция не включена или указано другое имя контейнера | Настройки счётчика, название массива и наличие событий в браузере |
| Есть товары, но нет покупок | Не отправляется purchase или отсутствует ID заказа | Событие после успешного ответа сервера и поле actionField.id |
| Выручка завышена | Покупка отправляется повторно | Обновление страницы подтверждения, возврат из платёжной системы и повторную инициализацию тегов |
| Количество товаров неверно | При изменении корзины передаётся итоговое, а не добавленное или удалённое количество | Логику событий add и remove |
| Цена отличается от заказа | Передаётся базовая цена без скидки или строка с форматированием | Источник price и правило учёта скидок |
| Один товар разделён на несколько строк | Меняется ID между просмотром, корзиной и покупкой | Единый справочник идентификаторов |
| Заказы теряют источник перехода | Переход на другой домен разрывает визит | Междоменное отслеживание, редиректы и возврат из платёжного сервиса |
Ещё одна распространённая ошибка — смешивание данных нескольких систем в одном контейнере без согласованной схемы. Если ecommerce одновременно используют Метрика и другие аналитические инструменты, изменения структуры для одной системы могут нарушить сбор в другой. Перед публикацией нужно проверить, какие именно объекты читает каждый счётчик.
Не стоит считать целью каждое техническое событие только ради дублирования отчёта. Цели полезны для рекламной оптимизации и отдельных сценариев, а ecommerce — для детального анализа товаров и транзакций. Состав целей следует определять исходя из задач, а не из количества доступных действий.
Как использовать ecommerce-данные в аналитике
После настройки можно анализировать не только число заказов, но и эффективность ассортимента. Отчёты помогают находить товары с большим числом просмотров и слабым добавлением в корзину, категории с частыми удалениями, популярные бренды и источники наиболее ценных заказов.
Основные направления анализа:
- конверсия из просмотра карточки в добавление;
- потери между корзиной и покупкой;
- выручка и количество заказов по источникам трафика;
- среднее количество товарных позиций в заказе;
- эффективность категорий, брендов и вариантов товара;
- различия между устройствами, регионами и сегментами аудитории.
Ecommerce-данные особенно полезны при оценке рекламы: количество заявок не показывает реальную ценность заказов с разным составом и стоимостью. Перед масштабированием кампаний стоит проверить корректность атрибуции, разметки и передачи выручки. Эти данные можно использовать при ведении контекстной рекламы, но решения о бюджетах лучше принимать после сверки Метрики с системой заказов.
Метрика не заменяет CMS, CRM или бухгалтерский учёт. Аналитическая система фиксирует действия браузера и связывает их с визитами, поэтому часть заказов может отсутствовать из-за блокировщиков, ограничений согласия на обработку данных или переходов между устройствами. Для управленческой отчётности источником факта заказа остаётся внутренняя система, а Метрика отвечает прежде всего на вопрос, откуда пришёл пользователь и как он взаимодействовал с сайтом.
Частые вопросы
Нужно ли создавать цель на покупку отдельно?
Не обязательно для появления ecommerce-отчётов. Однако отдельная цель может понадобиться для рекламной оптимизации, сегментации или уведомлений. Цель и событие purchase должны срабатывать по одному подтверждённому факту заказа.
Можно ли настроить ecommerce без разработчика?
Да, если CMS предоставляет совместимый и корректно работающий модуль. При нестандартной корзине, одностраничном приложении, нескольких валютах или сложной оплате обычно требуется участие разработчика или специалиста по системам управления тегами.
Через сколько данные появятся в отчётах?
Обработка ecommerce-событий происходит не мгновенно. Сначала проверьте отправку в браузере, затем дождитесь обновления отчётов. Если данные не появились после обычного периода обработки, проверьте структуру события, ID счётчика и название контейнера.
Почему число покупок в Метрике меньше, чем в CMS?
Причинами могут быть блокировщики, отказ от аналитических cookies, закрытие страницы до отправки события, междоменный переход, заказ по телефону или оформление на другом устройстве. Сначала сравните уникальные ID и найдите систематически пропадающий сценарий.
Как понять, что настройка выполнена правильно?
Корректная настройка подтверждается тремя признаками: события появляются в контейнере в нужный момент, поля совпадают с данными сайта, а уникальные заказы и выручка за сопоставимый период близки к данным внутренней системы с учётом известных ограничений веб-аналитики.
