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

Аналитика интернет-магазина показывает, где магазин зарабатывает, где теряет заказы и какие действия пользователей влияют на выручку: просмотр категории, клик по товару, добавление в корзину, выбор доставки, оплата, покупка.

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

Нормальная e-commerce-аналитика строится на событиях. Сайт передает данные о действиях пользователя, товарах, ценах, скидках, категориях, корзине и заказах в DataLayer, а уже из GTM они отправляются в GA4, «Яндекс.Метрику», Roistat и другие системы.

Почему обычного счетчика на сайте недостаточно

Счетчик показывает посещения, источники, страницы входа и базовые цели. Для интернет-магазина этого мало: важно видеть не только визит, а весь путь к заказу.

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

Хорошая аналитика отвечает на конкретные вопросы:

• Какие категории и бренды дают выручку

• Какие товары часто смотрят, но редко добавляют в корзину

• Какие товары добавляют в корзину, но потом удаляют

• Где пользователи уходят из оформления заказа

• Какие способы доставки и оплаты выбирают чаще

• Какие баннеры и промо-блоки приводят к продажам

• Какие запросы во внутреннем поиске показывают реальный спрос

Из чего состоит аналитика интернет-магазина

Базовая схема выглядит так:

1. На сайт устанавливается Google Tag Manager

2. Сайт передает события в DataLayer

3. В GTM настраиваются теги для GA4, «Яндекс.Метрики», Roistat и других систем

4. Каждое событие передается вместе с параметрами: товар, категория, цена, скидка, количество, список, заказ, доставка, оплата

5. В аналитике собираются отчеты по воронке, товарам, категориям, источникам и заказам

Главная идея DataLayer — отделить сайт от систем аналитики. Разработчики формируют единый слой данных, а маркетолог или аналитик через GTM решает, куда эти данные отправлять. Это удобнее, чем вшивать каждый счетчик и каждую цель напрямую в код сайта.

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

Какие данные о товаре нужно передавать

Событие без данных о товаре почти бесполезно. Если пользователь добавил товар в корзину, аналитике нужно знать не только сам факт добавления. Важно понимать, какой это товар, из какой категории, с какой ценой, скидкой, брендом, вариантом и количеством.

Минимальный набор для e-commerce-аналитики:

• item_id — Идентификатор товара

• item_name — Название товара

• price — Цена за единицу товара

• discount — Скидка в абсолютном значении

• item_brand — Бренд

• item_category, item_category2, item_category3, item_category4 — Уровни категорий

• coupon — Купон или промоусловие

• index — Позиция товара в списке

• item_variant — Выбранный вариант товара: размер, рост, цвет, комплектация

• quantity — Количество товаров в корзине или заказе

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

Какие события нужно настроить в интернет-магазине

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

Путь до товара: списки, клики и карточки

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

view_item_list — показ списка товаров

Событие фиксирует показ списка товаров: категории, результатов поиска, рекомендаций, подборок, товаров со скидкой, блока «Вы уже смотрели».

Что передавать:

• item_list_name — Название списка

• items — Массив товаров в списке

• index — Позиция товара в списке

Данные товара: item_id, item_name, price, discount, item_brand, категории, купон

Зачем нужно:

• Видно, какие списки реально просматривают

• Можно сравнить кликабельность категорий, рекомендаций и подборок

• Можно оценить, как позиция товара влияет на переходы

• Можно найти списки с большим показом и слабым кликом

select_item — клик по товару в списке

Событие показывает, что пользователь заинтересовался товаром и перешел из списка в карточку.

Что передавать:

• Название списка, из которого был клик

• Данные товара

• Позицию товара в списке

• Товар внутри массива items, даже если он один

Зачем нужно:

• Понятно, какие списки приводят к просмотру карточек

• Видно, какие товары привлекают внимание до открытия карточки

• Можно оценить качество сортировки и первых позиций в выдаче

view_item — просмотр карточки товара

Событие фиксирует просмотр детальной карточки товара.

Что передавать:

• Данные товара

• Цену и скидку

• Бренд и категории

• Список, из которого пользователь пришел

• Купон или промоусловие, если оно есть

Зачем нужно:

• Видно, какие товары чаще всего смотрят

• Можно найти товары, которые смотрят, но редко добавляют в корзину

• Можно связать интерес к товару с категорией, списком, брендом и источником трафика

Если товар часто смотрят и редко добавляют в корзину, стоит проверять цену, наличие, фото, характеристики, доставку, отзывы, условия возврата и варианты товара.

Корзина: добавление, удаление и просмотр

На этапе корзины аналитика показывает, какие товары вызывают реальный коммерческий интерес и где покупатель начинает сомневаться.

add_to_cart — добавление товара в корзину

Событие фиксирует добавление товара в корзину.

Что передавать:

• Данные товара

• Цену и скидку

• Категорию и бренд

• item_variant — Размер, цвет, рост или другая выбранная характеристика

• quantity — Количество добавленных товаров

Зачем нужно:

• Видно, какие товары и категории дают потенциальную выручку

• Можно оценить влияние скидок на добавление в корзину

• Можно понять, какие размеры и варианты чаще выбирают

Важно: событие должно срабатывать после успешного добавления товара, а не просто по клику на кнопку. Если товар не добавился из-за ошибки или невыбранного размера, событие отправлять нельзя.

remove_from_cart — удаление товара из корзины

Событие фиксирует удаление товара из корзины.

Что передавать:

• Данные товара

• Выбранный вариант

• Количество удаленных единиц

• Контекст корзины

Зачем нужно:

• Видно, какие товары чаще удаляют

• Можно найти категории, где пользователи часто передумывают

• Можно проверить, не ломают ли покупку цена доставки, сроки, размеры, наличие или минимальная сумма заказа

view_cart — просмотр корзины

Событие фиксирует переход пользователя в корзину.

Что передавать:

• value — Итоговая стоимость корзины с учетом скидок

• currency — Валюта

• items — Все товары в корзине

• Количество, варианты, скидки и категории товаров

Зачем нужно:

• Можно построить переход от добавления товара к оформлению заказа

• Видно, сколько пользователей доходит до корзины

• Можно найти разрыв между add_to_cart и view_cart

Если добавлений в корзину много, а просмотров корзины мало, стоит проверять заметность корзины, состояние кнопки после добавления, мини-корзину, скорость обновления интерфейса и понятность следующего шага.

Оформление заказа: доставка, оплата и покупка

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

begin_checkout — переход к оформлению заказа

Событие показывает, что пользователь начал оформление заказа.

Что передавать:

• Товары в заказе

• Итоговую стоимость

• Валюту

• Скидки и промокоды, если они есть

Зачем нужно:

• Видно, сколько пользователей переходит из корзины к оформлению

• Можно сравнить поведение по устройствам и источникам

• Можно найти товары и категории, которые чаще доходят до оформления

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

add_shipping_info — выбор способа доставки

Событие фиксирует выбор доставки.

Что передавать:

• shipping_tier — Тип доставки

• value — Итоговая стоимость заказа

• items — Товары в заказе

Зачем нужно:

• Видно, какие способы доставки выбирают чаще

• Можно понять, на каких способах пользователи уходят

• Можно оценить влияние доставки на конверсию

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

add_payment_info — выбор способа оплаты

Событие фиксирует выбор оплаты.

Что передавать:

• payment_type — Тип оплаты

• value — Итоговая стоимость заказа

• items — Товары в заказе

Зачем нужно:

• Понятно, какие способы оплаты выбирают чаще

• Можно увидеть, какие способы оплаты чаще приводят к успешной покупке

• Можно найти отказы после выбора оплаты

Если после выбора оплаты много потерь, стоит проверять платежный шлюз, банковскую форму, возврат пользователя на сайт, мобильную оплату и статус заказа после платежа.

purchase — успешная покупка

Событие фиксирует успешную транзакцию. Это центральное событие e-commerce-аналитики.

Что передавать:

• transaction_id — Уникальный номер заказа

• value — Итоговая стоимость заказа

• currency — Валюта

• shipping — Стоимость доставки

• coupon — Промокод на уровне заказа

• items — Все товары в заказе

Что проверить:

• transaction_id уникален

• Событие не отправляется повторно при обновлении страницы

• Сумма заказа совпадает с CMS или ERP

• Доставка передается отдельно

• Промокод передается на уровне заказа

• Товары передаются с корректной ценой, скидкой, вариантом и количеством

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

Дополнительные события

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

add_to_wishlist — добавление товара в избранное

Показывает отложенный интерес. Если товар часто сохраняют, но редко покупают, стоит проверить цену, наличие нужных вариантов, доставку, отзывы и условия возврата.

Что смотреть:

• Какие товары чаще добавляют в избранное

• Какие из них потом покупают

• Какие категории имеют длинный цикл выбора

• Какие бренды пользователи сохраняют «на потом»

view_promotion и select_promotion — показы и клики по промо-блокам

Эти события нужны для баннеров, слайдеров, промо-плашек и подборок акций.

Что передавать:

• creative_name — Название креатива

• creative_slot — Место размещения

• promotion_id — Идентификатор акции

• promotion_name — Название акции

Что смотреть:

• Какие баннеры показываются

• Какие промо-блоки получают клики

• Какие акции ведут к просмотрам товаров и покупкам

• Какие баннеры занимают место, но не дают результата

sign_up и login — регистрация и авторизация

Для регистрации подходит событие sign_up с передачей user_id. Для входа в аккаунт лучше использовать отдельное событие login, чтобы не смешивать создание профиля и авторизацию.

Что смотреть:

• Как регистрация влияет на покупку

• Сколько пользователей покупает без аккаунта

• На каком этапе пользователь создает профиль

• Как авторизованные пользователи отличаются от новых

В аналитику нельзя передавать email, телефон, ФИО и другие персональные данные в открытом виде. user_id должен быть техническим идентификатором.

search — поиск на сайте

Событие фиксирует внутренний поиск. В нем передается поисковая фраза через search_term.

Что смотреть:

• Частые поисковые запросы

• Запросы без результатов

• Запросы с низким кликом по товарам

• Запросы, которые приводят к покупке

• Опечатки и разговорные формулировки

• Спрос на товары, которых нет в каталоге

Внутренний поиск часто показывает спрос лучше, чем внешняя аналитика. Пользователь сам пишет, что хочет найти. Эти данные можно использовать для ассортимента, синонимов, фильтров, названий товаров и SEO-страниц.

subscribe и sharing — подписка и кнопка «Поделиться»

subscribe фиксирует подписку на рассылку. Событие помогает понять, где пользователь готов оставить контакт: в футере, попапе, карточке товара, после заказа или в блоге.

Типичные ошибки при настройке e-commerce-аналитики

События срабатывают не в тот момент

add_to_cart должен срабатывать после успешного добавления товара, а purchase — после успешного создания заказа или оплаты в зависимости от бизнес-логики. Клик по кнопке сам по себе не всегда равен успешному действию.

События дублируются

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

В разных событиях разные названия товаров и категорий

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

Цена и скидка передаются некорректно

Цена должна быть числом. Скидку лучше передавать в абсолютном значении. Если где-то передается процент, а где-то сумма, отчеты по скидкам будут бесполезны.

Не передается список, из которого пришел пользователь

Без item_list_name невозможно понять, какой блок сработал: категория, рекомендации, поиск, «Вы уже смотрели», акция или подборка.

Не размечены доставка и оплата

Если аналитика заканчивается на begin_checkout, команда не видит, что происходит внутри оформления заказа. Для интернет-магазина это слепая зона.

В аналитику передаются персональные данные

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

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

Перед запуском интернет-магазина или после внедрения событий нужно пройти тестовый сценарий от первого просмотра до покупки.

Проверяем по шагам:

• Открытие страницы

• Показ категории или списка товаров

• Клик по товару

• Просмотр карточки

• Добавление в избранное

• Добавление в корзину

• Удаление товара из корзины

• Переход в корзину

• Переход к оформлению

• Выбор доставки

• Выбор оплаты

• Успешная покупка

• Показ и клик по промо-баннеру

• Поиск по сайту

• Регистрация, авторизация, подписка

• Для каждого события нужно проверить три вещи:

• Сработало ли событие

• Ушли ли правильные параметры

• Не было ли дублей

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

Практический чек-лист для интернет-магазина

1. Установить Google Tag Manager

2. Подключить «Яндекс.Метрику», GA4 и Roistat

3. Настроить передачу событий через DataLayer

4. Передавать товарные данные единообразно во всех событиях

5. Настроить view_item_list для категорий, поиска, рекомендаций и дополнительных списков

6. Настроить select_item для кликов по товарам в списках

7. Настроить view_item для просмотра карточки

8. Настроить add_to_cart, remove_from_cart, view_cart

9. Настроить begin_checkout

10. Настроить add_shipping_info и add_payment_info

11. Настроить purchase с уникальным номером заказа

12. Разметить показы и клики по промо-блокам

13. Передавать внутренний поиск через search

14. Настроить события регистрации, авторизации, подписки и «Поделиться»

15. Проверить отсутствие дублей

16. Сверить суммы заказов с CMS

17. Проверить, что в аналитику не уходят персональные данные