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

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

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

Продвижение интернет-магазинаот 60 000 до 150 000 ₽/мессроки: 4-8 месяцев

Как устроена настройка электронной коммерции в Яндекс.Метрике

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

window.dataLayer = window.dataLayer || [];

Дальше каждое действие покупателя превращается в push с объектом ecommerce. Внутри ровно одно действие: detail, add, remove или purchase.

window.dataLayer.push({
  ecommerce: {
    currencyCode: 'RUB',
    add: {
      products: [
        {
          id: 'SKU-771',
          name: 'Кресло Ergo Lite',
          price: 12450,
          brand: 'Ergo',
          category: 'Кресла/Офисные',
          variant: 'Серый',
          quantity: 2
        }
      ]
    }
  }
});

Обязательным по факту является id или name, но отчёты без остального будут пустыми. id должен совпадать с артикулом в вашей учётной системе, иначе сверить продажи не получится. price передаётся за одну единицу, а не за позицию: количество лежит отдельно в quantity. Категорию удобно писать через слэш, тогда в отчёте появляется вложенность.

Событие покупки отличается тем, что к товарам добавляется описание заказа:

window.dataLayer.push({
  ecommerce: {
    currencyCode: 'RUB',
    purchase: {
      actionField: {
        id: '10432',
        revenue: 24900,
        coupon: 'AUG10'
      },
      products: [ /* те же поля товаров */ ]
    }
  }
});

actionField.id это номер заказа. Он же дальше становится ключом защиты от дублей, о которой ниже.

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

Событие	Когда	Что показывает
`detail`	Открыта карточка товара	Какие товары смотрят, но не берут
`add`	Товар положили в корзину	Где рвётся путь между интересом и оформлением
`remove`	Товар убрали из корзины	Сомнения на этапе оформления, часто из-за доставки
`purchase`	Заказ подтверждён сервером	Выручка, средний чек, состав заказа

Есть ещё показы товаров в списках, но на средних каталогах я их обычно не включаю: объём данных большой, а выводы из него делают редко.

Почему purchase нельзя вешать на кнопку

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

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

Правильный момент один: сервер подтвердил заказ. Дальше есть два сценария.

Оплата на сайте картой. Заказ считается состоявшимся, когда платёжная система прислала вебхук об успешной оплате. Страница «спасибо» отдаётся бэкендом уже с готовым объектом заказа, и purchase уходит из этого объекта, а не из данных корзины в браузере.

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

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

Дубли purchase и как от них закрыться

Страница «спасибо» перезагружается чаще, чем кажется. Человек обновляет её, чтобы убедиться, что заказ прошёл. Возвращается по кнопке «назад». Открывает ссылку из письма о подтверждении. Каждый такой заход отправляет purchase заново, и один заказ на 24 900 ₽ превращается в отчёте в три заказа на 74 700 ₽.

Ловится это по одному признаку: средний чек в Метрике заметно выше, чем в учётной системе, а число заказов кратно больше.

Защита строится вокруг номера заказа, и лучше поставить оба уровня:

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

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

Схема связей

Путь от действия покупателя до решения по бюджету

Что происходит с событием магазина между кликом и отчётом, из которого вы принимаете решение.

Действие покупателя

Открыл карточку Событие detail
Положил в корзину Событие add с количеством
Убрал из корзины Событие remove, часто после расчёта доставки
Оплатил заказ Событие purchase, только после подтверждения

dataLayer

Объявлен до счётчика Иначе первые события теряются
Одно действие на push detail, add, remove или purchase
currencyCode Одна валюта на весь сайт
actionField.id Номер заказа, ключ защиты от дублей

Метрика

Заказы и выручка Сумма, средний чек, состав
Товары и категории Просмотры, добавления, покупки
Источники с деньгами Выручка в разрезе каналов и запросов
Связка с Директом Расходы подтягиваются автоматически

Отчёты и решения

Какой канал окупается Выручка против расхода, а не заказы
Что смотрят и не берут Высокий detail при низком add
Где теряется корзина Массовый remove после блока доставки
Какие категории двигать Приоритет для семантики и посадочных

Отчёты, ради которых всё это делается

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

Заказы. Список заказов с суммой и составом. Полезен в первую неделю после настройки: вы просто сверяете его с учётной системой строчка в строчку.

Источники с выручкой. Тот самый отчёт, ради которого затевалось. Каналы сортируются не по трафику и не по числу заказов, а по деньгам. Расклад почти всегда отличается от ожидаемого: канал с половиной заказов часто даёт четверть выручки.

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

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

Валюта, НДС и доставка

Три места, где данные расходятся с бухгалтерией, и все три решаются договорённостью на старте.

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

НДС. Определитесь, передаёте вы суммы с налогом или без, и запишите это решение в документации проекта. Обе схемы рабочие, нерабочая только третья: когда карточки отдают цену с НДС, а revenue считается без него. Расхождение будет ровно на ставку, и искать его будут долго.

Доставка. Входит ли она в revenue, решаете вы. Я обычно не включаю: тогда выручка в отчёте это деньги за товар, и её проще сравнивать с закупкой. Главное, чтобы правило было одно для всех заказов.

Что делать с возвратами

Электронная коммерция не умеет отрицательные заказы. Отправить purchase с минусом нельзя, и отменённый заказ так и останется в отчётах выручкой.

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

Третий вариант требует работы на стороне бэкенда, но только он даёт отчёт, которому можно верить без оговорок.

С чего начать

Порядок работ такой: объявить массив данных, повесить четыре события, оформить два тестовых заказа, свести их с учётной системой до рубля, поставить защиту от дублей и только потом связывать счётчик с Директом. Если начать со связки, реклама будет оптимизироваться по задвоенной выручке.

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