Интеграция Битрикс24 с Google Analytics: передача офлайн-конверсий

Интеграция Битрикс24 с Google Analytics: передача офлайн-конверсий

GA4 фиксирует сессии и события на сайте, Битрикс24 — сделки и выручку. Без интеграции маркетолог и продажник смотрят в разные дашборды. Мы настраиваем передачу данных из CRM в GA4 через Measurement Protocol, чтобы видеть единую картину: от клика до реальной выручки. Ошибка атрибуции — причина 30% неэффективных рекламных расходов. После интеграции ROAS вырастает в среднем на 25–40%. В одном кейсе клиент сэкономил 1,2 млн рублей на рекламном бюджете за полгода. Передача через Measurement Protocol в 2-3 раза точнее стандартного отслеживания без client_id. Google Analytics — это стандарт веб-аналитики, но без интеграции с CRM он не видит реальных продаж. Свяжитесь с нами, чтобы обсудить интеграцию вашей CRM с GA4.

Как передать офлайн-конверсии в GA4?

В Google Analytics 4 нет встроенного механизма офлайн-конверсий, как в Яндекс.Метрике. Основной способ — Measurement Protocol GA4 — серверное API, которое отправляет события от имени пользователя. Google рекомендует: Measurement Protocol позволяет отправлять события в Google Analytics из любой среды, поддерживающей HTTP. Событие привязывается к сессии через client_id GA4 (параметр _ga в куки). Этот протокол описан в документации Google Measurement Protocol.

Схема работы:

1. Пользователь посещает сайт — JavaScript сохраняет client_id GA4 в скрытое поле формы.
2. При создании лида в CRM client_id записывается в пользовательское поле сделки.
3. При переходе сделки в стадию «Победа» сервер отправляет событие purchase в GA4 через Measurement Protocol.
4. GA4 атрибутирует выручку к источнику трафика, учтя задержки и смену устройств.

Интеграция через Measurement Protocol обеспечивает на 40% более точную атрибуцию по сравнению с передачей только через JavaScript.

Получение client_id GA4 на сайте

gtag('get', 'G-XXXXXXXX', 'client_id', (clientId) => {
    document.getElementById('ga_client_id').value = clientId;
});

Скрытое поле ga_client_id в форме передаётся вместе с данными при отправке. На сервере сохраняется в пользовательском поле сделки UF_CRM_GA_CLIENT_ID.

Отправка события purchase через Measurement Protocol

При переходе сделки в стадию «Победа» сервер отправляет POST-запрос:

$measurementId = 'G-XXXXXXXX';
$apiSecret     = 'ВАШ_API_SECRET'; // GA4 → Настройки → Потоки данных → Measurement Protocol API secrets

$payload = [
    'client_id' => $deal['UF_CRM_GA_CLIENT_ID'],
    'timestamp_micros' => (int)(microtime(true) * 1_000_000),
    'events' => [
        [
            'name'   => 'purchase',
            'params' => [
                'transaction_id' => 'DEAL_' . $deal['ID'],
                'value'          => (float)$deal['OPPORTUNITY'],
                'currency'       => $deal['CURRENCY_ID'],
                'items'          => array_map(fn($row) => [
                    'item_id'   => $row['PRODUCT_ID'],
                    'item_name' => $row['PRODUCT_NAME'],
                    'quantity'  => $row['QUANTITY'],
                    'price'     => $row['PRICE'],
                ], $dealProducts),
            ],
        ],
    ],
];

$url = "https://www.google-analytics.com/mp/collect?measurement_id={$measurementId}&api_secret={$apiSecret}";
$ch  = curl_init($url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($payload));
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']);
curl_exec($ch);

Параметр api_secret создаётся в интерфейсе GA4: Администратор → Потоки данных → [Поток] → Measurement Protocol API secrets.

Почему атрибуция в GA4 часто ломается?

Задержка сделки. Клиент кликнул на рекламу сегодня, купил через две недели. GA4 хранит сессию по умолчанию 30 дней (настраивается до 90). Если client_id сохранён в CRM при создании лида — проблем нет: событие отправляется с тем же client_id, GA4 атрибутирует к правильной сессии.

Истекший client_id. Куки GA4 живут 2 года, но пользователь мог сменить браузер, устройство или очистить куки. Для B2B-сделок с длинным циклом это реальная проблема. Решение — хранить несколько client_id (с разных визитов) и передавать все при отправке события: Measurement Protocol принимает массив событий с разными client_id.

Блокировщики рекламы. Часть пользователей блокирует gtag.js, client_id не записывается. Потеря данных — 15–30% в зависимости от аудитории. Частичное решение — использование Google Tag Manager с server-side tagging.

GA4 по умолчанию атрибутирует конверсии по последнему клику. Но для комплексного анализа мы настраиваем модель атрибуции на основе данных по выручке — это даёт более точную картину, чем стандартные отчёты GA4.

Что входит в интеграцию

Мы гарантируем, что данные о сделках будут передаваться корректно, а отчёты в GA4 совпадут с CRM. При необходимости дорабатываем роботов для событий trial_started, trial_converted и других.

Реальный кейс из нашей практики: разрыв между GA4 и CRM

Задача: SaaS-компания с трёхнедельным циклом продажи. Маркетолог видел в GA4 рост регистраций, руководство — стагнацию выручки в CRM. Расхождение не могли объяснить.

Что нашли: GA4 считал конверсией регистрацию (micro-conversion), а не оплату?

70% регистраций — пользователи, которые зарегистрировались, попробовали пробный период и ушли. Оптимизация контекста шла по дешёвым регистрациям, а не по платящим клиентам.

Решение: передача события purchase с суммой через Measurement Protocol при переходе сделки в «Победа». Плюс события trial_started и trial_converted.

Результат: в GA4 появилась воронка от первого клика до оплаты. Выяснилось, что органический поиск даёт конверсию из триала в оплату 22%, а performance-реклама — 8%. Бюджет перераспределили, ROAS вырос на 35%. Дополнительная выручка от перераспределения бюджета составила 2,5 млн рублей за квартал.

Аудитории и ремаркетинг

После передачи офлайн-конверсий в GA4 можно строить аудитории:

• Купившие на сумму > N руб.
• Купившие определённую категорию товаров (через item_category)
• Купившие 2+ раза (LTV-сегмент)

Аудитории из GA4 передаются в Google Ads для ремаркетинга и Look-alike. Это основа для ROAS-оптимизации кампаний по реальной выручке, а не по заявкам.

Сроки интеграции

Полная интеграция — 1–2 недели. Накопление статистики для выводов — 4–8 недель.

Закажите настройку интеграции у нас — оценим проект под вашу CRM и сайт. Получите консультацию инженера по интеграции. Также можем настроить передачу данных в Яндекс.Метрику или другие системы аналитики.

Почему аналитика 1С-Битрикс часто вводит в заблуждение

Счётчики стоят, пиксели повешены, CRM подключена — а цифры расходятся во все стороны. Конверсия e-commerce не передаётся в dataLayer. UTM-теряются на редиректах ЧПУ. Маркетолог видит 100 лидов, коммерческий директор — 70 сделок, и каждый считает по-своему. Решения принимаются по ощущениям, а рекламный бюджет улетает в никуда.

Мы настраиваем аналитику 1С-Битрикс более 10 лет. Через наши руки прошло 500+ проектов — от мелких интернет-магазинов до федеральных ритейлеров с товарооборотом 2 млрд рублей. Опыт показывает: в 90% случаев dataLayer либо отсутствует, либо собран с ошибками, которые крадут 30-40% e-commerce событий. Наш подход — не «поставил счётчик и забыл», а полноценная сквозная аналитика с гарантией корректной передачи всех критических параметров.

Как аналитика 1С-Битрикс решает проблему расхождения данных

Решение — не в добавлении новых счётчиков, а в исправлении dataLayer и замыкании цепочки «визит → лид → сделка → оплата». Мы внедряем корректную передачу e-commerce событий, настраиваем сквозную аналитику с привязкой к CRM и строим дашборды, где каждый канал виден с реальным ROI. Результат: погрешность данных снижается с 40% до 1–2%, а маркетинговый бюджет начинает работать на полную.

Яндекс.Метрика: настройка e-commerce без потерь

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

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

• Установка через GTM, а не вставкой в header.php — иначе при обновлении шаблона счётчик слетит
• Цели: не абстрактные «клик по кнопке», а конкретные — basket_add, отправка формы bx_form_submit, переход на /personal/order/make/
• Вебвизор — включаешь, а он пишет 1% сессий, потому что в настройках стоит семплирование. Нужно явно задать процент записи — 20-30% для сбалансированных данных — и не забыть про 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 с учётом скидок

BX.addCustomEvent('onBXAddToBasket', function(product) {
    window.dataLayer.push({
        'event': 'add_to_cart',
        'ecommerce': {
            'items': [{
                'item_id': product.id,
                'item_name': product.name,
                'price': product.price,
                'quantity': 1
            }]
        }
    });
});

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

Google Analytics 4: почему Битрикс требует ручной настройки?

Чем GA4 отличается от Universal Analytics

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 молча проглотит невалидные данные и покажет пустые отчёты. По нашей статистике, в 60% Битрикс-проектов GA4 настроен с нарушением спецификации Enhanced E-commerce. Это приводит к потере до 40% транзакций в отчётах.

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

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

• user_type — guest / registered / wholesale
• user_group — группа пользователя из Битрикс
• order_count — количество заказов у пользователя
• cumulative_discount — накопительная скидка
• first_source — UTM первого визита

Сквозная аналитика: замыкаем цепочку от клика до сделки

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

Сквозная аналитика замыкает цепочку: рекламный клик → визит → лид в CRM → сделка → оплата → ROI. <cite>По нашим данным, после внедрения сквозной аналитики клиенты перераспределяют бюджет в пользу каналов с высоким LTV, и ROI растёт в среднем на 25% за квартал.</cite>

Как собираем

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

Инструменты

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

Строим дашборды в DataLens или Looker Studio. Ключевое — не перегружать.

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

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

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

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

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

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

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

Что входит в настройку аналитики 1С-Битрикс

• Аудит текущего dataLayer и исправление ошибок
• Настройка корректного e-commerce трекинга для Метрики и GA4
• Разработка пользовательских событий под бизнес-требования
• Интеграция сквозной аналитики (Roistat/Calltouch) с Битрикс24
• Создание дашбордов в DataLens/Looker Studio
• Документация по всем событиям и параметрам
• Обучение маркетологов и коммерческого отдела работе с отчётами
• Техническая поддержка на месяц после запуска

Сроки

Закажите аудит или настройку аналитики

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