Налаштування динамічного коллтрекінгу на 1С-Бітрікс

Налаштування динамічного коллтрекінгу на 1С-Бітрікс

Ми стикалися з ситуацією: клієнт витрачає 500 000 грн на рекламу, бачить 1000 лідів у CRM, але не знає, який канал приніс дзвінок. Без динамічного коллтрекінгу ця частина конверсії залишається сліпою зоною. Для ecommerce та послуг дзвінки становлять 40–60% заявок — ігнорувати їх не можна. Ми навчилися налаштовувати коллтрекінг на 1С-Бітрікс так, щоб кожен дзвінок лягав в аналітику з UTM-мітками, ключовим словом та джерелом.

Принцип роботи: кожному відвідувачу показується унікальний підмінний номер з пулу. Система зіставляє номер із сесією та передає дані в системи аналітики. Після дзвінка номер повертається до пулу. Точність підміни — до 99.9% при правильному налаштуванні.

Вибір провайдера та встановлення скрипта

Основні провайдери: Callibri, CoMagic, Roistat, Ringostat, Mango Office. Усі пропонують JS-скрипт та API. Для Бітрікс скрипт додаємо через Bitrix\Main\Page\Asset::addString в події OnEpilog — це гарантує, що скрипт не потрапить в кеш і не продублюється при AJAX-навігації.

// /local/php_interface/init.php
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'main',
    'OnEpilog',
    function () {
        if (\Bitrix\Main\Application::getInstance()->getContext()->getRequest()->isAdminSection()) {
            return;
        }

        $asset = \Bitrix\Main\Page\Asset::getInstance();
        $asset->addString(
            '<script type="text/javascript">
                (function(w,d,n,t){
                    // Код скрипта провайдера коллтрекинга
                    w[n] = w[n] || function(){(w[n].q=w[n].q||[]).push(arguments)};
                    t = d.createElement("script");
                    t.async = 1;
                    t.src = "https://tracker.callibri.ru/callibri.js";
                    d.head.appendChild(t);
                })(window,document,"callibri");
                callibri("setCounter", "YOUR_COUNTER_ID");
            </script>',
            true
        );
    }
);

Як правильно розмітити телефони на сайті Бітрікс?

Для коректної підміни телефон має бути розмічений через data-атрибути. У шаблоні компонента (наприклад, header.php) змінюємо виведення:

<!-- Замість -->
<span class="phone">+7 (495) 123-45-67</span>

<!-- Використовуємо -->
<span class="calltracking-phone"
      data-original-phone="+74951234567"
      data-phone-display="+7 (495) 123-45-67">
    +7 (495) 123-45-67
</span>

Скрипт провайдера знаходить елементи за CSS-селектором і підміняє вміст. Якщо на сайті кілька телефонів (основний, відділ продажів, сервіс), кожному призначається окрема група підміни в особистому кабінеті провайдера.

Чому важливий розмір пулу номерів?

Пул має покривати максимальну кількість одночасних відвідувачів. Наприклад, при 30 одночасних відвідувачах і середній сесії 4 хвилини потрібно мінімум 30 номерів. Недостатність пулу призводить до того, що нові відвідувачі бачать статичний номер — дані втрачаються. Пул із 50 номерів обійдеться приблизно в 7 500 грн на місяць — це плата за точність. Завдяки точній атрибуції ви перестаєте зливати до 40% рекламного бюджету на нецільові дзвінки.

Для Бітрікс-сайтів з кешуванням є нюанс: якщо сторінка кешована на рівні Композитного сайту або nginx, скрипт коллтрекінгу може завантажуватися із затримкою. Рішення — телефон в HTML залишати як fallback, а підміна виконується через JS після повного завантаження сторінки.

Передача дзвінків у Google Analytics 4 та Яндекс.Метрику

Провайдери вміють надсилати події про дзвінки в GA4 та Метрику. Для GA4 використовуємо події phone_call_start та phone_call_end з параметрами call_id, utm_source, duration, is_target. Інтеграція виконується через налаштування провайдера або кастомний код:

callibri('onCallStart', function(callData) {
    gtag('event', 'phone_call_start', {
        'call_id'     : callData.callId,
        'utm_source'  : callData.utmSource,
        'utm_campaign': callData.utmCampaign,
    });
});

callibri('onCallEnd', function(callData) {
    gtag('event', 'phone_call_end', {
        'call_id'  : callData.callId,
        'duration' : callData.duration,
        'is_target': callData.isTarget,
    });
});

Порівняння: динамічний vs статичний коллтрекінг

Динамічний коллтрекінг точніший за статичний у 3–5 разів для сайтів з високим трафіком. Статичний присвоює один номер каналу — якщо по каналу прийшло 100 осіб, а зателефонував один, ви не дізнаєтеся, хто саме. Динамічний відстежує кожного відвідувача, пов'язуючи дзвінок з конкретним візитом та його UTM-мітками.

Що входить у роботу? (Deliverables)

Як налаштувати коллтрекінг на Бітрікс: покрокова інструкція

1. Аудит поточного сайту: Визначте, де виводяться телефони та як вони розмічені. Переконайтеся, що немає блокувань скриптів (CSP, якщо використовуються).
2. Вибір провайдера: Порівняйте умови Callibri, CoMagic, Roistat. Для початку використовуйте пробний період.
3. Реєстрація та отримання скрипта: Зареєструйтеся у провайдера, візьміть JS-скрипт та ідентифікатор лічильника.
4. Встановлення скрипта на сайт: Додайте код через OnEpilog у /local/php_interface/init.php як показано вище.
5. Розмітка телефонів: Промаркуйте кожен телефон атрибутами data-original-phone та data-phone-display.
6. Налаштування пулу: В особистому кабінеті провайдера вкажіть кількість номерів, яка перекриває пікову відвідуваність.
7. Інтеграція з аналітикою: Налаштуйте передачу подій у GA4 та Яндекс.Метрику.
8. Тестування: Перевірте підміну для різних UTM, прямих заходів, кешованих сторінок.

Чек-лист перевірки після налаштування

• Відкрити сайт з UTM-мітками ?utm_source=yandex&utm_medium=cpc — телефон має змінитися.
• Відкрити без UTM (прямий захід) — відображається дефолтний номер з пулу.
• Перевірити кешовані сторінки: після прогріву кешу телефон все одно підміняється.
• Переконатися, що телефони в og:image та Schema.org статичні, не підмінювані.
• Перевірити мобільну версію — click-to-call веде на підмінний номер.

Зв'яжіться з нами для аудиту вашого проекту — оцінимо поточну схему за один день. Замовте налаштування коллтрекінгу — перший дзвінок безкоштовно. Наш досвід: понад 50 проектів на Бітрікс, гарантуємо, що кожен дзвінок буде атрибутований до джерела.

Згідно з даними провайдера Callibri, точність підміни при правильному налаштуванні досягає 99.9%.

Чому аналітика 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 та запропонуємо оптимальне рішення. Замовте аудит або налаштування аналітики, щоб перестати втрачати гроші на некоректних даних. Звертайтеся — перевіримо, чи не втрачаєте ви гроші на аналітиці, за один день.