Какие цели настроить в Яндекс Метрике интернет-магазину
Как определить добавление в корзину, начало оформления, создание заказа и подтверждённую оплату. Таблица событий, отличие от ecommerce и сценарий проверки без двойного учёта.
Магазину нужны цели, которые отличают интерес к товару, начало покупки, созданный заказ и подтверждённую оплату. Начните с нескольких однозначно определённых событий, затем добавляйте только те, по которым будете принимать решение. Клик на кнопку «Купить» не следует называть продажей, если заказ ещё не создан.
Предполагаем, что счётчик Яндекс Метрики уже установлен. Здесь составим план целей и проверку их смысла. Передачу товарного состава, суммы и идентификатора покупки отдельно объясняет инструкция по электронной коммерции в Метрике.
Цель, достижение и заказ — разные единицы
Цель фиксирует выполнение заданного условия: событие, посещение страницы или другое поддерживаемое действие. В одном визите условие может выполниться несколько раз. Поэтому число достижений цели не всегда совпадает с числом покупателей и заказов, а доля целевых визитов имеет другой знаменатель.
Перед настройкой запишите, какую единицу используете в каждом отчёте. Если нужна доля покупателей, повторное действие одного человека нельзя считать новым независимым покупателем. Если анализируете заказы, свяжите события с учётом и используйте номера заказов для сверки. Метрика без определения легко меняет смысл при одном обновлении сайта.
Минимальная карта целей
Имена ниже — примеры для вашего технического задания, а не обязательные встроенные названия интерфейса. В официальной справке Метрики есть рекомендуемые события для магазинов, но событие должно реально передаваться сайтом или поддерживаемой интеграцией.
| Событие | Когда считать выполненным | Для какого решения нужно |
|---|---|---|
cart_add | Выбранный товар успешно добавлен | Отделить просмотр от действия с товаром |
checkout_start | Начат реальный путь оформления | Найти потери после корзины |
delivery_selected | Сохранён допустимый способ получения | Проверить проблемный шаг, если он существенен |
order_created | Заказ сохранён и имеет номер | Отделить работу формы от оплаты |
online_payment_confirmed | Подтверждён успешный платёж | Оценить завершение онлайн-оплаты |
Не добавляйте промежуточную цель, если у команды нет задачи, которую она помогает решить. Для магазина с заказом через консультацию отдельной конверсией может быть отправленное обращение. Нажатие на телефон остаётся нажатием: оно не доказывает разговор и тем более заказ.
Почему отдельная страница «Спасибо» не всегда подходит
URL-цель удобна, если посещение адреса действительно означает нужное действие. Но человек может перезагрузить страницу, открыть старую ссылку или вернуться после неуспешной оплаты. Тогда адрес не даёт достоверного подтверждения покупки.
В одностраничном оформлении состояние может меняться без отдельного URL. Для таких случаев технической команде обычно нужен поддерживаемый событийный способ. Например, вызов reachGoal отправляет достижение цели с согласованным идентификатором; сам по себе он не проверяет, был ли платёж. Условие успешности должно определяться системой заказа и платежа.
Не просите передавать личные сведения в имя цели, URL и произвольные параметры. Идентификатор события описывает действие, а не фамилию или телефон покупателя. Требования к обработке данных и составу передачи проверьте отдельно для своей реализации.
Как соотнести цели и ecommerce
Цель отвечает на вопрос о выполнении условия, а электронная коммерция добавляет данные о товарном действии: состав, суммы, идентификаторы. Эти возможности могут работать вместе. Не заменяйте фактическую стоимость заказа постоянной «ценностью цели», равной среднему чеку, если нужен расчёт реальной выручки.
Отдельно согласуйте момент события покупки в вашей модели: создание принятого заказа или подтверждение оплаты. Для оплаты при получении он не совпадает с онлайн-платежом. Документируйте правила и не суммируйте разные события как две продажи. Для управленческой выручки всё равно нужна сверка с заказами, отменами и возвратами.
Учебная проверка трёх заказов
Проверьте тестовые операции в предусмотренной среде и диагностическом режиме интеграции. Ниже вымышленный ожидаемый результат; это техническая приёмка событий, а не реальные продажи.
| Заказ | Исход | order_created | online_payment_confirmed |
|---|---|---|---|
| T-101 | Карта, подтверждён успех | Да | Да |
| T-102 | Заказ есть, платёж отклонён | Да | Нет |
| T-103 | Оплата при получении | Да | Нет |
В журнале заказов должны быть три записи и одна подтверждённая онлайн-оплата. Затем перезагрузите подтверждение T-101 и проверьте, не появилась ли вторая запись покупки. Просмотр страницы может повториться; учёт реального заказа от этого увеличиваться не должен.
Проверьте отказ формы: до сохранения заказа order_created не срабатывает. Для разных вариантов доставки пройдите необходимые поля. Сопоставьте видимое действие, диагностическое событие, номер заказа и статус платежа. Если отчёт показывает другую картину, выясните задержку данных, блокировку счётчика, неправильный момент отправки или повторные события.
Что передать исполнителю и как поддерживать настройку
В техническом задании укажите идентификатор цели, точное условие, источник истинного статуса и тестовые случаи. Для каждой строки назначьте ответственного за приёмку. Слов «настроить все цели» недостаточно: два исполнителя могут по-разному назвать покупкой один и тот же процесс.
После смены формы, модуля оплаты или согласий повторите затронутые сценарии. Данные браузерной аналитики могут отличаться от учёта из-за ограничений сбора; не объявляйте любое расхождение потерянной продажей. Для общей системы показателей используйте метрики интернет-магазина.