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

Одна некорректность в сборе данных может в корне поменять статистику. Какие аномалии в отчетах Yandex Метрики указывают на делему, также чек-лист для самостоятельной проверки – в материале Алены Фроловой, веб-аналитика ArrowMedia.

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

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

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

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

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

Передается неправильная валюта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На различных шагах воронки передается различный набор данных

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

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

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

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

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

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

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

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

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

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

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

Событие	Где проверить	На что направить внимание
Просмотр перечня продуктов / impressions	Сборники, брендовые и акционные странички, рекомендательные полки	Размер запроса
Клик по товару из перечня / click	Клики по товару из всех списков	Событие срабатывает во всех точках; передается позиция продукта в index
Просмотр карточки продукта / detail	Карточка, резвый просмотр, переключение цвета и размера	Событие срабатывает при любом методе просмотра
Добавление продукта в корзину / add	Добавление из карточки, каталога и резвого просмотра; «+» и ручное изменение количества в корзине	Событие срабатывает при всех методах прибавления; в quantity передается добавленное, а не итоговое количество
Удаление продукта из корзины / remove	«−», удаление позиции и ручное изменение количества	Событие срабатывает при всех методах удаления; в quantity передается удаленное количество, а не остаток
Покупка / purchase	Удачная отправка формы, покупка в один клик	Событие срабатывает лишь опосля удачной отправки формы и не повторяется при перезагрузке странички «Спасибо»; в actionField.id передается неповторимый номер заказа

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

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