Алена Фролова Веб-аналитик ArrowMedia Одна неточность в сборе данных может в корне изменить статистику. Какие аномалии в отчетах Яндекс Метрики указывают на проблему, а также чек-лист для самостоятельной проверки — в материале Алены Фроловой, веб-аналитика ArrowMedia.
События охватывают не все пользовательские сценарии
Если фиксируется только часть действий, в воронке появляются разрывы, а данные о покупках и эффективности рекламных каналов искажаются. На проблему указывают противоречия в отчетах: например, покупок оказывается больше, чем добавлений в корзину, количество добавленных товаров принимает отрицательные значения, а по отдельным вариантам товара могут отсутствовать просмотры при наличии добавлений в корзину.
Такое происходит, если событие detail передается только при открытии карточки и не срабатывает при переключении между цветами или размерами. Похожая ситуация возникает при расхождении между достижениями jаvascript-целей и покупками в e-commerce-отчетах.
Например, при оформлении заказа в один клик в мобильной версии jаvascript-цель может сработать, а e-commerce-событие — не отправиться. В результате цель фиксируется, но данные о покупках не попадают в e-commerce-отчеты.
Чтобы устранить пробелы, необходимо настроить события во всех предусмотренных на сайте сценариях.
Передается некорректная валюта
Расхождения денежных показателей в Метрике с фактическими данными могут привести к неверной оценке рекламных каналов и отдельных позиций. Одна из причин — несовпадение валюты в настройках счетчика и e-commerce-событиях. Например, магазин использует отдельные домены для разных стран на едином шаблоне, при этом валюта счетчика соответствует стране, но события не адаптированы под нее.
Другой вариант — один и тот же товар продается в разных валютах в зависимости от региона или способа оплаты, но суммы перед отправкой в Метрику не конвертируются.
Метрика учитывает currencyCode события и валюту счетчика. Если они различаются, сумма в отчете пересчитывается по текущему курсу, что может привести к искажению денежных показателей. Чтобы этого избежать, необходимо передавать валюту, соответствующую настройкам счетчика, либо конвертировать данные о доходе перед отправкой в аналитику.
Дублируется событие purchase
Повторная отправка purchase искусственно завышает количество покупок, доход и конверсию. Товары выглядят более востребованными, а отдельные источники заказов — эффективнее, чем на самом деле. Можно заметить повторяющиеся записи в отчете "Содержимое заказов": полные копии с одинаковыми transactionId и составом покупки либо заказы с одинаковыми товарами, ценами и количеством, но разными идентификаторами транзакций. Второй вариант обнаружить сложнее, поскольку такие записи выглядят как самостоятельные покупки.
Например, если purchase привязан к посещению страницы "Спасибо" и повторный доступ к ней не заблокирован, событие отправляется при каждом просмотре — после перезагрузки, перехода из истории или закладок.
Также дубли могут появляться, когда purchase привязан к кнопке "Оформить": если в многошаговой форме она доступна до заполнения всех обязательных полей, каждое нажатие фиксируется в Метрике как новая покупка. Если для каждого события генерируется новый transactionId, одинаковые заказы выглядят как разные.
Чтобы исключить повторную отправку purchase, событие следует привязать к успешной отправке формы заказа. Если дубли совпадают по идентификатору заказа, содержимому и доходу, можно включить опцию "Удаление дублей событий" в настройках счетчика Метрики.
Превышаются лимиты на размер запроса и количество событий
E-commerce-данные могут передаваться не полностью или вовсе выпадать из аналитики, а атрибуция — искажаться. При этом на сайте не возникает явных ошибок.
В Яндекс Метрике установлены следующие лимиты:
-
максимальный размер JSON в одном запросе — 8192 символа;
-
количество параметров за визит — 512;
-
количество параметров за визит для событий взаимодействия со списком и баннером — 400;
-
количество событий за визит — 1000.
Если запрос превышает допустимый размер, событие может быть обрезано или отброшено целиком. Один из характерных сигналов — расхождение между достижениями цели "Ecommerce: Покупка" и количеством покупок. Например, в магазине недорогих товаров корзины могут содержать десятки позиций. При превышении лимита в 8 КБ данные передаются некорректно или не попадают в Метрику. В отдельных случаях цель "Ecommerce: Покупка" фиксируется, а информация о самой покупке отсутствует. Проверить это можно в истории посетителя: достижение цели есть, а данных о покупке нет.
Превышение лимита в 1000 событий проявляется иначе: Метрика разделяет визит на несколько, из-за чего растет количество сессий и может измениться источник покупки. Например, в отчете "Источники заказов" появляются заказы с нетипичным источником — платежным шлюзом. При проверке выясняется, что покупка привязалась не к реальному источнику перехода, а к шлюзу, который оказался последним перед разрывом визита.
Если передается большой объем данных, запросы рекомендуется разбивать на части — например, заказы на подзаказы. Для оценки фактического количества заказов можно настроить jаvascript-цель и передавать ее в Метрику с одним из подзаказов. Также следует контролировать объем отправляемых событий и оптимизировать их количество, чтобы избежать разделения визита на несколько и, как следствие, искажения источника покупки.
На разных этапах воронки передается разный набор данных
Несогласованность данных о товаре на разных этапах нарушает связь между просмотром, добавлением в корзину и покупкой. В результате воронка строится некорректно, статистика по брендам и категориям становится неполной, а отдельные действия не удается связать с источником трафика.
Например, поле brand может присутствовать при просмотре и добавлении товара, но отсутствовать при покупке. Тогда в статистике по бренду отображаются просмотры, но не покупки, поэтому оценить востребованность товаров в этом разрезе невозможно.
Расхождения возникают и из-за лишних символов. Например, табуляция в названии товара в событии add приводит к тому, что Метрика воспринимает его как другую позицию. Добавления в корзину не связываются с просмотрами и покупками, хотя визуально данные совпадают.
Для корректного анализа необходимо передавать одинаковый набор полей во всех e-commerce-событиях. Если это невозможно, по срезу с неполными данными следует анализировать только те этапы, где они гарантированно есть.
Чек-лист для ручной проверки e-commerce-событий
Если отчеты указывают на аномалию, ручная проверка поможет локализовать ошибку и сформулировать задачу для разработчиков.
-
Подготовка.
-
Включить отладку. Добавить к URL параметр _ym_debug=2. Для старого кода счетчика — _ym_debug=1, в этом случае отладка доступна только через консоль.
-
Сохранить логи. Включить Preserve log в панели разработчика, чтобы события не исчезали при переходах между страницами.
-
Зафиксировать clientID. Сохранить значение cookie _ym_uid, чтобы отделить тестовый визит от остальных и проверить, какие события попали в аналитику.
-
Проверка событий.
| Событие | Где проверить | На что обратить внимание |
| Просмотр списка товаров / impressions | Каталоги, брендовые и акционные страницы, рекомендательные полки | Размер запроса |
| Клик по товару из списка / click | Клики по товару из любых списков | Событие срабатывает во всех точках; передается позиция товара в index |
| Просмотр карточки товара / detail | Карточка, быстрый просмотр, переключение цвета и размера | Событие срабатывает при любом способе просмотра |
| Добавление товара в корзину / add | Добавление из карточки, каталога и быстрого просмотра; "+" и ручное изменение количества в корзине | Событие срабатывает при всех способах добавления; в quantity передается добавленное, а не итоговое количество |
| Удаление товара из корзины / remove | "−", удаление позиции и ручное изменение количества | Событие срабатывает при всех способах удаления; в quantity передается удаленное количество, а не остаток |
| Покупка / purchase | Успешная отправка формы, покупка в один клик | Событие срабатывает только после успешной отправки формы и не повторяется при перезагрузке страницы "Спасибо"; в actionField.id передается уникальный номер заказа |
Важно проверить, что на каждом этапе сохраняется единый набор данных о товаре, валюта в currencyCode соответствует настройкам счетчика и отсутствуют лишние символы в стоимости.
Достоверная статистика позволяет принимать обоснованные решения, а ее качество зависит от точности данных на каждом этапе пользовательского пути. Регулярная проверка всей цепочки позволяет вовремя выявлять расхождения, до того как они отразятся на бизнес-показателях.
Комментариев: 0