Электронная коммерция в Метрике: какие события нужны для реальной воронки магазина

Сначала выберите одну коммерческую логику

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

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

Я не оптимизирую магазин по событию, которое не может объяснить деньги. Корзина полезна как ранний сигнал, особенно когда покупок пока мало, но она не должна притворяться выручкой. Сначала надо понять, какую ступень воронки измеряет событие, и только потом назначать ему роль в рекламе.

Соберите минимальный набор событий, который объясняет путь товара

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

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

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

Передавайте товар так, чтобы его можно было узнать в отчете

Событие без данных о товаре почти не помогает ассортиментному решению. В документации Яндекс описывает товар как объект, где обязательно передается id или name; также можно передать бренд и категорию. Действия и товары передаются через ecommerce-объекты в контейнере данных, обычно dataLayer. Подробная структура приведена в руководстве по передаче ecommerce-данных.

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

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

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

Не заменяйте покупку страницей «Спасибо»

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

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

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

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

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

Проверьте dataLayer на реальном действии

Электронная коммерция не включается одной галочкой. В настройках счетчика должен быть включен ecommerce и указан контейнер данных; код счетчика должен использовать это же имя контейнера. Затем сайт должен действительно отправлять нужные объекты в момент действия пользователя. Яндекс предлагает проверять эту связку через консоль браузера и содержимое контейнера данных в инструкции по проверке ecommerce.

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

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

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

Используйте отчеты для решения, а не для коллекции графиков

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

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

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

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

Зафиксируйте контрольную версию воронки

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

Дальше порядок работы простой:

1. Выбрать один товарный сценарий и один коммерческий итог.
2. Проверить событие на каждом нужном шаге маршрута.
3. Сверить идентификатор товара, цену и состав заказа между событиями.
4. Отделить диагностические цели от основной покупки для рекламы.
5. Привязать каждый регулярный отчет к конкретному действию команды.

Так ecommerce становится системой принятия решений. Магазин видит не просто «сколько событий пришло», а какой товар и какой источник прошли путь до дохода, где именно исчезает намерение и что нужно проверить раньше следующего увеличения бюджета.