Аналитика и отчёты для 1С-Битрикс

Почему 90% счётчиков на Битрикс-сайтах врут

Ставишь счётчик Метрики, подключаешь GA4, вешаешь пиксели — вроде аналитика есть. А потом смотришь: конверсия e-commerce не передаётся, UTM-метки слетают на редиректах, в CRM лиды без источника. Типичная картина — маркетолог смотрит в один отчёт, коммерческий директор в другой, цифры не бьются, и все принимают решения по ощущениям.

Мы настраиваем аналитику на проектах 1С-Битрикс — от корректной передачи dataLayer до сквозной аналитики с ROI по каждой кампании.

Яндекс.Метрика: больше, чем просто счётчик

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

Счётчик Метрики ставят все. Правильно — единицы.

• Установка через GTM, а не вставкой в header.php — иначе при обновлении шаблона счётчик слетит
• Цели: не абстрактные «клик по кнопке», а конкретные — basket_add, отправка формы bx_form_submit, переход на /personal/order/make/
• Вебвизор — включаешь, а он пишет 1% сессий, потому что в настройках стоит семплирование. Нужно явно задать процент записи и не забыть про GDPR/152-ФЗ
• Фильтрация внутреннего трафика — без этого аналитик офиса добавляет 15-20% мусорных визитов. Фильтруем по IP, по cookie _ym_debug, по заголовкам

Электронная коммерция — самая недооценённая фича

Модуль eCommerce в Метрике передаёт полную цепочку покупательского поведения. Проблема в том, что в Битрикс из коробки он работает только с компонентом sale.order.ajax, и то криво — теряет remove_from_cart при AJAX-обновлении корзины.

Что мы передаём в dataLayer:

• Просмотр карточки — id, name, brand, category, price. Без brand Метрика не построит отчёт по брендам, без category — по категориям. Очевидно, но забывают
• Добавление в корзину — ловим событие onBXAddToBasket через JS, а не через обработчик OnSaleBasketItemAdd на сервере. Серверный обработчик не знает про JS-контекст
• Удаление из корзины — тут ловушка: штатный компонент sale.basket.basket при AJAX-обновлении не генерирует отдельное событие удаления. Нужен свой обсёрвер
• Покупка — передаём на sale/order/complete/, включая coupon и revenue с учётом скидок

Данные, которые уходят в Метрику

GA4: событийная модель и её подводные камни

Почему GA4 — другой зверь

GA4 работает на событиях, а не на хитах. Нет «просмотров страниц» в привычном смысле — есть page_view как одно из событий. Для Битрикса это значит, что AJAX-переходы (фильтрация каталога, пагинация) нужно пушить вручную.

Ключевые события e-commerce:

view_item_list → select_item → view_item → add_to_cart → view_cart → begin_checkout → add_shipping_info → add_payment_info → purchase

Каждое событие требует свой набор параметров. purchase без transaction_id — не засчитается. add_to_cart без массива items — бесполезен. GA4 молча проглотит невалидные данные и покажет пустые отчёты. Никаких ошибок в консоли не будет.

Пользовательские параметры, которые реально нужны

Не надо передавать всё подряд. Пять параметров, которые дают 80% пользы:

• user_type — guest / registered / wholesale. Поведение и конверсия отличаются в разы
• user_group — группа пользователя из Битрикс. Позволяет строить сегменты по розничным vs оптовым
• order_count — сколько заказов у пользователя всего. Первый заказ и двадцатый — разные воронки
• cumulative_discount — накопительная скидка. Влияет на средний чек
• first_source — UTM первого визита. Хранится в cookie или в UF_SOURCE пользователя

Сквозная аналитика: где деньги, Лебовски

Метрика видит визиты. CRM видит сделки. Рекламный кабинет видит расходы. А связь между ними — разрыв. Менеджер закрыл сделку на 500К, но Метрика показывает источник (direct), потому что клиент пришёл по прямой ссылке из закладок, а первый контакт был через Директ три месяца назад.

Сквозная аналитика замыкает цепочку: рекламный клик → визит → лид в CRM → сделка → оплата → ROI.

Как собираем

1. UTM-метки фиксируем в cookie с TTL 90 дней и дублируем в roistat_visit
2. При создании лида в Битрикс24 записываем UTM в пользовательские поля сделки — UF_CRM_UTM_SOURCE, UF_CRM_UTM_MEDIUM, UF_CRM_UTM_CAMPAIGN
3. Коллтрекинг подменяет номер и привязывает звонок к визиту
4. Менеджер ведёт сделку по воронке, закрывает — сумма привязана к источнику
5. Roistat (или Calltouch, CoMagic) агрегирует расходы через API рекламных кабинетов
6. ROI = (выручка - расходы) / расходы. По каждой кампании, группе, ключевому слову

Инструменты

Дашборды: три экрана вместо десяти отчётов

Строим дашборды в DataLens или Looker Studio. Ключевое — не перегружать. Директор не будет разбираться в 40 графиках.

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

Дашборд для маркетолога — трафик по каналам, CAC, ROI кампаний, конверсия воронки, эффективность промокодов. Можно детальнее — маркетолог умеет читать данные.

Дашборд для коммерческого — конверсия менеджеров, скорость обработки заказов, повторные покупки. Здесь DataLens подключаем напрямую к PostgreSQL/MySQL Битрикса через b_sale_order и b_sale_basket.

Воронка: где именно дыра

Типичная воронка Битрикс-магазина:

Провал на чекауте — самый дорогой. Пользователь уже хотел купить, уже положил в корзину, и тут sale.order.ajax кидает 500-ку потому что не настроен обработчик доставки. Или форма требует ИНН у физлица. Каждый такой кейс — прямые потери.

Когортный анализ и LTV

Группируем по месяцу первой покупки, смотрим retention через 30, 60, 90 дней. В DataLens строится через SQL-запрос к b_sale_order с GROUP BY DATE_TRUNC('month', DATE_INSERT).

Главный инсайт когортного анализа — какой канал привлекает клиентов с высоким LTV, а не просто дешёвых. Контекст может давать дешёвые первые заказы, но нулевой repeat rate. А SEO-трафик конвертируется хуже, зато возвращается.

Сроки

Аналитика на Битриксе — не «поставил счётчик и забыл». DataLayer ломается после обновления модуля sale, UTM-метки теряются на редиректах ЧПУ, GA4 меняет формат событий. Систему нужно поддерживать — и мы это делаем.