Без корректной аналитики электронной коммерции магазин управляется вслепую. Вы видите, что заказы есть, но не знаете, какие товары чаще смотрят и бросают в корзине, на каком шаге оформления теряются покупатели и какая реклама реально окупается. Расширенная электронная коммерция закрывает эту слепоту: она передаёт в аналитику весь путь покупателя — от просмотра списка до оплаченного заказа с его составом и суммой. Но именно на событии покупки чаще всего и ошибаются, а неверная аналитика хуже её отсутствия, потому что ведёт к неверным решениям.
В статье разберём, как настроить расширенную электронную коммерцию на 1С-Битрикс: какие события отправлять, что такое dataLayer, как реализовать событие покупки без дублей и как всё это проверить. Материал полезен и маркетологу, и разработчику. Если аналитика — часть большой задачи по наведению порядка в магазине, начать стоит с аудита и оптимизации 1С, который свяжет данные с реальными узкими местами.
Коротко
- Расширенная коммерция передаёт весь путь: просмотр, клик, корзина, оформление, покупка с составом заказа.
- События удобно складывать в dataLayer, а рассылать по системам через менеджер тегов.
- Событие покупки — самое важное: его отправляют один раз на заказ и защищают от дублей по идентификатору.
- Для надёжности покупку дублируют серверной отправкой и проверяют в режиме отладки до запуска рекламы.
Что такое расширенная электронная коммерция
Обычная веб-аналитика считает визиты, источники и цели: «пришло N человек, M оформили заказ». Этого мало, чтобы управлять магазином. Расширенная электронная коммерция добавляет товарное измерение: она передаёт события по всему пути покупателя вместе с данными о товарах, ценах и заказе. Становится видно, какие позиции смотрят, добавляют в корзину и покупают, где обрывается воронка и какая реклама приносит деньги, а не просто клики.
Что это даёт бизнесу:
- Товарная аналитика. Какие товары популярны на просмотре, а какие — на покупке.
- Воронка оформления. На каком шаге теряются заказы и сколько.
- Окупаемость рекламы. Связь заказа с источником и оценка возврата вложений.
- Основа для ремаркетинга. Брошенные корзины и просмотренные товары для возврата покупателей.
Полный набор событий покупателя
Расширенная коммерция — это последовательность событий, повторяющая путь покупателя. Важно передавать их все, а не только покупку, иначе воронка будет неполной.
| Событие | Когда срабатывает | Что передаёт |
|---|---|---|
| Просмотр списка | Открытие каталога/подборки | Список товаров и их позиции |
| Клик по товару | Переход из списка в карточку | Товар и место клика |
| Просмотр товара | Открытие карточки | Товар, цена, категория |
| Добавление в корзину | Клик «Купить» | Товар, количество, цена |
| Начало оформления | Переход в чекаут | Состав корзины |
| Покупка | Создание заказа | Заказ, товары, сумма, доставка |
Каждое событие несёт данные о товарах в едином формате, чтобы система аналитики могла связать их в цельную картину. Начинать внедрение стоит с покупки и корзины как самых ценных, а затем достраивать просмотры и клики.
dataLayer и менеджер тегов
Технически события удобнее всего складывать в dataLayer — слой данных на странице, промежуточный буфер между сайтом и системами аналитики. Сайт кладёт события в dataLayer в едином формате, а менеджер тегов забирает их оттуда и рассылает в нужные системы.
Такая схема развязывает разработку и маркетинг: разработчику достаточно один раз научить сайт наполнять dataLayer, а маркетолог сам подключает и меняет теги, не трогая код. Это удобно и снижает число правок сайта ради аналитики.
События каталога и карточки
Верхняя часть воронки — просмотры и клики — показывает, что привлекает внимание ещё до корзины. Эти события наполняют из шаблонов каталога и карточки товара.
- Просмотр списка. При открытии каталога или подборки в dataLayer кладётся список показанных товаров с их позициями.
- Клик по товару. При переходе в карточку фиксируется, какой товар и из какого списка выбрали.
- Просмотр товара. При открытии карточки передаются товар, цена и категория.
Эти данные помогают понять, какие товары притягивают внимание, но плохо конвертируются в покупку, и наоборот. Наполняются они из компонентов каталога 1С-Битрикс, где уже есть все нужные свойства товара — их остаётся аккуратно вывести в слой данных.
Корзина и шаги оформления
Средняя часть воронки — самая денежная: здесь покупатель уже проявил намерение, и здесь же чаще всего теряется. Поэтому события корзины и оформления настраивают особенно тщательно.
- Добавление в корзину. При клике «Купить» в dataLayer уходит товар, количество и цена.
- Удаление из корзины. Тоже полезно фиксировать — что и как часто убирают.
- Начало оформления. Переход в чекаут с полным составом корзины.
- Шаги чекаута. Ввод контактов, выбор доставки и оплаты — чтобы видеть, где обрыв.
Данные о корзине берут из объекта корзины модуля «Интернет-магазин», а шаги оформления — из компонента sale.order. Так события точно соответствуют тому, что реально в корзине и заказе. Аналитику шагов оформления мы подробно затрагивали в контексте мобильного чекаута — эти данные показывают, какое поле или шаг отпугивает покупателя.
Событие покупки — главное
Если во всей аналитике выделить одно событие, это покупка. Именно она связывает заказ с его товарами, суммой, доставкой и источником трафика — на ней строится вся аналитика окупаемости. Ошибка в событии покупки искажает главные бизнес-показатели, поэтому его настраивают и проверяют тщательнее всего.
Событие покупки должно передавать полный и достоверный набор данных:
- Идентификатор заказа. Уникальный номер, по которому отсекаются дубли.
- Состав заказа. Все товары с количеством и ценами.
- Итоговую сумму. С учётом скидок и доставки, совпадающую с реальным заказом.
- Способ доставки и оплаты. Для сегментации и анализа.
Отправляют его один раз — на странице благодарности за заказ или через обработчик события создания заказа. Данные берут из созданного заказа, а не из корзины, чтобы сумма и состав были финальными.
Клиент, сервер и защита от дублей
Главная беда события покупки — дубли. Покупатель обновляет страницу благодарности или возвращается на неё кнопкой «назад», и событие срабатывает снова: один заказ считается несколько раз, выручка в отчётах завышается, атрибуция ломается. Защита строится на двух принципах.
- Привязка к заказу. Событие отправляется с идентификатором заказа; повторная отправка того же идентификатора игнорируется.
- Отправка один раз. Флаг «покупка по этому заказу уже отправлена» не даёт задвоить при перезагрузке.
Для надёжности покупку часто дублируют серверной отправкой. Клиентская (через dataLayer в браузере) проще, но зависит от блокировщиков и обрывов связи; серверная берёт данные из достоверного источника — созданного заказа — и не теряется. Многие магазины отправляют покупку и с клиента, и с сервера, а затем убирают дубли по идентификатору заказа. Серверные события отправляют по защищённым каналам — как безопасно устроить такие интеграции, мы разбирали в статье про безопасность REST и вебхуков в 1С-Битрикс. А накапливать и сверять отправленные события удобно через современный слой доступа к данным — D7 и ORM в 1С-Битрикс позволяют вести журнал отправок аккуратно.
Реализация в 1С-Битрикс
Сборка расширенной коммерции на 1С-Битрикс идёт по понятной последовательности. Данные о товарах и заказах уже есть в модуле «Интернет-магазин» — задача в том, чтобы аккуратно вывести их в слой данных и события.
- Спроектируйте формат событий. Единая структура для товара и заказа во всех событиях.
- Наполните dataLayer в шаблонах. Каталог, карточка, корзина и чекаут кладут события из данных компонентов.
- Настройте событие покупки. На странице благодарности и/или через обработчик создания заказа, с идентификатором и защитой от дублей.
- Добавьте серверную отправку. Для покупки — как надёжный дубль клиентской.
- Подключите менеджер тегов. Он забирает события из dataLayer и рассылает по системам.
- Проверьте всё в отладке. До запуска рекламы, на реальных заказах.
Изменения в шаблонах и обработчиках лучше выкатывать через выстроенный процесс, чтобы не сломать боевой магазин правкой аналитики. Как устроен безопасный деплой с окружениями и откатом, мы описали в статье про CI/CD и деплой для 1С-Битрикс.
Отладка и проверка данных
Аналитику нельзя «настроить и забыть» — её обязательно проверяют, потому что тихая ошибка неделями копит искажённые данные. Отладку проводят до запуска рекламных кампаний.
- Режим предпросмотра менеджера тегов. Видно, какие события и с какими данными срабатывают.
- Консоль браузера. Проверка содержимого dataLayer на каждом шаге.
- Отчёты реального времени. Событие покупки доходит до аналитики и не задваивается.
- Сверка с заказом. Состав, цены и сумма в событии совпадают с реальным заказом.
Особое внимание — событию покупки: его прогоняют на нескольких реальных заказах, проверяют отсутствие дублей при перезагрузке и совпадение сумм. Только после этого аналитике можно доверять для решений.
Скорость и контроль тегов
Аналитика не должна замедлять магазин. При аккуратной реализации её влияние на скорость минимально, но проблемы возникают, когда через менеджер тегов на страницу навешивают десятки скриптов и виджетов без контроля.
- Асинхронная загрузка. Скрипты аналитики не блокируют отрисовку страницы.
- Данные с сервера. dataLayer наполняется без тяжёлых вычислений в браузере.
- Ревизия тегов. Регулярно проверяют, какие теги реально нужны, и убирают лишние.
- Осторожность со сторонним. Тяжёлые внешние виджеты — под вопросом, они бьют по скорости.
Скорость витрины — отдельная большая тема, тесно связанная с конверсией. Держать её высокой помогает и продуманное кэширование, и лёгкие шаблоны, и контроль над сторонними скриптами.
Частые ошибки настройки
- Дубли события покупки. Перезагрузка страницы благодарности задваивает заказ и выручку.
- Сумма из корзины, а не из заказа. Скидки и доставка не учтены, цифры не сходятся.
- Нет идентификатора заказа. Невозможно отсечь дубли и связать данные.
- Только клиентская отправка. Блокировщики и обрывы теряют часть покупок.
- Разный формат событий. Разбор данных ломается, отчёты недостоверны.
- Запуск без отладки. Ошибку замечают через месяцы искажённой аналитики.
- Свалка тегов. Десятки неконтролируемых скриптов замедляют сайт.
Чек-лист внедрения
- Формат событий единый. Товар и заказ описаны одной структурой во всех событиях.
- Воронка полная. Просмотр, клик, карточка, корзина, оформление, покупка передаются.
- dataLayer наполняется в шаблонах. Данные берутся из компонентов, а не хардкодятся.
- Покупка настроена верно. Идентификатор заказа, полный состав, итоговая сумма из заказа.
- Дубли исключены. Событие покупки отправляется один раз на заказ.
- Серверная отправка есть. Покупка продублирована с сервера для надёжности.
- Отладка пройдена. Проверено на реальных заказах до запуска рекламы.
- Теги под контролем. Лишние скрипты убраны, скорость не пострадала.
Вывод
Расширенная электронная коммерция превращает магазин из «чёрного ящика» в управляемую систему: видно, какие товары смотрят и бросают, где теряются заказы и какая реклама окупается. Технически это последовательность событий по всему пути покупателя, сложенных в dataLayer и разосланных через менеджер тегов, а данные для них уже есть в модуле «Интернет-магазин» 1С-Битрикс.
Ключ ко всей аналитике — событие покупки: отправленное один раз, с идентификатором заказа, полным составом и итоговой суммой, продублированное с сервера и проверенное в отладке. Настройте его без дублей и ошибок — и остальные отчёты станут надёжной опорой для решений, а не источником ложных выводов. Собрать корректную аналитику и связать её с автоматизацией помогут наши услуги автоматизации на 1С и аудита и оптимизации 1С.
