Яндекс.Метрика и GA4 в интернет-магазине на Битрикс

Владелец магазина открывает Яндекс.Метрику, видит «1200 визитов и 18 конверсий» и не понимает главного: какие товары смотрели, что клали в корзину и на каком шаге оформления теряли покупателей. Обычный счётчик считает страницы и клики, но не видит товар как объект — цену, категорию, количество, доход. Всё это открывает только правильно подключённая электронная коммерция в Метрике и GA4: события просмотра, добавления в корзину, оформления и покупки, привязанные к конкретным SKU.

Ниже — практическая инструкция, как подключить товарную аналитику в интернет-магазине на 1С-Битрикс так, чтобы цифры сходились с реальными продажами: единый слой данных dataLayer, стандартные события Метрики и GA4, цели и отчёты, согласие на cookie и проверка данных. Это выжимка из наших проектов по интеграции сервисов с 1С-Битрикс — без теории ради теории, только то, что реально влияет на выручку и решения.

Зачем магазину корректная e-commerce-аналитика

Базовый счётчик Метрики или GA4 из коробки отвечает на вопросы «сколько людей пришло» и «сколько страниц посмотрели». Для контентного сайта этого достаточно, для магазина — нет. Магазину нужны ответы на другие вопросы: какие товары чаще смотрят, но не покупают; на каком шаге оформления отваливается больше всего людей; какой канал приводит покупателей с высоким средним чеком; какие категории дают выручку, а какие только съедают рекламный бюджет.

Все эти ответы даёт электронная коммерция — расширение аналитики, которое учит систему видеть не абстрактные «события», а товары и деньги. Когда e-commerce подключён корректно, каждый просмотр карточки, каждое добавление в корзину и каждая покупка передаются с полным набором атрибутов: идентификатор, название, категория, бренд, цена, количество, а для заказа ещё и общая сумма, стоимость доставки и промокод.

Разница между «есть счётчик» и «есть товарная аналитика» — это разница между управлением магазином вслепую и по приборам. Без e-commerce вы оптимизируете рекламу по кликам и заявкам, не зная реального дохода с канала. С e-commerce вы видите ROMI по каждому источнику, ассортиментные отчёты и точную воронку от просмотра до оплаты. Именно поэтому подключение электронной коммерции — это не «галочка для галочки», а фундамент, на котором стоит вся дальнейшая работа с продвижением и конверсией.

Отдельно стоит подчеркнуть: корректная e-commerce-аналитика — это ещё и общий язык между маркетологом, разработчиком и владельцем. Когда все смотрят на одни и те же события с одинаковыми идентификаторами товаров, спор «у меня в рекламном кабинете одно, а в CRM другое» решается сверкой, а не догадками. Данные перестают быть предметом веры и становятся инструментом.

Метрика и GA4: в чём разница и зачем обе

Первый вопрос, который возникает при внедрении: ставить Яндекс.Метрику, Google Analytics 4 или обе системы сразу. Универсального ответа нет — всё зависит от рынка, рекламных каналов и требований к отчётности. Но понимать сильные стороны каждой системы полезно, чтобы принять осознанное решение.

Яндекс.Метрика — базовый инструмент для магазина, работающего на российском рынке. Она бесплатна без ограничений на объём, из коробки даёт вебвизор (запись действий посетителей), карты кликов и скроллинга, отчёт «Товары» и «Заказы» по данным электронной коммерции, а также бесшовно связывается с Яндекс.Директом. Для большинства магазинов на 1С-Битрикс именно Метрика становится основной системой аналитики.

Google Analytics 4 строится на событийной модели: в ней вообще всё — событие, включая просмотр страницы. GA4 силён гибкостью, связкой с Google Ads, бесплатным экспортом сырых данных в BigQuery и сквозной аналитикой по нескольким сайтам и приложениям. Его подключают, когда важны Google-каналы, международные рынки или продвинутая работа с данными на стороне аналитика.

Хорошая новость: формат данных электронной коммерции у Метрики и GA4 практически одинаковый — обе системы понимают структуру dataLayer, унаследованную от Google. Это значит, что событие о покупке можно сформировать один раз, а прочитают его обе системы. Именно поэтому мы не рекомендуем городить отдельный код под каждую аналитику — правильная архитектура строится вокруг единого слоя данных, о котором пойдёт речь ниже.

Модель данных электронной коммерции

Чтобы события отправлялись корректно, важно понимать, из каких сущностей состоит модель e-commerce. Она проще, чем кажется, и вращается вокруг трёх понятий: товар, действие и заказ.

• Товар (product / item). Минимальная единица данных. Обязательные поля — идентификатор и название; желательные — категория, бренд, цена, количество, вариант (например, размер или цвет), позиция в списке.
• Действие (event). Что произошло с товаром: его показали в списке, кликнули, посмотрели карточку, добавили или убрали из корзины, начали оформление, оплатили. Каждое действие — отдельное событие со своим набором товаров.
• Заказ (purchase / transaction). Финальное событие с итоговыми суммами: идентификатор заказа, доход, стоимость доставки, налоги, купон и список купленных товаров с ценами и количествами.

Ключевое требование модели — сквозная согласованность идентификаторов. Один и тот же товар во всех событиях должен иметь один и тот же id. Если на карточке товар передаётся с артикулом SKU-100, а в корзине — с внутренним ID элемента инфоблока 4821, системы будут считать это двумя разными товарами, и товарная воронка развалится. Поэтому в 1С-Битрикс важно заранее выбрать, какое поле служит идентификатором: как правило, это внешний код (артикул) из свойств элемента каталога.

Второй важный аспект — валюта и цены. Цену передавайте числом в основной валюте магазина, без символов и разделителей разрядов. Для мультивалютных магазинов приводите цену к одной отчётной валюте, иначе доход в отчётах будет складывать рубли с условными единицами. Количество — всегда целое число единиц товара в этом событии.

dataLayer как единый источник событий

dataLayer — это глобальный массив JavaScript на странице, в который сайт складывает структурированные данные о происходящем. Идея простая: вместо того чтобы под каждую систему аналитики писать свой код отправки событий, сайт один раз кладёт в dataLayer объект «случилось добавление в корзину, вот товар и его атрибуты», а дальше уже Метрика, GA4 и Google Tag Manager сами забирают эти данные и отправляют их каждый в свою систему.

Такая архитектура — единый источник правды — избавляет от двух главных бед плохой аналитики: дублирующего кода и расхождений между системами. Если товар попал в dataLayer один раз с ценой 12490 и артикулом SKU-100, то ровно эти же значения увидят и Метрика, и GA4. Никакой ситуации «в одной системе цена с копейками, в другой округлённая» просто не возникает.

Технически событие в dataLayer для Метрики выглядит так — объект с ключом ecommerce, внутри которого действие (add, remove, detail, purchase) и массив товаров:

Важный практический нюанс: dataLayer должен быть объявлен до подключения счётчиков, чтобы события, произошедшие в самом начале загрузки (например, просмотр карточки), не потерялись. В шаблоне сайта на 1С-Битрикс объявление window.dataLayer = window.dataLayer || []; ставят как можно выше в <head>, ещё до кода Метрики и GA4. Тогда любое раннее событие спокойно дождётся инициализации систем и будет обработано.

Ещё одно правило хорошего тона — очищать объект ecommerce перед отправкой нового события (dataLayer.push({ ecommerce: null }) в связке с GTM). Иначе данные предыдущего события могут «прилипнуть» к следующему, и, скажем, в покупку попадут товары, оставшиеся от просмотра списка. Это одна из самых коварных причин задвоенных или искажённых данных.

Ключевые события товарной аналитики

Полноценная воронка магазина состоит из нескольких стандартных событий. Их набор в Метрике и GA4 почти совпадает — различаются только названия. Ниже — минимально необходимый набор, который стоит внедрить на любом магазине.

Самое важное событие — purchase. Именно оно приносит в аналитику деньги, и именно с ним чаще всего связаны ошибки. Три правила для покупки: отправлять её строго один раз, строго на финальной странице «Заказ оформлен» и с полным составом заказа. Если purchase срабатывает по клику на кнопку «Оформить» (а не после успешного создания заказа), в аналитику попадут и брошенные оформления. Если страница благодарности отправляет событие при каждой перезагрузке — покупки задвоятся.

События верхней части воронки — показы и клики в списке — часто откладывают «на потом», и зря. Именно они показывают, какие товары привлекают внимание в каталоге, а какие остаются незамеченными. В связке с событием добавления в корзину это даёт понимание конверсии на уровне отдельного товара: посмотрели 1000 раз, в корзину положили 40, купили 8.

Электронная коммерция в Яндекс.Метрике

В Яндекс.Метрике электронная коммерция включается в настройках счётчика и работает через тот самый dataLayer. Порядок подключения выглядит так:

1. Включите e-commerce в счётчике. В настройках счётчика Метрики на вкладке «Счётчик» найдите блок «Электронная коммерция», поставьте галочку и укажите имя контейнера данных — по умолчанию dataLayer.
2. Объявите контейнер до счётчика. В шаблоне сайта добавьте window.dataLayer = window.dataLayer || []; в самом верху, до кода счётчика Метрики.
3. Настройте передачу событий. В шаблонах компонентов каталога и корзины эмитируйте события detail, add, remove, purchase с массивом товаров и валютой.
4. Проверьте в отчётах. Через несколько часов после первых заказов в разделе отчётов Метрики появятся «Товары», «Заказанные товары», «Популярные категории» и «Заказы».
5. Свяжите с Директом. Если ведёте рекламу в Яндекс.Директе, привяжите счётчик — тогда доход и ROMI по кампаниям будут считаться на данных электронной коммерции.

Метрика ожидает данные в структуре, совместимой с исходным форматом Google Enhanced Ecommerce: объект ecommerce с ключами currencyCode и действиями. Это удобно: один и тот же dataLayer.push кормит и Метрику, и GTM, который отправит данные в GA4. Отдельно отметим отчёт «Заказы» — он появляется, только если в событии purchase передан идентификатор заказа и его сумма; без них Метрика посчитает товары, но не сами заказы.

Сильная сторона Метрики для магазина — связка e-commerce с вебвизором. Увидев в отчёте, что товар часто кладут в корзину, но не покупают, вы можете открыть записи сессий по этому товару и увидеть, где именно спотыкаются посетители: непонятная доставка, обязательная регистрация, ошибка на шаге оплаты. Это переводит аналитику из режима «числа» в режим «понимание поведения».

Электронная коммерция в GA4

В Google Analytics 4 всё событийно, и электронная коммерция — это набор зарезервированных событий с параметром items. Подключить их можно двумя путями: напрямую через gtag или, что удобнее, через Google Tag Manager, читающий события из dataLayer.

1. Создайте ресурс и поток данных GA4. Получите идентификатор измерения (Measurement ID вида G-XXXXXXX) и установите базовый тег на сайт.
2. Подключите Google Tag Manager. Контейнер GTM удобно вешать на весь сайт один раз, а внутри настраивать теги GA4 и Метрики без правки кода шаблона под каждое событие.
3. Настройте события ecommerce. На каждое действие (view_item, add_to_cart, begin_checkout, purchase) создайте триггер по событию dataLayer и тег GA4 с передачей параметра items.
4. Пометьте покупку. В событии purchase обязательно передайте transaction_id, value, currency и массив items; GA4 использует transaction_id для дедупликации заказов.
5. Проверьте в DebugView. Режим отладки GA4 показывает события в реальном времени с их параметрами — это лучший способ убедиться, что данные уходят корректно.

Формат items в GA4 немного отличается именами полей от формата Метрики: там item_id, item_name, item_category, item_brand, price, quantity. Если вы используете GTM, преобразование из «метричного» dataLayer в «джиэй-четвёрочный» items удобно сделать переменной-маппером внутри контейнера — так исходный слой данных остаётся один, а каждый тег берёт из него нужный формат.

Ценная особенность GA4 — бесплатный экспорт сырых событий в BigQuery. Для магазина это означает возможность строить любые нестандартные отчёты: когорты покупателей, LTV, детальную атрибуцию. Но это уже уровень аналитика-инженера; для старта достаточно стандартных отчётов «Монетизация» и «Покупки», которые GA4 собирает автоматически из событий электронной коммерции.

Реализация в 1С-Битрикс

Теперь самое практичное — как всё это внедряется именно в 1С-Битрикс. Платформа устроена компонентно, и события электронной коммерции удобно эмитировать из шаблонов соответствующих компонентов каталога и корзины. Разберём по шагам, где что живёт.

1. Определите идентификатор товара. Решите, какое поле служит id для аналитики: артикул, внешний код или символьный код элемента инфоблока. Главное — стабильность при обмене с 1С. Внутренний числовой ID лучше не использовать: он может пересоздаться.
2. Объявите dataLayer в шаблоне. В файле header.php вашего шаблона сайта, до подключения счётчиков, добавьте инициализацию window.dataLayer = window.dataLayer || [];.
3. Событие просмотра карточки. В шаблоне компонента bitrix:catalog.element сформируйте dataLayer.push с действием detail и данными текущего товара из $arResult.
4. Список и клики. В шаблоне bitrix:catalog.section и блоков рекомендаций эмитируйте показы (impressions / view_item_list) и клики по товару.
5. Добавление и удаление из корзины. Компонент bitrix:sale.basket.basket и AJAX-добавление в корзину — точки для событий add и remove. Здесь важно ловить именно фактическое изменение корзины, а не клик.
6. Покупка. На странице завершения заказа (компонент bitrix:sale.order.ajax, шаг «Заказ оформлен») эмитируйте purchase с номером заказа, суммой, доставкой и составом. Данные берите из объекта заказа, а не из корзины, которая к этому моменту уже очищена.

Ключевой архитектурный принцип — не править файлы дистрибутива. Все вставки делайте в собственном шаблоне сайта и в скопированных шаблонах компонентов (.default → ваш шаблон), иначе обновление платформы затрёт правки. Это стандартная практика 1С-Битрикс, о которой легко забыть в спешке.

Отдельно про событие покупки на странице благодарности. В 1С-Битрикс страница «Заказ оформлен» может открываться повторно (пользователь нажал «назад», обновил страницу, вернулся по ссылке из письма). Чтобы purchase не задваивался, привяжите отправку к признаку «заказ только что создан» — например, через флаг в сессии, который взводится один раз при создании заказа и гасится после отправки события. Это надёжнее, чем полагаться только на дедупликацию по transaction_id на стороне аналитики.

Если магазин работает с CRM и сквозной аналитикой, события сайта имеет смысл дополнить серверной передачей заказов. Тогда покупки, оформленные по телефону или менеджером, тоже попадут в общую картину. Как это выстроить сквозным контуром, мы разбираем в материале про сквозную аналитику Битрикс24 для интернет-магазина, а более широкий контур на данных сайта и рекламы — в статье про сквозную аналитику e-commerce на Битрикс.

Как это выглядит в админке и коде

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

Обратите внимание на пару в коде: числовой доход revenue и строковый идентификатор заказа id. Доход — всегда число без символов валюты и пробелов-разделителей, идентификатор — стабильная строка, совпадающая с номером заказа в 1С-Битрикс. Именно по этому номеру потом сверяют выручку в аналитике с реальными заказами в CRM и бухгалтерии.

Цели, конверсии и воронка

События электронной коммерции описывают, что происходит с товарами, но бизнесу нужны ещё и цели — измеримые действия, которые считаются конверсиями. В Метрике и GA4 подход немного разный.

В Яндекс.Метрике цели настраиваются отдельно от e-commerce: это может быть посещение страницы «Спасибо за заказ», JavaScript-событие, клик по кнопке или составная цель. Для магазина ключевая цель — оформленный заказ; её удобно завязать на то же условие, что и событие purchase, чтобы конверсии и доход считались согласованно. Дополнительно полезны микроцели: добавление в корзину, переход к оформлению, подписка.

В GA4 конверсией (в новой терминологии — ключевым событием) можно пометить любое событие, в том числе purchase, add_to_cart, begin_checkout. Достаточно в интерфейсе отметить нужное событие как ключевое — и GA4 начнёт считать его в отчётах о конверсиях и передавать в Google Ads для оптимизации кампаний.

Собрав события в цепочку, вы получаете воронку — самый наглядный инструмент для поиска точек потери. Классическая воронка магазина: просмотр товара → добавление в корзину → начало оформления → покупка. На каждом переходе часть людей отваливается, и задача аналитика — найти самый «дырявый» шаг. Часто это переход от корзины к оформлению, где всплывают неожиданная стоимость доставки или требование регистрации.

Отдельная тема — как воронка связана с оптимизацией конверсии. Найдя проблемный шаг в аналитике, гипотезу об улучшении проверяют A/B-тестом, а не меняют вслепую. Про то, как правильно строить эксперименты на магазине, мы подробно писали в статье про A/B-тестирование и CRO на 1С-Битрикс — аналитика и тестирование работают в паре: одна находит проблему, другое проверяет решение.

Товарные отчёты: что и где смотреть

Когда данные наконец пошли, встаёт вопрос — что с ними делать. Перечислим отчёты, которые дают максимум пользы владельцу магазина, и вопросы, на которые они отвечают.

• Товары / заказанные товары. Что реально покупают, а что только смотрят. Помогает управлять ассортиментом и закупками.
• Популярные категории. Какие разделы каталога приносят выручку. Основа для перераспределения рекламного бюджета.
• Источники и доход. Сколько денег приносит каждый канал — не по кликам, а по фактической выручке. Прямой вход в расчёт ROMI.
• Воронка продаж. Где теряются покупатели между просмотром и оплатой.
• Ассоциации / вместе покупают. Какие товары берут в одном заказе — подсказка для блоков рекомендаций и кросс-продаж.
• Средний чек и его динамика. Как меняется сумма заказа во времени и по сегментам.

Практический совет: не тоните в отчётах. Выберите три-четыре метрики, которые реально влияют на решения (например, выручка по каналам, конверсия воронки и средний чек), и смотрите их регулярно. Остальное подключайте под конкретный вопрос. Аналитика ценна не количеством дашбордов, а числом решений, которые она помогла принять.

Согласие на cookie и приватность

Аналитика работает с cookie и пользовательскими идентификаторами, а значит, попадает под требования о защите персональных данных (в России — 152-ФЗ). Игнорировать это нельзя: как минимум на сайте должны быть уведомление об обработке данных и политика конфиденциальности, а как максимум — механизм получения согласия перед запуском трекинга.

• Баннер согласия. Всплывающее уведомление с кнопкой «Принять» и ссылкой на политику. До согласия аналитику либо не запускают, либо запускают в ограниченном режиме.
• Consent Mode в GA4. Google предлагает режим согласия, при котором до одобрения теги работают в урезанном виде (без записи в cookie), а после — в полном. Это компромисс между приватностью и полнотой данных.
• Отложенная инициализация Метрики. Счётчик Метрики можно запускать только после клика по «Принять», взводя его инициализацию из обработчика согласия.
• Политика и уведомления. Страница политики конфиденциальности и явное уведомление об использовании cookie — обязательный минимум для магазина.

Важно понимать компромисс: чем строже вы относитесь к согласию, тем меньше данных собираете (часть пользователей откажется), но тем спокойнее с точки зрения закона. Баланс каждый бизнес выбирает сам, а конкретные юридические формулировки лучше согласовать с юристом под вашу деятельность. Технически же и Метрика, и GA4 позволяют аккуратно встроить сбор данных в логику согласия — это стандартная часть внедрения.

Проверка и отладка данных

Внедрить события — половина дела. Вторая половина — убедиться, что они уходят корректно, без дублей и с правильными значениями. Вот инструменты и приёмы, которыми пользуются при проверке.

1. Консоль браузера. Наберите dataLayer в консоли и посмотрите, какие объекты в нём накопились при проходе по сайту. Это самый быстрый способ увидеть, что реально отправляется.
2. DebugView в GA4. Режим отладки показывает события в реальном времени с параметрами. Пройдите путь «карточка → корзина → заказ» и убедитесь, что каждое событие пришло один раз и с нужными полями.
3. Предпросмотр в Google Tag Manager. Режим Preview показывает, какие теги сработали на каждом действии и какие данные они получили из dataLayer.
4. Отчёт «Проверка электронной коммерции». В Метрике проверьте, появляются ли заказы и товары в отчётах после тестовой покупки.
5. Сверка с 1С-Битрикс. Оформите тестовый заказ и убедитесь, что его сумма и состав в аналитике совпадают с заказом в админке магазина.

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

Частые ошибки

• Событие purchase привязано к клику по кнопке оформления, а не к завершённому заказу — в аналитику попадают брошенные оформления.
• Страница «Спасибо за заказ» отправляет покупку при каждой перезагрузке — заказы задваиваются, доход завышается.
• Идентификатор товара в карточке и в корзине разный (артикул против внутреннего ID) — товарная воронка не сходится.
• Цена передаётся строкой с символом валюты или пробелами («12 490 ₽») — аналитика не может посчитать доход.
• dataLayer объявлен после счётчика — ранние события (просмотр карточки) теряются.
• Объект ecommerce не очищается между событиями — данные предыдущего действия «прилипают» к следующему.
• Состав покупки читают из уже очищенной корзины, а не из объекта заказа — в событие уходит пустой список товаров.
• Правки внесены в файлы дистрибутива компонентов — при обновлении платформы события пропадают.
• Аналитика запускается без учёта согласия на cookie — риск нарушения требований по персональным данным.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность аналитики магазина перед запуском.

1. Системы подключены. Счётчик Метрики и/или ресурс GA4 установлены, электронная коммерция включена в настройках.
2. dataLayer объявлен рано. Инициализация контейнера стоит выше кода счётчиков, ранние события не теряются.
3. Идентификатор товара стабилен. Во всех событиях используется один и тот же артикул или внешний код, устойчивый к обмену с 1С.
4. Ключевые события внедрены. Просмотр карточки, добавление и удаление из корзины, начало оформления и покупка эмитятся из шаблонов компонентов.
5. Покупка отправляется один раз. Событие purchase срабатывает строго на завершённом заказе, без дублей при перезагрузке.
6. Цели и конверсии настроены. Оформленный заказ помечен как цель в Метрике и ключевое событие в GA4.
7. Согласие на cookie обработано. Есть баннер, политика конфиденциальности и запуск трекинга с учётом согласия.
8. Данные проверены. Тестовый заказ прошёл сверку с 1С-Битрикс, DebugView и отчёты показывают корректные суммы.

Вывод

Электронная коммерция в Яндекс.Метрике и GA4 превращает магазин на 1С-Битрикс из «сайта с посещаемостью» в управляемый по деньгам бизнес: видны товары, воронка, доход по каналам и точки потерь. Секрет надёжной аналитики прост — единый dataLayer как источник событий, стабильные идентификаторы товаров, покупка строго один раз на завершённом заказе и обязательная сверка с реальными продажами. Сделайте эти четыре вещи корректно, и цифры в отчётах начнут совпадать с деньгами в кассе, а решения о рекламе и ассортименте — опираться на факты, а не на догадки.