Інтеграція Бітрікс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 угод, і кожен рахує по-своєму. Рішення приймаються на відчуттях, а рекламний бюджет летить у нікуди — за нашими даними, втрати через некоректну аналітику сягають 30–40% бюджету. Для магазина з витратами на рекламу 100 000 грн на місяць це 30–40 тис. грн щомісячних втрат.

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

Як аналітика 1С-Бітрікс вирішує проблему розбіжності даних?

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

Як виправити e-commerce трекінг у Яндекс.Метриці та GA4?

Базове налаштування — і чому його зазвичай роблять криво

• Встановлення через 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 з урахуванням знижок.

Приклад налаштування dataLayer для події add_to_cart:

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
            }]
        }
    });
});

Чому 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 мовчки проковтне невалідні дані і покаже порожні звіти. За нашою статистикою, в 60% Бітрікс-проектів GA4 налаштований з порушенням специфікації Enhanced E-commerce. Це призводить до втрати до 40% транзакцій у звітах.

Користувацькі параметри, які реально потрібні:

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

Що дає наскрізна аналітика на Бітрікс?

Метрика бачить візити. CRM бачить угоди. Рекламний кабінет бачить витрати. А зв'язок між ними — розрив. Менеджер закрив велику угоду, але Метрика показує джерело (direct), тому що клієнт прийшов за прямим посиланням із закладок, а перший контакт був через Директ три місяці тому.

Наскрізна аналітика замикає ланцюжок: рекламний клік → візит → лід в CRM → угода → оплата → ROI. Після впровадження клієнти перерозподіляють бюджет на користь каналів з високим LTV, і ROI зростає в середньому на 25% за квартал. Roistat показує на 40% точнішу атрибуцію порівняно з Calltouch за нашими тестами на великих проектах.

Як збираємо

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-трафік конвертується гірше, зате повертається. Без цього аналізу ви ризикуєте переплачувати за канали, які дають одноразових покупців.

Терміни та вартість налаштування аналітики

Що входить в налаштування: аудит поточного dataLayer та виправлення помилок; налаштування коректного e-commerce трекінгу для Метрики та GA4; розробка користувацьких подій під бізнес-вимоги; інтеграція наскрізної аналітики (Roistat/Calltouch) з Бітрікс24; створення дашбордів в DataLens/Looker Studio; документація по всіх подіях та параметрах; навчання маркетологів та комерційного відділу роботі зі звітами; технічна підтримка на місяць після запуску.

Вартість розраховується індивідуально залежно від обсягу робіт та складності інтеграцій. Отримайте консультацію — ми проаналізуємо ваш поточний dataLayer та запропонуємо оптимальне рішення. Замовте аудит або налаштування аналітики, щоб перестати втрачати гроші на некоректних даних. Звертайтеся — перевіримо, чи не втрачаєте ви гроші на аналітиці, за один день.