Электронная коммерция в Яндекс Метрике: события и проверка заказов

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

До внедрения определите, что ваш магазин считает покупкой: оформленный заказ или заказ с подтверждённой оплатой. Метрика не узнаёт банковский статус из названия события purchase; она обрабатывает то, что отправил сайт. От этого решения зависит смысл дохода в отчёте и возможность сравнить его с системой учёта.

Что Ecommerce добавляет к обычным целям

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

Но Ecommerce не заменяет учёт прибыли. В переданном доходе нет автоматически рассчитанной себестоимости, рекламных расходов и итогов возвратов. Как объединять показатели магазина для управленческих решений, разобрано в статье об аналитике интернет-магазина. Здесь задача уже: добиться правильной передачи и проверить её на одном понятном заказе.

Подготовьте счётчик и способ передачи

Проверьте, что нужный счётчик установлен и работает на карточке, корзине и странице подтверждения. В его настройках включите «Электронную коммерцию», сохраните изменения и проверьте актуальный код на сайте. По умолчанию контейнер данных называется dataLayer; если используете другое имя, оно должно совпадать в настройках и коде.

Дальше выберите один согласованный способ передачи. Для некоторых CMS доступны официальные модули; в конструкторе может быть собственная интеграция. Проверьте, какие события она уже отправляет. Если параллельно добавить ручной обработчик, один заказ может уйти дважды.

Ниже разобрана ручная схема с detail, add, remove и purchase. Метрика поддерживает и другие форматы, в том числе совместимую схему Google Analytics 4; не смешивайте имена и вложенность разных схем внутри одного примера. Автосбор событий и его цели также проверяйте отдельно: найденная цель не доказывает, что передан полный состав заказа.

Когда отправлять товарные события

Сначала составьте таблицу «действие покупателя — событие — данные». Одинаковый товар должен иметь стабильный идентификатор на всех этапах. Если в карточке он называется одним ID, а в покупке другим, сопоставлять его путь будет сложнее.

Действие	Событие ручной схемы	Что должно произойти на сайте
Просмотр карточки	detail	Показаны данные текущего товара или выбранного варианта
Добавление товара	add	Корзина действительно приняла указанное количество
Удаление товара	remove	Из корзины действительно убрано указанное количество
Подтверждение заказа по принятому правилу	purchase	Система магазина подтвердила выбранное бизнес-событие и сформировала ID заказа

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

У товара обязателен хотя бы один параметр id или name; для сопоставления удобнее передавать оба. Цена относится к одной единице, а количество показывает, сколько единиц добавили, удалили или заказали в данном событии. При выборе вариантов используйте согласованные ID и поле variant, чтобы покупка нужного размера не потерялась среди данных общей модели.

Пример просмотра карточки

Учебный товар — термос с артикулом THERMOS-500-BLUE, цена 2 000 ₽. Пример предполагает, что счётчик читает dataLayer. Код вызывается при реальном показе карточки; значения должны поступать из каталога, а не оставаться одинаковыми для всех страниц.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  ecommerce: {
    currencyCode: "RUB",
    detail: {
      products: [{
        id: "THERMOS-500-BLUE",
        name: "Синий термос, 500 мл",
        price: 2000,
        variant: "синий"
      }]
    }
  }
});

Для добавления в этой схеме вместо detail используют add, для удаления — remove, а в товарной строке передают quantity с числом добавленных или удалённых единиц. Вызывайте каждый объект после успешного изменения корзины. Отдельно протестируйте быстрое повторное нажатие и изменение количества: один пользовательский результат не должен создавать несколько одинаковых сообщений.

remove относится только к корзине. Оно не означает возврат денег, отказ после доставки или отмену уже оформленного заказа. Для покупки нужна другая структура с actionField.

Какой момент считать покупкой

Если purchase отправляется после оформления заказа, отчёт будет показывать оформленные заказы, в том числе те, которые позже не оплатят. Это допустимая схема, когда именно такой этап нужен для анализа, но её доход нельзя без сверки назвать выручкой от завершённых продаж.

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

Есть и обратная проблема: покупатель оплатил, но закрыл банковскую страницу и не вернулся на сайт. Событие, которое существует только на странице «Спасибо», может потеряться. Разберите этот сценарий с разработчиком и сверяйте результат с данными платёжной системы и учёта. Браузерное событие не обеспечивает полного совпадения с учётом всех оплат, поэтому его нельзя использовать как единственный реестр платежей.

Как передать заказ со скидкой и доставкой

Для purchase обязателен actionField.id — идентификатор покупки. Используйте ID из системы заказов, а не случайный номер при каждом открытии страницы. В products передайте фактически заказанные позиции, их цену и количество; валюта задаётся через currencyCode, для рублей — RUB.

Доход можно указать явно в actionField.revenue. Если его не передать, Метрика рассчитывает его по товарным строкам. Яндекс рекомендует передавать стоимость, которую действительно платит покупатель: отдельное поле скидки не уменьшает цену автоматически.

Разберём учебный заказ. В нём один рюкзак со скидкой и один термос; доставка платная. Это условные данные для проверки, не реальные цены или кейс магазина.

Часть заказа	Расчёт	Сумма
Рюкзак	5 000 − 500 ₽ скидки, 1 штука	4 500 ₽
Термос	2 000 ₽, 1 штука	2 000 ₽
Товары после скидки	4 500 + 2 000	6 500 ₽
Доставка	Отдельная услуга по условиям примера	300 ₽
Сумма к оплате	6 500 + 300	6 800 ₽

Для этого теста примем правило: в доходе Метрики учитываем товары после скидки, без доставки. Поэтому revenue равен 6 500, хотя покупатель платит 6 800. В базовой схеме нет отдельного поля shipping; не рассчитывайте, что счётчик сам выделит доставку из общей суммы.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  ecommerce: {
    currencyCode: "RUB",
    purchase: {
      actionField: {
        id: "TEST-1042",
        revenue: 6500,
        coupon: "BAG500"
      },
      products: [
        {
          id: "BAG-GREEN",
          name: "Зелёный рюкзак",
          price: 4500,
          discount: 500,
          quantity: 1
        },
        {
          id: "THERMOS-500-BLUE",
          name: "Синий термос, 500 мл",
          price: 2000,
          quantity: 1
        }
      ]
    }
  }
});

Цена рюкзака уже уменьшена на скидку; вычитать 500 ₽ ещё раз из revenue нельзя. В примере одна единица со скидкой, поэтому размер скидки не требует распределения между несколькими экземплярами. Для скидки на весь заказ заранее распределите итог по строкам по правилу своей системы и проверьте округление, чтобы сумма товаров совпадала с принятым доходом.

Можно выбрать другое правило и включать доставку в переданный доход. Тогда в этом же тесте revenue будет 6 800, а сумма товарных строк останется 6 500; разницу нужно объяснять при сверке отчётов. Не меняйте определение дохода незаметно между заказами и интеграциями, иначе сравнение периодов потеряет смысл.

Не передавайте в товарных полях имя покупателя, телефон, email или адрес доставки. Для этой схемы достаточно технического ID заказа, данных товаров и денежных значений. Идентификатор не должен содержать контактные данные.

Как избежать повторного учёта покупки

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

В дополнительных настройках счётчика есть опция удаления дублей событий «еком-покупка» в разных визитах. По справке Яндекса она работает при совпадении пользователя, суммы и идентификатора покупки. Проверьте, включена ли она, и не рассчитывайте на её действие, если номер меняется, доход передаётся по разным правилам или посетитель определяется иначе.

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

Контрольный заказ: от отладчика до отчёта

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

1. Откройте сайт с параметром _ym_debug=2 для нового кода счётчика. Если в URL уже есть параметры, добавьте его через &, иначе через ?. Для предыдущего кода справка описывает _ym_debug=1 и проверку сообщений в консоли.
2. В панели отладки проверьте нужный счётчик и вкладку Ecommerce. Откройте карточку, добавьте и удалите товар: события должны соответствовать действиям и количеству.
3. Оформите учебный заказ из примера и доведите его до выбранного статуса. Проверьте purchase: ID TEST-1042, два товара по одной штуке, цены 4 500 и 2 000, доход 6 500 RUB.
4. Обновите страницу подтверждения, вернитесь назад и повторно откройте её. Проверьте, нет ли лишнего вызова; отдельно протестируйте возврат из платёжной формы.
5. После обработки данных откройте отчёт «Содержимое заказов», выберите соответствующий период и RUB. Найдите контрольный ID и сравните состав, количество и доход с системой магазина. После первой передачи появление данных может занять несколько часов.

Что сверяем в учебном тесте	Ожидаемый результат
Заказ в системе магазина	Две позиции, товары 6 500 ₽, доставка 300 ₽, к оплате 6 800 ₽
Объект purchase	Тот же ID и состав; revenue: 6500 по правилу без доставки
Отчёт Метрики	Заказ и суммы согласуются с отправленными данными в выбранной валюте
Платёжный статус	Соответствует принятому моменту отправки, проверяется по системе магазина
Повторный вход на подтверждение	Проверена логика отправки и условия удаления дублей

Разница 300 ₽ здесь объясняется выбранным учётом доставки. Разница 500 ₽ может указывать на повторное вычитание скидки или отправку исходной цены. Удвоение суммы требует проверки повторных сообщений. Такая сверка полезнее, чем правило «несколько процентов расхождения — нормально» без выяснения причин.

Какие отчёты читать после проверки

Отчётам нужны определённые события. Если передаётся только покупка, отсутствие данных о просмотре не означает, что товар никто не видел. Оно может означать, что сайт не отправляет detail.

Вопрос	Отчёт	Нужные события ручной схемы
Что входит в конкретный заказ?	«Содержимое заказов»	purchase
Какие товары заказывают?	«Заказанные товары»	purchase
Откуда приходят покупатели?	«Источники заказов»	purchase и данные визитов счётчика
Что добавляют и убирают?	«Товары в корзине»	add, remove

Для анализа интереса к товару дополнительно передавайте просмотры. Если товар часто добавляют, но редко заказывают, проверьте путь до оформления и условия покупки; полезный порядок разбора есть в статье о брошенных корзинах. Само различие показателей не доказывает конкретную причину ухода.

Почему данные не сходятся или не появляются

Сначала проверьте вызов события, имя контейнера и структуру объекта. Затем — нужный счётчик, обязательные поля и фактический запрос. Частые технические причины: ошибка JavaScript, пустой список товаров, отсутствие actionField.id, блокировщик счётчика или уход со страницы до передачи. Справка также ограничивает размер передаваемых Ecommerce-данных 8 192 символами; особенно внимательно проверяйте большие корзины.

Если объект отправлен, но отчёт пуст, дождитесь обработки и проверьте период, валюту и фильтры. При сравнении с учётом учитывайте выбранный момент покупки, часовой пояс и тестовые заказы. Сравнение всех оформленных заказов в CMS только с оплаченными событиями в Метрике изначально сопоставляет разные группы.

Отмена или возврат после purchase не исправляют этот браузерный объект автоматически. В рассмотренной ручной схеме не документировано отдельное событие refund; remove относится к корзине. Не используйте отрицательную покупку как непроверенный способ вычесть возврат. Итоговые продажи и возвраты сверяйте с системой учёта.

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

Нужно ли отдельно создавать цель покупки после настройки Ecommerce?+

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

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

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