Количество оформленных заказов и количество оплат отвечают на разные вопросы. Первое показывает, сколько заказов магазин принял. Второе — сколько заказов действительно оплачено. Если оба результата считать одним событием на странице «Спасибо», аналитика интернет-магазина может выглядеть убедительно и при этом скрывать потери после оформления.
Начните с пути покупателя: товар → корзина → оформление → подтверждение заказа → оплата. Для каждого перехода договоритесь, какое действие произошло, какая система его подтверждает и какие данные нужны для проверки. Сам по себе установленный счётчик этого договора не заменяет.
Какие события нужны для основного пути
В Яндекс Метрике электронная коммерция передаёт действия с товарами и покупки. В документированном формате есть detail, add, remove и purchase. Начало оформления, ошибки формы и фактическую оплату при необходимости отслеживают дополнительными целями или через отдельный обмен данными. Их названия и условия задаются для конкретного магазина.
| Шаг | Что фиксировать | Где проходит граница события |
|---|---|---|
| Просмотр товара | Открытие карточки, идентификатор товара и выбранный вариант; в ecommerce — detail | Карточка открыта. Загрузка каталога сама по себе не означает просмотра каждой карточки |
| Добавление в корзину | Товар, вариант и добавленное количество; add | Корзина действительно изменилась. Неуспешный клик по кнопке не считается добавлением |
| Удаление из корзины | Товар и удалённое количество; remove | Позиция или её часть удалена из корзины. Это ещё не возврат покупки |
| Начало оформления | Переход к оформлению непустой корзины | Покупатель приступил к заказу. Он ещё не отправил форму и не оплатил товар |
| Подтверждение заказа | Принятый магазином заказ с устойчивым ID и составом; согласованная точка для purchase | Заказ сохранён, и система подтвердила результат. Одного нажатия «Оформить» недостаточно |
| Оплата | Достоверный статус платежа, связанный с заказом | Система магазина получила и проверила подтверждение оплаты. Открытие платёжной страницы не считается оплатой |
Это основа измерений, а не требование к каждому покупателю пройти все экраны. «Купить в один клик» может обходить корзину, повторный заказ — карточку товара, оплата при получении — происходить позже. Такие маршруты нужно учитывать отдельно, иначе отсутствие промежуточного события будет выглядеть ошибкой.
Если менеджер проверяет наличие и только потом принимает заказ, создание записи и подтверждение заказа тоже могут быть разными шагами. Если заказ принимается автоматически, они могут совпадать. Не добавляйте отдельное событие лишь ради длинной воронки: сначала определите реальный процесс.
Почему purchase не доказывает оплату
В официальной инструкции Метрики событие purchase отправляется в момент подтверждения заказа. Его название и сумма в отчёте не удостоверяют списание денег: данные передаёт сам магазин. Поэтому в задании на аналитику нужно прямо написать, что здесь считается подтверждением.
Например: «Передаём purchase, когда сервер сохранил и принял заказ. Для оплаты фиксируем отдельный подтверждённый статус». Если в вашем процессе заказ подтверждается только после успешного платежа, это другая точка фиксации. Её тоже нужно описать и проверить. Менять условие незаметно для тех, кто читает отчёты, нельзя: сравнение периодов потеряет смысл.
Не отправляйте вторую покупку по тому же заказу только потому, что позже он оплачен. Разделите подтверждение заказа и оплату в данных. В отчёте владельца полезно видеть оба результата, а рядом — понятное пояснение, какой из них обозначает доход от оплаченных заказов.
При онлайн-оплате возвращение покупателя на сайт не является достаточным основанием. Покупатель может закрыть вкладку после платежа, а страница возврата — открыться раньше окончательного статуса. Источником подтверждения должен служить проверенный результат платёжной системы, который сервер магазина сопоставил с заказом. Для оплаты при получении нужен соответствующий подтверждённый статус в системе учёта магазина.
Что передавать вместе с событием
Событие без связи с товаром или заказом трудно проверить. Для основного пути предусмотрите:
- устойчивый идентификатор товара и способ различать варианты, если размер, цвет или комплектация влияют на покупку;
- количество изменённых единиц для корзины и количество заказанных единиц для покупки;
- цену единицы товара и валюту;
- устойчивый идентификатор покупки для
purchase, связанный с заказом магазина; - единое правило расчёта суммы: как учитываются скидка, доставка и другие составляющие.
В Метрике purchase.actionField.id обязателен. Если поле revenue не передано, доход рассчитывается из цен товаров. Поэтому состав и сумма события должны соответствовать заказу на момент его подтверждения. Не подставляйте текущую цену каталога в старый заказ и не умножайте цену на количество дважды.
Не формируйте ID из телефона, почты или имени покупателя. Используйте технический идентификатор, а связь с клиентом храните внутри системы магазина с соответствующими правами доступа. В обычные события и параметры Метрики не передают ФИО, телефон, email, адрес доставки и банковские данные. Это относится и к названиям событий, адресу страницы, её заголовку и произвольным полям: случайно скопированное содержимое формы тоже может раскрыть данные.
Повторы, отмены и возвраты
Обновление страницы «Спасибо» не создаёт новый заказ. Повторная попытка доставить событие тоже не должна превращаться в новую покупку. Зафиксируйте один источник отправки каждого результата: одновременная передача из модуля магазина и дополнительного скрипта может дублировать действия.
Устойчивый ID помогает сопоставлять записи, но сам по себе не доказывает, что защита от дублей настроена. Попросите разработчика показать результат при обновлении страницы, повторном открытии подтверждения и повторной доставке уведомления об оплате. В журнале обработки должно быть видно, что один подтверждённый результат учтён один раз. При этом новая покупка того же человека получает новый ID, а повторная доставка данных старой покупки сохраняет прежний.
Важно различать четыре случая:
- Удаление из корзины: товар ещё не заказан; это
remove. - Отмена неоплаченного заказа: заказ был принят, но оплаты нет. Она не должна появиться в числе оплат.
- Возврат оплаченной покупки: отдельная операция, связанная с исходным заказом и подтверждённым возвратом денег.
- Частичный возврат: возвращены конкретные позиции, количество или часть суммы; весь заказ нельзя автоматически считать полностью возвращённым.
В опубликованном перечне действий стандартного JS ecommerce Метрики отдельного действия refund нет. Не заменяйте возврат событием remove и не рассчитывайте, что отмена в CMS автоматически исправит уже переданную покупку. Учёт возвратов согласуйте отдельно: например, в отчёте по данным заказов и платежей или в предусмотренной для этого интеграции. Владелец должен понимать, показывает ли сумма отчёта принятые заказы, подтверждённые оплаты или оплаты за вычетом возвратов.
Учебный пример. Заказ A-104 принят магазином, но покупатель ушёл с платёжной страницы. В аналитике есть подтверждённый заказ, оплаты нет. Затем покупатель оплачивает его по сохранённой ссылке: статус оплаты связывается с тем же A-104, новая покупка не создаётся. Позже магазин возвращает деньги за одну позицию — учитывается частичный возврат, а не удаление товара из корзины. Это пример различения событий, а не результат реального проекта.
Как владельцу проверить настройку
Принимать работу только по скриншоту графика недостаточно. Попросите исполнителя пройти контрольный заказ вместе с вами и показать связь между действием, записью магазина и данными аналитики.
- Проверьте исходные условия. В настройках счётчика Метрики включена электронная коммерция; имя контейнера данных совпадает с используемым на сайте. Исполнитель показывает, откуда берутся ID товара, ID покупки и суммы.
- Откройте отладку. Добавьте параметр
_ym_debug=2к адресу страницы и пройдите путь на сайте. Во вкладке Ecommerce панели отладки должны появляться соответствующие действия. Для прежнего кода счётчика или отсутствующей панели предусмотрена проверка через консоль браузера; её выполняет разработчик. - Проверьте корзину. Добавьте товар, измените количество, удалите позицию. В передаваемых данных отражаются реальные изменения, а не все товары корзины как новые добавления при каждом обновлении.
- Проверьте оформление с ошибкой. Пропустите обязательное поле или воспроизведите согласованный отказ создания заказа. Покупка не должна фиксироваться, пока магазин не принял заказ. Техническую проверку ошибок проводят безопасно, без повреждения реальных заказов.
- Создайте контрольный заказ. Сопоставьте его ID, состав, варианты, количество и сумму с событием покупки. В отчёте Метрики «Электронная коммерция → Содержимое заказов» проверьте данные этого заказа после их обработки.
- Проверьте оплату отдельно. В предусмотренном платёжной системой тестовом режиме выполните успешный и неуспешный сценарии. Покажите, что подтверждение оплаты привязано к нужному заказу, а отказ не увеличивает число оплат. Отдельно проверьте ситуацию, когда покупатель не вернулся на сайт.
- Проверьте повторы и возврат. Обновите страницу подтверждения и откройте её повторно. Исполнитель отдельно проверяет повторную доставку платёжного уведомления, отмену неоплаченного заказа и частичный возврат. Заказ и его сумма не должны необоснованно удваиваться.
- Повторите пользовательский путь на телефоне. Проверьте используемые магазином варианты: быстрый заказ, авторизованный покупатель, оплата позже. Убедитесь, что контрольные операции можно отделить от рабочих данных.
Отладчик подтверждает передачу события, отчёт — его появление в аналитике, а система заказов и платежей — бизнес-результат. Браузерные события могут не поступить из-за блокировки счётчика, закрытой вкладки или сетевого сбоя. Поэтому при расхождении с учётом магазина сначала выясняют причину и границы данных; не объявляют все отсутствующие события потерянными продажами.
Как использовать данные после проверки
Смотрите, на каком переходе появляется разрыв. Товар смотрят, но редко добавляют в корзину — проверьте предложение, доступность вариантов и саму кнопку. Корзину собирают, но не начинают оформление — проверьте итоговую стоимость и условия доставки. Оформление начинают, но заказ не принимается — проверьте форму и ошибки. Заказ подтверждён, но оплата не завершена — изучите платёжный сценарий и возможность оплатить позже.
Это направления проверки, а не готовые причины. Сопоставляйте одинаковые маршруты и периоды, отдельно учитывайте устройства и способы оплаты. Не считайте долю перехода простым делением общего числа событий: один покупатель может открыть несколько карточек, многократно менять корзину и оформить несколько заказов. Для воронки заранее определяют единицу анализа — например, визит или заказ — и условия последовательности шагов.
Если нужно связать результат с рекламой, следующий вопрос — как определить источник обращения и учесть ограничения атрибуции. Для обмена статусами заказа и оплаты полезно разобраться, как устроена интеграция сайта через API.
В задании на настройку веб-аналитики зафиксируйте словарь событий, точку purchase, источник подтверждения оплаты, правила суммы, защиту от повторов и контрольные сценарии. При разработке интернет-магазина эти условия лучше согласовать вместе с корзиной, оформлением и платёжным процессом: аналитика должна опираться на реальные состояния заказа.
