Как проверить e-commerce-воронку в Яндекс Метрике: от списка товара до покупки

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

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

В базовой цепочке impressions отмечает показ товара в списке, click фиксирует клик, detail сообщает об открытии карточки, add — о добавлении в корзину, а purchase подтверждает заказ. Если проверяем удаление, добавляем remove. Каждое событие должно сработать в свой момент: клик по ссылке ещё не означает, что карточка загрузилась.

Внутри каждого события лежат данные о товаре. Для сверки нужны id или name и, по ситуации, list, position, price, quantity, variant. currencyCode стоит уровнем выше — внутри общего объекта ecommerce.

Лучший якорь для теста — устойчивый ID: он не должен меняться между списком, карточкой, корзиной и покупкой. Яндекс также рекомендует сохранять list после просмотра списка.

У покупки есть второй ориентир — actionField.id. Сайт отправляет его в Метрику, а команда по нему находит заказ в закрытом отчёте. С товарным ID это значение не связано.

Чтобы потом не искать один номер вместо другого, заранее разведите три обозначения:

• код теста, например TEST-01, связывает внутренний журнал и задачи, но может вообще не уходить в Метрику;
• ID товара тянется через все товарные события и показывает, что речь по-прежнему об одном товаре;
• синтетический ID покупки уходит в purchase.actionField.id, а затем помогает найти тестовый заказ в отчёте.

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

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

Затем сверьте счётчик и сайт. Электронная коммерция должна быть включена, а имя контейнера — совпадать в обоих местах. Обычно это dataLayer; параметр счётчика задают как ecommerce:true либо указывают другое имя.

Контейнер нужен на всём маршруте, а новые объекты сайт добавляет методом push. Отправку нельзя откладывать до ухода со страницы: следующая страница может открыться раньше, и событие потеряется по дороге.

Здесь важна последовательность: один товар, один маршрут, никаких прыжков через шаг.

1. Откройте выбранный список и убедитесь, что тестовый товар действительно показан.
2. Перейдите в карточку именно из этого списка, а не по прямой ссылке.
3. Добавьте товар в корзину; если в сценарии есть удаление, удалите его и положите снова.
4. Доведите заказ до экрана, где покупка подтверждена.

Рядом с каждым шагом запишите время в одном часовом поясе. Иначе соседние тесты легко принять за одну цепочку.

Если на сайте стоит новый код счётчика, добавьте к адресу _ym_debug=2: после действия событие должно появиться в панели. Панель не открылась — переходите к _ym_debug=1, включайте сохранение журнала и смотрите стандартный контейнер через JSON.stringify(dataLayer).

Сообщение dataLayer is not defined означает, что массива на странице нет. Пустой [] говорит другое: контейнер есть, но выполненное действие ничего в него не добавило. Если объект найден, сравните его целиком с ожиданием — одной строки ecommerce мало.

В журнал перенесите три вещи: ожидаемый объект, фактический объект и отметку отладчика. Между соседними шагами сверяйте товарный ID и нужные поля, а ecommerce.currencyCode проверяйте на уровне всего объекта.

Расхождение — это ещё не диагноз. Новый ID может появиться из-за варианта товара, другого источника каталога или ошибки маппинга. Пока код и журналы не проверены, это три версии, а не три факта.

Не ищите событие в отчёте сразу после клика. Обычно Метрике нужно 10–15 минут, иногда больше. Запланируйте две проверки: первую после обычного окна обработки, вторую — если данных всё ещё нет.

Отчёты собирают данные по-разному. «Списки товаров» опирается на список, позицию и название, а «Популярные товары» и «Товары в корзине» — на название. Поэтому общая строка отчёта не всегда принадлежит именно вашему тесту. Точный ID покупки ищут в «Содержимом заказов», остальные шаги связывают по времени, отладчику и доступным группировкам.

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

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

Фраза «починить аналитику» бесполезна: из неё не ясно ни где сломалось, ни как принимать работу. В хорошей задаче есть место разрыва, сценарий воспроизведения и наблюдаемый результат.

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

Объект в контейнере есть, а отладчик его не видит. Проверять нужно имя контейнера, параметр ecommerce, структуру объекта и момент перехода. Критерий приёмки простой: событие появляется при повторе.

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

Если товар по дороге сменил ID, сохраните оба значения и страницы, где они появились. Команде нужен либо один ID на всём пути, либо понятное и проверяемое правило связи вариантов.

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

Если сумма стала нулевой, проверьте ecommerce.currencyCode, price, quantity и состав покупки. Само наличие purchase ещё ничего не говорит о корректности выручки.

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

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

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

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

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

• имя контейнера совпало в настройках счётчика и в коде сайта;
• товар, цена, валюта, список и три вида идентификаторов были записаны до запуска;
• у каждого шага есть ожидаемый объект, время и фактические значения;
• impressions, click, detail, add, при необходимости remove и purchase появились в отладчике;
• товар сохранил один ID между событиями, а покупка получила отдельный actionField.id;
• после обработки каждый шаг проверен в подходящем отчёте с учётом его группировок;
• наблюдаемый факт не смешан с предполагаемой причиной;
• персональные данные, токены и исходный номер рабочего заказа не ушли в общий документ;
• после исправления команда провела новый тест и сохранила результат.

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