«Заказов стало меньше» — а где именно вы их теряете? В карточке, в корзине, на доставке или на оплате? Если вы считаете только сами заказы, ответа нет: вы видите результат, но не место утечки. Чтобы чинить конверсию точечно, нужно отслеживать всю воронку — каждое добавление в корзину и каждый шаг оформления, а не только финал.
В этой статье разберём, как настроить корректное отслеживание добавлений в корзину и оформлений в магазине на 1С-Битрикс: что такое dataLayer, какие события ловить, где брать данные из модуля «Интернет-магазин» и события `sale.order`, зачем нужны серверные события и дедупликация. Навести порядок в этих механизмах помогает аудит и оптимизация 1С.
Коротко
- Считать только заказы недостаточно — нужна вся воронка, чтобы видеть, где теряются покупатели.
- Стандартный способ — dataLayer: сайт складывает события в единый слой, аналитика читает их через тег-менеджер.
- Данные берите из штатных механизмов Битрикса: корзина (Sale\Basket), заказ (Sale\Order), каталог — а не из DOM.
- Ключевое событие покупки дублируйте серверно и дедуплицируйте по id заказа, чтобы не потерять и не задвоить.
Почему заказ — не первое, что надо считать
Заказ — это конец пути, и по нему одному невозможно понять, что происходит по дороге. Представьте: заказов стало на треть меньше. Причина может быть где угодно — упал трафик, сломалась кнопка «в корзину», выросла стоимость доставки, отвалилась оплата. Одна цифра заказов не различает эти сценарии, а значит, не подсказывает, что чинить.
Поэтому отслеживание строят не от заказа, а от воронки. Нужно видеть каждый шаг: сколько посмотрели товар, сколько добавили в корзину, сколько начали оформление, сколько дошли до оплаты. Тогда падение локализуется: «добавлений столько же, но оформлений вдвое меньше — проблема в корзине или доставке». Это превращает аналитику из констатации в инструмент.
Воронка e-commerce по шагам
Стандартная воронка интернет-магазина — это последовательность событий, между которыми теряются покупатели:
| Шаг | Событие | О чём говорит потеря |
|---|---|---|
| 1 | Просмотр товара | Проблема с трафиком или релевантностью |
| 2 | Добавление в корзину | Карточка, цена, наличие не убеждают |
| 3 | Начало оформления | Корзина, доставка, стоимость отпугивают |
| 4 | Ввод данных и доставки | Форма сложная, мало способов доставки |
| 5 | Оплата (покупка) | Проблемы с оплатой или доверием |
Каждый переход между шагами — это конверсия, которую можно измерить и улучшать. Смысл трекинга в том, чтобы каждый из этих шагов стал событием с данными, и вы видели не только «сколько заказов», но и «сколько отвалилось на переходе 3→4 и почему».
dataLayer как единый слой данных
Технически связать сайт и системы аналитики удобнее всего через dataLayer — промежуточный слой данных на странице. Это JavaScript-массив, куда сайт складывает события и их параметры в едином формате, а тег-менеджер читает их оттуда и передаёт в нужные системы аналитики.
Зачем эта прослойка:
- Развязка ролей. Разработчик один раз выводит корректные события с данными, маркетолог настраивает передачу без правок кода.
- Единый формат. Одни и те же данные о товарах уходят во все системы одинаково.
- Гибкость. Добавить новую систему аналитики — вопрос настройки тегов, а не переделки сайта.
- Отладка. Содержимое dataLayer видно в режиме отладки — легко проверить, что и с какими данными сработало.
Ключевой принцип: сайт отвечает за то, чтобы в dataLayer попали правильные события с точными данными о товарах и заказе. Всё остальное — настройка передачи — делается поверх, без вмешательства в код магазина.
Какие события отслеживать
Базовый набор e-commerce событий, которого достаточно для полноценной воронки:
- Просмотр списка и товара. Какие категории и карточки смотрят, с какими данными о товаре.
- Добавление и удаление из корзины. Ключевые сигналы намерения и сомнения.
- Просмотр корзины и начало оформления. Переход от «положил» к «покупаю».
- Шаги оформления. Контакты, доставка, оплата как отдельные шаги воронки.
- Покупка. Финальное событие с составом заказа, суммой и id — самое важное.
Каждое событие несёт параметры: id товара, артикул, название, цену, категорию, количество, а для покупки — состав заказа и сумму. Именно точность этих параметров определяет ценность аналитики: без корректных данных о товарах воронка есть, а понять, что и почём покупают, нельзя.
Где брать данные в 1С-Битрикс
Главная ошибка трекинга — парсить данные из HTML-разметки (DOM). Это хрупко: поменялась вёрстка — сломался трекинг, а цены и id легко считать неверно. Правильный источник — штатные механизмы модуля «Интернет-магазин»:
- Каталог и карточка. Данные о товаре (id, артикул, название, цена, раздел) берутся при выводе товара, а не выдёргиваются из вёрстки.
- Корзина (Sale\Basket). Состав корзины и её изменения — источник событий добавления и удаления.
- Заказ (Sale\Order). Созданный заказ с составом и суммой — источник события покупки.
- Свойства и торговый каталог. Категория, бренд, вариант (SKU) для точной атрибуции.
Привязка трекинга к серверным сущностям Битрикса даёт точные данные, совпадающие с реальным заказом. Работать с этими объектами чисто и производительно помогает современный слой доступа — принципы мы разбираем в статье про D7 ORM в Битрикс.
Событие добавления в корзину
Добавление в корзину — самый частый и важный промежуточный сигнал. Оно происходит из разных мест: карточки, списка товаров, блока рекомендаций, быстрого просмотра. Задача — ловить его везде и с одинаковыми данными.
Что учесть при настройке события добавления:
- Все точки добавления. Карточка, каталог, рекомендации, быстрый заказ — событие срабатывает из каждой.
- Правильный товар. Для товара с вариантами передаётся именно выбранный SKU (размер, цвет), а не родитель.
- Актуальная цена. Цена в событии — та, что видит покупатель, включая цену его группы в B2B.
- Количество. Если добавили несколько штук — количество попадает в событие.
Отдельное внимание — асинхронному добавлению без перезагрузки (AJAX). Событие должно уходить именно в момент успешного добавления в корзину на сервере, а не при клике по кнопке: иначе вы посчитаете и неудачные попытки. Привязка к ответу сервера делает событие достоверным.
События оформления по шагам
Оформление заказа — самая «протекающая» часть воронки, и её надо разложить на шаги. В 1С-Битрикс оформление может быть одностраничным или пошаговым, но логически всегда есть этапы: старт оформления, ввод контактов, выбор доставки, выбор оплаты, подтверждение.
Отслеживание каждого шага показывает, где именно покупатель бросает заказ. Много начавших оформление, но мало выбравших доставку — проблема в способах или стоимости доставки. Много выбравших доставку, но мало дошедших до оплаты — сложная форма или недоверие к оплате. Без разбивки на шаги вы видите только «начал — не купил», без понимания причины. Эти же данные о поведении в оформлении питают и персонализацию — как её выстроить, мы разбираем в статье про гиперперсонализацию витрины.
Событие покупки и sale.order
Покупка — главное событие, ради которого существует вся воронка, и к нему требования строже всего. Ловить его надо в момент реального создания заказа, а данные брать из объекта заказа (Sale\Order), а не со страницы «спасибо».
Правильно привязать событие покупки к серверным событиям модуля продаж — обработчикам создания заказа. Тогда в событие попадают достоверные данные: id заказа, полный состав, суммы, примённые скидки. Это надёжнее, чем полагаться на JavaScript на странице успеха, которую пользователь может перезагрузить, закрыть до отработки скрипта или не увидеть из-за блокировщика. Как аккуратно работать с серверными событиями и внешними системами, мы описали в материале про REST, вебхуки и безопасность в Битрикс.
Серверные события и дедупликация
Клиентские события (в браузере) неизбежно теряются: блокировщики, отключённый JavaScript, сбои сети, ограничения браузеров. Для промежуточных шагов это терпимо, но для покупки — нет: терять данные о выручке недопустимо. Поэтому ключевое событие покупки дублируют серверно.
Серверное событие отправляется с вашего сервера напрямую в аналитику при создании заказа — его не блокирует браузер. Но если слать покупку и с клиента, и с сервера, возникает риск задвоения. Решает его дедупликация:
- Единый id заказа. И клиентское, и серверное событие несут один и тот же уникальный идентификатор заказа.
- Склейка по id. Аналитика по id понимает, что это одно событие, и не считает дважды.
- Гибридная надёжность. Клиентское событие ловит поведение, серверное гарантирует, что покупка не потеряется.
- Идемпотентность. Повтор запроса с тем же id не создаёт вторую покупку.
Такой гибрид клиент + сервер с дедупликацией — современный стандарт для достоверного учёта покупок. Он совмещает полноту поведенческих данных с надёжностью серверного подтверждения выручки.
Кэш, композит и скорость
Трекинг не должен замедлять сайт и не должен ломаться на кэшированных страницах. Два технических момента, которые важно проверить:
- Асинхронная загрузка. Тег-менеджер и пиксели подключаются асинхронно, не блокируя отрисовку страницы.
- Работа с композитом. На композитном сайте страница отдаётся из кэша — динамические данные (id товара, сумма) должны попадать в dataLayer и в этом случае.
- Без дублей пикселей. Одинаковые счётчики не подключаются дважды — это и лишняя нагрузка, и задвоение событий.
- Проверка на кэше. События тестируются именно на закэшированных страницах, а не только на «свежих».
Композитный сайт и кэш ускоряют магазин, но добавляют нюанс: динамическая часть страницы, откуда берутся данные для событий, приходит отдельно. Убедитесь, что трекинг корректно срабатывает и на статике из кэша, и на догружаемой динамике, иначе часть событий потеряется незаметно.
Частые ошибки трекинга
- Считают только заказы. Нет воронки — не видно, где теряются покупатели.
- Парсят DOM. Данные берут из вёрстки; смена дизайна ломает трекинг, цены и id неверны.
- Событие на клик, а не на успех. Добавление считается даже при неудачной попытке.
- Покупка со страницы «спасибо». Перезагрузка задваивает выручку, блокировщик теряет событие.
- Нет серверного подтверждения. Ключевое событие покупки теряется из-за браузеров и сети.
- Нет дедупликации. Клиент и сервер шлют покупку без единого id — выручка задваивается.
- Не проверяют на кэше. На композитных страницах события молча не срабатывают.
Чек-лист внедрения
- Воронка определена. Выбраны шаги от просмотра товара до оплаты, каждый станет событием.
- dataLayer внедрён. Сайт складывает события с точными данными о товарах в единый слой.
- Данные из Битрикса. Источник — корзина, заказ и каталог модуля «Интернет-магазин», а не DOM.
- Добавление корректно. Событие ловится из всех точек, с нужным SKU, ценой и по факту успеха.
- Шаги оформления считаются. Старт, доставка, оплата разложены на события воронки.
- Покупка надёжна. Событие привязано к созданию заказа (sale.order), дублируется серверно, дедуплицируется по id.
- Скорость и кэш проверены. Трекинг асинхронный, работает на композитных страницах, без дублей.
- Сверка с 1С-Битрикс. Число покупок в аналитике совпадает с числом заказов за период.
Вывод
Отслеживание добавлений в корзину и оформлений — это не про «поставить счётчик», а про то, чтобы видеть всю воронку и точно знать, где теряются покупатели. Считать только заказы — значит видеть результат без причины. Разложите путь на события: просмотр, добавление, шаги оформления, покупка — и падения станут локализуемыми, а улучшения точечными.
Технически это dataLayer как единый слой данных, события из штатных механизмов 1С-Битрикс (корзина, заказ, каталог), а не из вёрстки, и надёжная фиксация покупки: серверное подтверждение через события sale.order с дедупликацией по id заказа. Проверьте работу на кэше и сверьте покупки с заказами в 1С — и ваша аналитика превратится из красивых графиков в инструмент, который реально помогает растить конверсию.
