Электронная коммерция в Метрике: какие данные должен видеть маркетолог магазина

Начните с решений, для которых нужны данные

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

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

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

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

Разделите действия товара, корзины и заказа

Событие просмотра фиксирует открытие карточки товара. Добавление в корзину — о другом действии, которое ещё не создаёт обязательства купить. Удаление помогает увидеть изменение выбора. Событие покупки относится к согласованному результату оформления. Не подменяйте одно другим только потому, что на сайте есть удобная кнопка для отслеживания.

Для каждого действия укажите точный момент передачи. Карточка появилась на экране; товар действительно добавлен; количество изменено; заказ успешно сохранён. Нажатие кнопки, после которого сайт показал ошибку, не должно автоматически считаться завершённым действием. Разработчику нужен смысл события, а не просьба «поставить аналитику на все кнопки».

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

Какие сведения о товаре должны сохраняться

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

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

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

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

Как согласовать сумму, скидку и доставку

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

Составьте учебный заказ и рассчитайте ожидаемые значения вручную. Например, две единицы по 1 000 рублей, скидка на товары 200 рублей и доставка 300 рублей. Товарная сумма после скидки — 1 800 рублей, итог к оплате с доставкой — 2 100 рублей. Это условные числа для проверки; выбранное поле должно поддерживать такой показатель по документации Метрики.

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

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

Почему заказ не равен полученной выручке

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

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

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

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

Как поставить задачу разработчику без кода

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

Опишите повторы. Что произойдёт при обновлении страницы благодарности, возвращении назад, повторном открытии ссылки на заказ и задержке ответа сайта? Один и тот же результат не должен превращаться в несколько покупок из-за повторной отправки. Попросите исполнителя подтвердить поведение контрольным тестом, а не только сослаться на предполагаемую защиту сервиса.

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

Как провести контрольную покупку

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

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

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

Повторите проверку на телефоне и на альтернативном пути покупки, если он есть. Для ошибки оплаты или незаполненного обязательного поля должно быть заранее определено ожидаемое поведение. Не записывайте «всё работает» по одному успешному заказу, если магазин предлагает несколько способов оформления.

Как искать причину расхождений

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

Если покупок слишком много, проверьте повторную передачу после обновления страницы, несколько установленных механизмов ecommerce и альтернативные формы. Если мало — маршруты без события, ошибки на странице, ограничения работы счётчика и случаи, когда клиент не вернулся с внешней оплаты. Это направления диагностики, а не установленная причина без проверки.

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

Сохраняйте результаты разбора: пример, причина, исправление и повторная проверка. Не устанавливайте универсальный «допустимый процент» без понимания источников потерь. Для одного магазина небольшая разница может объясняться известным ограничением измерения, для другого — скрывать дефект отдельного способа оплаты.

Как использовать отчёты после проверки

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

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

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

Для начала соберите один план измерения и протокол контрольной покупки. ШТАБ ИТ помогает настраивать и проверять аналитику сайта. Если задача шире товарных событий, дополните её планом целей Метрики, сохраняя различие между обращением, оформлением заказа и его оплатой.