5 ошибок в настройке екоммерс-событий, которые искажают аналитику

Алена Фролова

Веб-аналитик ArrowMedia

События охватывают не все пользовательские сценарии

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

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

Например, при оформлении заказа в один клик в мобильной версии JavaScript-цель может сработать, а екоммерс-событие – не отправиться. В результате цель фиксируется, но данные о покупках не попадают в екоммерс-отчеты.

Чтобы устранить пробелы, необходимо настроить события во всех предусмотренных на сайте сценариях.

Передается некорректная валюта

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

Другой вариант – один и тот же товар продается в разных валютах в зависимости от региона или способа оплаты, но суммы перед отправкой в Метрику не конвертируются.

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

Дублируется событие purchase

Повторная отправка purchase искусственно завышает количество покупок, доход и конверсию. Товары выглядят более востребованными, а отдельные источники заказов – эффективнее, чем на самом деле. Можно заметить повторяющиеся записи в отчете «Содержимое заказов»: полные копии с одинаковыми transactionId и составом покупки либо заказы с одинаковыми товарами, ценами и количеством, но разными идентификаторами транзакций. Второй вариант обнаружить сложнее, поскольку такие записи выглядят как самостоятельные покупки.

Например, если purchase привязан к посещению страницы «Спасибо» и повторный доступ к ней не заблокирован, событие отправляется при каждом просмотре – после перезагрузки, перехода из истории или закладок.

Также дубли могут появляться, когда purchase привязан к кнопке «Оформить»: если в многошаговой форме она доступна до заполнения всех обязательных полей, каждое нажатие фиксируется в Метрике как новая покупка. Если для каждого события генерируется новый transactionId, одинаковые заказы выглядят как разные.

Чтобы исключить повторную отправку purchase, событие следует привязать к успешной отправке формы заказа. Если дубли совпадают по идентификатору заказа, содержимому и доходу, можно включить опцию «Удаление дублей событий» в настройках счетчика Метрики.

Превышаются лимиты на размер запроса и количество событий

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

В Яндекс Метрике установлены следующие лимиты:

• максимальный размер JSON в одном запросе – 8192 символа;

• количество параметров за визит – 512;

• количество параметров за визит для событий взаимодействия со списком и баннером – 400;

• количество событий за визит – 1000.

Если запрос превышает допустимый размер, событие может быть обрезано или отброшено целиком. Один из характерных сигналов – расхождение между достижениями цели «Ecommerce: Покупка» и количеством покупок. Например, в магазине недорогих товаров корзины могут содержать десятки позиций. При превышении лимита в 8 КБ данные передаются некорректно или не попадают в Метрику. В отдельных случаях цель «Ecommerce: Покупка» фиксируется, а информация о самой покупке отсутствует. Проверить это можно в истории посетителя: достижение цели есть, а данных о покупке нет.

Превышение лимита в 1000 событий проявляется иначе: Метрика разделяет визит на несколько, из-за чего растет количество сессий и может измениться источник покупки. Например, в отчете «Источники заказов» появляются заказы с нетипичным источником – платежным шлюзом. При проверке выясняется, что покупка привязалась не к реальному источнику перехода, а к шлюзу, который оказался последним перед разрывом визита.

Если передается большой объем данных, запросы рекомендуется разбивать на части – например, заказы на подзаказы. Для оценки фактического количества заказов можно настроить JavaScript-цель и передавать ее в Метрику с одним из подзаказов. Также следует контролировать объем отправляемых событий и оптимизировать их количество, чтобы избежать разделения визита на несколько и, как следствие, искажения источника покупки.

На разных этапах воронки передается разный набор данных

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

Например, поле brand может присутствовать при просмотре и добавлении товара, но отсутствовать при покупке. Тогда в статистике по бренду отображаются просмотры, но не покупки, поэтому оценить востребованность товаров в этом разрезе невозможно.

Расхождения возникают и из-за лишних символов. Например, табуляция в названии товара в событии add приводит к тому, что Метрика воспринимает его как другую позицию. Добавления в корзину не связываются с просмотрами и покупками, хотя визуально данные совпадают.

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

Чек-лист для ручной проверки екоммерс-событий

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

1. Подготовка.

• Включить отладку. Добавить к URL параметр _ym_debug=2. Для старого кода счетчика – _ym_debug=1, в этом случае отладка доступна только через консоль.

• Сохранить логи. Включить Preserve log в панели разработчика, чтобы события не исчезали при переходах между страницами.

• Зафиксировать clientID. Сохранить значение cookie _ym_uid, чтобы отделить тестовый визит от остальных и проверить, какие события попали в аналитику.

2. Проверка событий.

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

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