Товарная аналитика в Яндекс Метрике

Товарная аналитика в Яндекс Метрике

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

Главная задача настройки — получить последовательные данные, которые можно сопоставить с каталогом и системой заказов. Сам факт появления отчета еще не означает, что цифры корректны. Если одна модель передается под несколькими кодами, покупка отправляется повторно, а цена в корзине отличается от цены в заказе, маркетолог видит убедительные графики, но принимает решения на неверной основе.

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

Начните с управленческих вопросов

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

• Какие категории приводят покупателей, а какие создают много просмотров без заказов?
• В каких товарных списках пользователи замечают позиции и переходят в карточки?
• После каких действий чаще всего меняется состав корзины?
• Какие источники приводят заказы с большей выручкой?
• На каком устройстве или этапе оформления возникает заметный разрыв в воронке?
• Совпадает ли аналитическая сумма заказов с данными магазина за тот же период?

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

Опишите путь покупателя как набор проверяемых действий

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

Для каждого действия в спецификации фиксируют:

• условие запуска — что именно должен сделать пользователь или подтвердить сервер;
• источник данных — объект товара, состояние корзины или ответ системы заказов;
• состав параметров — идентификатор, название, цена, количество и дополнительные признаки;
• правило от повторов — при каком изменении событие допустимо отправить снова;
• контрольный результат — что должно появиться в контейнере и затем в отчете.

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

Создайте единую модель товара и заказа

Аналитическая система связывает события по переданным значениям. Она не знает, что «4587», «SKU-4587-BL» и «арт. 4587» относятся к одной позиции. Поэтому товар должен сохранять один ключ на всем пути. Если варианты продаются и анализируются отдельно, ключом обычно становится SKU варианта. Если цвет и размер не влияют на учет, можно использовать общий код товара и передавать вариант отдельным параметром.

Идентификатор важнее названия

Название меняется из-за редакторских правок, сезонных уточнений и формата витрины. Идентификатор должен быть стабильным и совпадать с ключом, по которому заказ можно найти в CMS, CRM или товарном учете. Тогда аналитические события удается проверить без ручного поиска по похожим названиям.

Цена требует общего правила

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

Категория должна отражать структуру каталога

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

Номер заказа связывает аналитику с учетом

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

Соберите товарную воронку из событий

Показ позиции в списке

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

Переход из списка

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

Просмотр подробной информации

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

Изменение корзины

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

Оформленный заказ

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

Защитите покупку от завышения

Самая дорогая ошибка внедрения — повторная передача одного заказа. Она завышает выручку, меняет оценку каналов и способна обучать рекламные стратегии на ложных конверсиях. Типичный источник проблемы — запуск purchase при каждой загрузке страницы благодарности. Посетитель обновляет вкладку или возвращается по истории браузера, и отчет получает еще одну покупку.

Стабильная схема строится вокруг серверного подтверждения:

1. Магазин успешно создает заказ и присваивает ему уникальный номер.

2. Клиентский код получает подтвержденный объект с составом и итоговой суммой.

3. Перед отправкой проверяется, не фиксировался ли этот номер ранее.

4. После передачи состояние сохраняется так, чтобы перезагрузка не повторила событие.

5. Отдельная проверка сопоставляет номер с записью в системе заказов.

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

Настройте техническую передачу

Метрика считывает ecommerce-объекты из контейнера данных в глобальной области браузера. Обычно используется window.dataLayer. Имя контейнера в коде должно совпадать с настройкой счетчика, а сам массив необходимо объявить до первой отправки.

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

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({​
ecommerce: {​
currencyCode: 'RUB',
add: {​
products: [{​
id: 'SKU-2048-GR-L',
name: 'Толстовка базовая',
category: 'Одежда/Толстовки',
variant: 'Серый, L',
price: 4290,
quantity: 1
}]
}
}
});

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

Порядок подключения

1. Включить электронную коммерцию в настройках счетчика.

2. Проверить параметр ecommerce и имя контейнера в коде сайта.

3. Объявить контейнер раньше товарных скриптов.

4. Реализовать события по согласованной спецификации.

5. Проверить обычный и альтернативные пути оформления.

6. Дождаться данных в отчетах и сопоставить их с контрольными заказами.

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

Проведите приемку на трех уровнях

Уровень событий в браузере

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

Уровень отчетов

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

Уровень системы заказов

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

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

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

Ошибки, которые выглядят как проблемы бизнеса

Одна позиция распалась на несколько строк

Причина часто находится не в ассортименте, а в разных идентификаторах. Каталог передает код карточки, корзина — код варианта, а заказ — артикул из учетной системы. Исправление начинают с единого словаря соответствий и повторной проверки всех событий.

Добавлений больше, чем просмотров

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

Выручка растет без изменения заказов

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

Событие теряется при переходе

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

В контейнер попадают данные покупателя

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

Читайте отчет как последовательность потерь

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

Рабочая последовательность анализа выглядит так:

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

2. Разделить данные по устройству, источнику и товарной категории.

3. Определить товары, которые внесли наибольший вклад в отклонение.

4. Проверить коммерческие условия и интерфейс соответствующего сценария.

5. Сформулировать одно проверяемое изменение и выбрать показатель результата.

6. После выпуска убедиться, что события продолжают передаваться корректно.

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

Поддерживайте аналитику после запуска

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

• включите ключевые ecommerce-сценарии в регрессионную проверку релизов;
• назначьте владельца спецификации и журнала изменений;
• регулярно сопоставляйте заказы и выручку с учетной системой;
• настройте контроль резких скачков и исчезновения событий;
• проверяйте новые способы оформления до публикации;
• не меняйте смысл полей без обновления документации и отчетов.

Контрольный список перед использованием данных

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

Краткие выводы

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

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