GA4 Enhanced Ecommerce: какие события реально нужны интернет-магазину, а какие — цифровой шум

«У нас настроена вся электронная торговля в GA4» — фраза, за которой часто стоит один раз нажатая кнопка «Enable Enhanced Ecommerce» в шаблоне GTM, без единой проверки, что данные реально приходят верно. Разбираю, какие события из стандартного набора держат смысл в себе, какие нужны только при конкретной задаче, и что обычно идёт не так при настройке.

Стандартный набор событий GA4 для электронной торговли

Google документирует рекомендованный набор ecommerce-событий: view_item_list, select_item, view_item, add_to_wishlist, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund. В готовых GTM-шаблонах (включая решения для большинства CMS и конструкторов) все они обычно включаются сразу пакетом.

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

Четыре события, без которых аналитики нет вообще

• view_item. Просмотр карточки товара. Базовая точка входа в воронку, без неё не посчитать конверсию из просмотра в покупку.
• add_to_cart. Добавление в корзину. Разница между «добавили, но не купили» и «даже не добавили» — это разные проблемы на разных этапах, и чинить их нужно по-разному.
• begin_checkout. Старт оформления заказа. Без него не увидеть процент, который доходит до оплаты, а который бросает корзину на этапе «посмотрел итоговую сумму и ушёл».
• purchase. Собственно покупка, с revenue и товарами в параметре items. Без него нет самого смысла в ecommerce-отчётах.

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

Что нужно не всегда, а под конкретную задачу

• view_item_list и select_item — нужны, если хочешь понимать, с какой позиции в выдаче каталога или в блоке рекомендаций реально кликают. Для магазина с активным A/B-тестом карточной выдачи — критично. Для магазина, который такую выдачу не трогает месяцами — лишние два события на каждый клик.
• add_to_wishlist — ценен, только если список желаний реально используется в email-ремаркетинге или пуш-уведомлениях («забыли о товаре»). Если списка желаний на сайте нет вообще — событие можно не включать, оно ничего не даст.
• add_shipping_info и add_payment_info — показывают, на каком именно шаге чекаута теряются покупатели: выбор доставки или способ оплаты. Нужны, если чекаут многошаговый и ты реально собираешься чинить конкретный шаг. На одностраничном чекауте без разбивки по шагам — почти бесполезны.
• view_cart и remove_from_cart — полезны для диагностики брошенных корзин в деталях (что убирают из корзины перед уходом), не для ежедневного мониторинга.

Если ты не можешь назвать конкретный отчёт или гипотезу, под которую событие собирает данные — оно не «подстраховка», оно цифровой шум, который потом путает дебаг и раздувает квоту событий в GA4 (там есть лимиты на объём данных, особенно на бесплатном тарифе).

Моя ошибка: задвоенный purchase, который раздул выручку в отчётах

Настраивал ecommerce для магазина одежды — тег purchase сработал на срабатывание триггера «страница загрузилась» на thank-you-странице. Через месяц сверил выручку в GA4 с реальными продажами в CRM — цифра в GA4 оказалась на треть выше. Разбирался три дня, подозревал всё: курс валют в параметре, задвоение транзакций на бэкенде, баг в товарных фидах.

Оказалось проще и глупее: часть покупателей обновляла thank-you-страницу вручную (случайный рефреш, кто-то жмёт назад-вперёд в браузере проверить подтверждение) — и каждый такой рефреш слал новый purchase с тем же ID транзакции. GA4 по умолчанию не дедуплицирует события по transaction_id на уровне тега — дедупликация должна быть в логике самого тега: проверка, что событие для конкретного ID заказа ещё не отправлялось в этой сессии (через sessionStorage или серверную проверку).

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

Как проверить, что событие реально передаёт верные данные

• GA4 DebugView (включается через расширение GA4 Debugger или параметр debug_mode) — показывает каждое событие и его параметры в реальном времени, пока ты сам кликаешь по сайту.
• Отчёт Realtime в самом GA4 — быстрая проверка, что событие вообще долетает и считается в правильном месте интерфейса.
• Сверка параметра items построчно. Для purchase и add_to_cart обязательны item_id, item_name, price, quantity, currency — без них событие формально срабатывает, но отчёты по товарам (топ продаваемых, выручка по категориям) остаются пустыми или искажёнными.
• Сверка итоговой выручки GA4 с CRM/платёжной системой за одну неделю. Разница больше 3-5% — повод искать дубли или потерю событий, а не сразу «нормальная погрешность аналитики».

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