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

Обычная цель в Яндекс Метрике фиксирует факт: посетитель нажал кнопку, дошёл до страницы «Спасибо за заказ», заполнил форму. Для интернет-магазина этого мало. Нужно знать, какие именно товары купили, на какую сумму и по какой цене. Иначе отчёты о рекламе не свяжутся с реальной выручкой.

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

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

Что такое электронная коммерция в Яндекс Метрике

Модуль «Электронная коммерция» передаёт товарные действия через JavaScript-массив window.dataLayer: просмотр списка или карточки товара, клик по товару, добавление и удаление из корзины, покупку, а также действия с внутренней рекламой. Он не заменяет обычные цели; для покупки Метрика может создавать отдельную цель. Стандартного действия «начало оформления заказа» в этом списке нет.

По логике модуль похож на Enhanced Ecommerce из Google Analytics: Яндекс изначально делал совместимость с этой структурой, чтобы сайтам, где Enhanced Ecommerce уже настроен, не приходилось переписывать код заново. Перед настройкой стоит свериться с актуальной справкой Яндекса: формат полей и список поддерживаемых событий может обновляться, а разбираемая ниже структура — рабочий пример логики, не финальная спецификация.

Чем цель электронной коммерции отличается от обычной цели

Обычная цель в Метрике — это одно событие: переход на URL, клик по кнопке, отправка формы, JavaScript-событие. Такая цель отвечает на вопрос «дошёл или не дошёл». Она хорошо работает для лендинга-одностраничника или сайта услуг, где важен один факт конверсии, а не состав заказа. Подробнее логика таких целей разобрана в статье про аналитику лендинга.

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

Как устроена структура данных для целей электронной коммерции

Данные передаются через JavaScript-массив window.dataLayer. Сайт добавляет в него объекты с типом действия и описанием товаров: идентификатором или названием, ценой и количеством при необходимости. Имя контейнера должно совпадать с настройкой счётчика.

Ниже упрощённый иллюстративный пример того, как может выглядеть запись о покупке. Это не готовый код для копирования, а демонстрация логики: у реальной настройки структура полей должна проверяться по актуальной документации Яндекса.

Событие purchase отправляйте в тот момент, который магазин определил как регистрацию покупки или заказа, с уникальным ID. Зафиксируйте это определение и сопоставляйте с CRM; отображение страницы «Спасибо» само по себе ещё не подтверждает оплату.

Метрика поддерживает стандартные действия detail, add, remove и purchase, а также показы и клики по товарам и внутренним промо. Если нужен отдельный шаг начала оформления, его отслеживают другой согласованной целью: в перечне Ecommerce-действий такого шага нет.

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

Где чаще всего ошибаются при настройке электронной коммерции

При настройке стоит проверить несколько типовых технических рисков:

• Неверно задан или недоступен контейнер dataLayer. Проверьте, что массив существует в глобальном window, его имя совпадает с настройкой счётчика и Ecommerce-объекты отправляются после инициализации массива.
• ID товара не совпадает с ID в фиде. Если для рекламы используется товарный фид, а идентификаторы в ecommerce-модуле отличаются, отчёты по товарам и по рекламным кампаниям невозможно сопоставить друг с другом.
• Purchase срабатывает несколько раз. Классическая ошибка: событие покупки привязано к загрузке страницы «Спасибо за заказ», и при обновлении страницы или возврате на неё браузером покупка засчитывается повторно.
• Цена передаётся без скидки или с ней, но непоследовательно. Если на одном шаге воронки цена указана с учётом промокода, а на другом без, сумма revenue в отчётах не будет совпадать с реальной выручкой.
• Валюта не учтена. Для мультивалютных магазинов забытая конвертация в единую валюту искажает суммарную выручку в отчётах.
• Тестовые заказы попадают в статистику. Проверка работы модуля прямо на продуктовом сайте без фильтрации тестовых транзакций засоряет отчёты и требует ручной чистки данных.

Каждая из этих ошибок сама по себе не критична, но их совокупность делает отчёты по продажам непригодными для принятия решений. Проверка на «здравый смысл», сопоставление суммы revenue за месяц из Метрики с данными из CRM или платёжной системы, быстро выявляет большинство перечисленных проблем.

Как проверить, что данные передаются корректно

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

После запуска проверьте событие в браузере и отчёте, а затем настройте повторную сверку с учётной системой после изменений сайта. Частота зависит от объёма заказов и скорости выпуска изменений.

Что делать с данными после настройки

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

• Сравнение конверсии в покупку по разным источникам трафика позволяет перераспределять бюджет в пользу каналов с более высоким качеством аудитории, а не только с низкой ценой клика.
• Высокая доля добавлений в корзину без покупки — повод проверить цену, наличие, доставку и техническую работу оформления. Из отчёта причина не следует автоматически.
• Оценка среднего чека и его динамики по сегментам аудитории помогает точнее планировать акции и спецпредложения.
• Построение отчёта по ассоциированным конверсиям показывает вклад каждого канала в цепочку до покупки, а не только последнего клика.

Если данные о заказах не связаны с более широкой картиной трафика, полезно посмотреть, как сравнивать каналы трафика между собой по единой методике, а также изучить, как влияет модель Data-Driven атрибуции по сравнению с Last Click на распределение заслуг между источниками. Это особенно важно, если бюджет распределяется между несколькими рекламными каналами одновременно.

Электронная коммерция и анализ воронки продаж

Настроенный модуль электронной коммерции — фундамент для более глубокого анализа воронки конверсии сайта. Данные о просмотрах, добавлениях в корзину и покупках складываются в отчёт «Электронная торговля» и показывают, на каком шаге теряется больше всего потенциальных клиентов.

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

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

Как сверять покупки с учётной системой

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

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

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

Проверку выполняйте последовательно: сначала запись в dataLayer в браузере, затем передача счётчиком, затем появление данных в отчёте после обработки и только потом сверка с CRM. Если запись есть в массиве, но не приходит в отчёт, проверьте имя контейнера и настройку электронной коммерции в счётчике. Если запись доходит, но сумма неверна, ищите ошибку в составе товаров, цене или определении события purchase.

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

Частые вопросы о настройке электронной коммерции в Яндекс Метрике