Как проверить цели и электронную коммерцию в Яндекс Метрике
Содержание 9 разделов
Проверка Яндекс Метрики — это не поиск зелёной галочки в настройках счётчика. Рабочая аналитика должна выдержать один и тот же контрольный маршрут от действия посетителя до записи в отчёте: нужный счётчик загружается, событие возникает в правильный момент, параметры имеют ожидаемый формат, а заказ в Метрике совпадает с заказом в CMS или CRM.
Цели и электронная коммерция решают разные задачи. Цель отвечает на вопрос, произошло ли значимое действие. Ecommerce-событие описывает товарный контекст: какой товар посмотрели, что добавили в корзину, какой заказ подтвердили и какую сумму нужно отнести к покупке. Поэтому исправная цель отправки формы ещё не доказывает, что доход и состав заказа передаются корректно.
Ниже — методика, которой удобно пользоваться перед запуском рекламы, после обновления сайта и при расхождении отчётов с учётной системой. Она основана на официальных инструкциях Яндекс Метрики и не требует доверять одному признаку.
Сначала определите, что именно должно измеряться
Разделите цели и товарные события
Составьте короткую карту пользовательского пути. Для формы это может быть открытие страницы, успешная отправка и появление подтверждения. Для магазина — просмотр карточки, добавление товара, удаление из корзины, подтверждение заказа и, если бизнес считает покупкой только оплату, отдельное серверное подтверждение оплаты.
Не смешивайте действие интерфейса и бизнес-результат. Клик по кнопке «Оформить» не равен созданному заказу, а переход на страницу благодарности не всегда означает оплату. Название цели должно отражать факт, который действительно проверяет код: например, form_success, order_created или payment_confirmed.
Зафиксируйте ожидаемые поля до теста
Для каждой цели запишите номер счётчика, идентификатор, страницу и условие срабатывания. Для ecommerce-события дополнительно нужны тип действия, ID товара, название, цена, количество, валюта и источник значения. Для покупки заранее зафиксируйте ID контрольного заказа, итоговую сумму и состав позиций.
Такой перечень превращает проверку из «кажется, событие есть» в приёмку. Он также помогает увидеть лишние отправки: если одна покупка должна возникнуть один раз, два одинаковых вызова уже являются дефектом, даже если итоговые цифры пока выглядят правдоподобно.
Подготовьте воспроизводимый контрольный сценарий
Используйте отдельные тестовые данные
Выберите товар или набор товаров, которые легко узнать в журнале и отчёте. Подойдёт технический SKU вроде TEST-SKU-001 и заказ с явно зафиксированным номером. Сумму, скидку, доставку и количество запишите до начала теста. Не включайте в названия, URL, параметры целей или идентификаторы телефон, email, ФИО и другие данные человека.
Проведите маршрут последовательно: откройте карточку, добавьте товар, измените количество, при необходимости удалите и верните позицию, затем оформите заказ. Если сайт одностраничный, отдельно проверьте переходы без полной перезагрузки: именно там часто теряются просмотры или повторно подключаются обработчики.
Проверяйте после каждого значимого изменения
Один успешный тест не защищает от регрессии. Повторная проверка нужна после смены шаблона, checkout, системы управления тегами, модуля CMS, способа оплаты, согласия на cookie и логики динамической подгрузки. Сохраняйте дату, версию релиза, контрольный ID и результат — тогда следующая проверка не начинается с догадок.
Проверьте обычные цели через отладчик Метрики
Убедитесь, что тестовый визит учитывается
Если в фильтрах включена опция «Не учитывать мои визиты», откройте сайт в приватном режиме. Затем добавьте к адресу параметр _ym_debug=2, загрузите страницу и выполните целевое действие. Официальная инструкция показывает событие во вкладках Events и Console панели отладки [1]. Для старого кода счётчика предусмотрен режим _ym_debug=1 и консоль браузера.
Смотрите не только название события, но и номер счётчика. На сайте могут одновременно работать старый и новый счётчики, тестовый контейнер или код партнёра. Событие, ушедшее не в тот счётчик, технически отправлено, но для рабочего отчёта потеряно.
Для JavaScript-цели проверьте момент вызова reachGoal
Метод имеет форму ym(XXXXXXXX, 'reachGoal', 'TARGET_NAME') [2]. Вызывать его следует после подтверждённого действия, а не просто при нажатии кнопки. Для формы хорошая точка — успешный ответ сервера; для регистрации — созданная учётная запись; для заказа — результат, соответствующий принятому в компании определению конверсии.
Если действие уводит посетителя на другую страницу, убедитесь, что отправка не обрывается переходом. Если интерфейс допускает двойной клик, повторный callback или повторное открытие модального окна, проверьте, не вызывается ли цель несколько раз. После отладки дождитесь появления достижения в отчёте «Конверсии»: справка Метрики отдельно указывает, что данные появляются там через несколько минут [1].
Проверьте подключение электронной коммерции
Сверьте настройку счётчика и имя контейнера
В настройках счётчика должна быть включена электронная коммерция, а имя контейнера должно совпадать с кодом сайта. Метрика поддерживает ecommerce:true или явную запись ecommerce:'dataLayer'; при нестандартном имени оно должно совпадать во всех местах [3].
Контейнер — глобальный JavaScript-массив. Ecommerce-объекты добавляются в него методом push [4]. Ошибка dataLayer is not defined означает, что массив не инициализирован, а пустой массив после выполненного действия показывает, что событие в него не добавилось [3]. Отдельно проверьте порядок загрузки: событие не должно исчезнуть из-за поздней инициализации или перезаписи массива.
Проверьте структуру каждого события
С параметром _ym_debug=2 выполните нужное действие и откройте вкладку Ecommerce. Для глубокой проверки включите в консоли Preserve log, повторите действие и выполните JSON.stringify(dataLayer). Скопированный объект удобно сопоставить с официальными примерами [3].
Для просмотра товара ожидается блок detail, для добавления — add, для удаления — remove, для покупки — purchase. В объекте товара сверяйте типы полей: цена должна быть числом, количество — целым числом, а ID товара — стабильным значением из каталога. Категория поддерживает иерархию с разделителем / [4].
Особенно внимательно проверьте покупку
Сопоставьте заказ, сумму и товары
Официальный формат покупки требует строковый идентификатор в actionField.id. Доход можно передать полем revenue; если его нет, Метрика рассчитывает сумму по товарам [4]. В контрольном заказе сравните ID, валюту, общую сумму, количество строк, ID каждой позиции, цену и количество.
Заранее определите, что входит в доход: доставка, скидка, бонусы и налоги. Метрика не может угадать бизнес-правило, если сайт передал другую величину. Расхождение нужно искать от источника: сначала объект в браузере, затем принятые данные, потом отчёт и запись в CMS.
Убедитесь, что одна покупка отправляется один раз
Повторите загрузку страницы подтверждения, возврат из платёжной системы и повторный запуск SPA-компонента. Проверьте, не срабатывают ли одновременно модуль CMS, собственный скрипт и тег-менеджер. Стабильный ID заказа помогает находить дубли, но защиту от повторной отправки лучше реализовать в самом приложении.
Событие покупки следует формировать в момент подтверждения заказа [4]. Если фактом продажи считается подтверждённая сервером оплата, браузерная страница благодарности может быть ненадёжным источником: покупатель способен закрыть вкладку или не вернуться из эквайринга. Такой сценарий нужно вынести в отдельную серверную передачу, а не пытаться скрыть расхождение фильтром отчёта.
Сверьте три уровня, а не один экран
Код и браузер
Проверьте, что нужный обработчик выполняется, счётчик загружен, контейнер не перезаписан, а объект содержит ожидаемые поля. Network и Console помогают увидеть блокировку запросов, JavaScript-ошибки и повторные вызовы. Отладчик Метрики подтверждает, как событие распознано конкретным счётчиком.
Отчёты Метрики
Цель должна появиться в отчёте «Конверсии», а ecommerce-события — в отчётах электронной коммерции. Официальная справка предупреждает, что первая статистика по электронной коммерции может появляться спустя несколько часов [5]. Поэтому отсутствие строки сразу после теста ещё не доказывает ошибку, но не отменяет последующую сверку.
CMS, CRM или учётная система
За выбранный период сопоставьте число уникальных заказов, их ID и сумму. Не сравнивайте только общую выручку: одинаковый итог может скрывать один пропущенный и один задвоенный заказ. Для приёмки полезнее таблица «ID — сумма в CMS — сумма в Метрике — статус — объяснение расхождения».
Типичные причины неверных данных
- Неверный момент события. Цель уходит по клику, хотя сервер отклонил форму или заказ.
- Несовпадающее имя контейнера. Счётчик слушает
dataLayer, а сайт отправляет в другой массив. - Строка вместо числа. Цена содержит пробел, знак валюты или запятую и перестаёт быть корректным числом.
- Повторная инициализация. SPA, модальное окно или тег-менеджер подключает один обработчик несколько раз.
- Два источника покупки. Одно событие формирует CMS, второе — собственный скрипт или сервер.
- Переход раньше отправки. Новая страница загружается до того, как счётчик успел принять событие; справка отдельно предупреждает о таком риске [4].
- Идентификационные данные в параметрах. Телефон, email или ФИО попадают в URL, название цели или параметры визита, хотя условия Метрики это запрещают [6].
Протокол приёмки аналитики
Проверку можно считать завершённой, когда один и тот же контрольный сценарий даёт согласованный результат на всех уровнях:
- события возникают только после подтверждённого действия и уходят в нужный счётчик;
- в ecommerce-объектах верны тип действия, ID, цены, количество, валюта и состав;
- контрольная покупка отправляется один раз и сохраняет устойчивый ID заказа;
- цели и товарные события появляются в соответствующих отчётах после обработки;
- заказ и сумма объяснимо совпадают с CMS или CRM;
- повторная загрузка страницы и ошибки интерфейса не создают лишних конверсий;
- в URL, UTM, целях и параметрах нет идентификационных данных.
Итогом должна быть не только исправленная настройка, но и карта событий, контрольный заказ и короткая инструкция повторной проверки. Это позволяет безопасно обновлять сайт и быстро локализовать расхождение, если цифры снова изменятся.