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

Уявіть: запускаєте рекламну кампанію в Яндекс.Дірект та Google Ads, дзвінки йдуть — але ви не знаєте, з якого каналу прийшов кожен клієнт. Без атрибуції дзвінків зливаєте бюджет на неефективні джерела. Статичний коллтрекінг на 1С-Бітрікс вирішує це завдання, але впирається в кешування. Якщо просто вивести динамічний номер у шаблоні, Бітрікс перестане кешувати сторінку — продуктивність впаде.

Ми налаштовуємо статичний коллтрекінг на проєктах під Бітрікс понад п'ять років. Розберемося, як працює схема, які підводні камені приховує кешування і чому JS-підміна — оптимальне рішення. Цей підхід дешевший за динамічний: потрібно менше номерів. Наприклад, при відстеженні п'яти каналів щомісячна оренда номерів обходиться на 30–50% дешевше, ніж при динамічній схемі, де потрібен один номер на кожного унікального відвідувача. Але атрибуція йде тільки до рівня каналу, не до ключового слова. Для B2B, медицини, нерухомості — виправдано.

Механізм статичного коллтрекінгу

Беремо N номерів у провайдера — за кількістю відстежуваних каналів. Кожен номер переадресовує на основний. Система коллтрекінгу фіксує, на який зі статичних номерів подзвонили, і записує це в статистику.

Реалізація на стороні Бітрікс

Маппінг каналів та номерів зберігаємо в налаштуваннях модуля. Визначаємо канал за utm_source з GET-параметра або cookie.

// /local/modules/local.calltracking/lib/Config.php
namespace Local\Calltracking;

class Config
{
    public static function getPhoneMap(): array
    {
        return [
            'yandex'   => [
                'display' => '+7 (495) 111-11-11',
                'href'    => 'tel:+74951111111',
            ],
            'google'   => [
                'display' => '+7 (495) 222-22-22',
                'href'    => 'tel:+74952222222',
            ],
            'vk'       => [
                'display' => '+7 (495) 333-33-33',
                'href'    => 'tel:+74953333333',
            ],
            'offline'  => [
                'display' => '+7 (495) 444-44-44',
                'href'    => 'tel:+74954444444',
            ],
            'default'  => [
                'display' => '+7 (495) 555-55-55',
                'href'    => 'tel:+74955555555',
            ],
        ];
    }
}

Хук в OnProlog — ловимо utm_source і пишемо cookie:

// /local/php_interface/init.php
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'main',
    'OnProlog',
    function () {
        $request = \Bitrix\Main\Application::getInstance()->getContext()->getRequest();

        // Пріоритет 1: GET-параметр utm_source (новий візит)
        $utmSource = $request->get('utm_source');
        if ($utmSource) {
            $utmSource = preg_replace('/[^a-z0-9_-]/i', '', strtolower($utmSource));
            setcookie('ct_source', $utmSource, time() + 86400 * 30, '/');
            $_COOKIE['ct_source'] = $utmSource;
        }

        // Пріоритет 2: збережений cookie
        if (!$utmSource) {
            $utmSource = $_COOKIE['ct_source'] ?? 'default';
        }

        $GLOBALS['CT_CURRENT_SOURCE'] = $utmSource;
    }
);

Хелпер для підстановки номера в шаблон:

namespace Local\Calltracking;

class PhoneResolver
{
    public static function getCurrentPhone(): array
    {
        $source = $GLOBALS['CT_CURRENT_SOURCE'] ?? 'default';
        $map    = Config::getPhoneMap();

        return $map[$source] ?? $map['default'];
    }
}

Використання в шапці:

<?php
$phone = \Local\Calltracking\PhoneResolver::getCurrentPhone();
?>
<a href="<?= htmlspecialchars($phone['href']) ?>"
   class="header-phone"
   data-source="<?= htmlspecialchars($GLOBALS['CT_CURRENT_SOURCE'] ?? 'default') ?>">
    <?= htmlspecialchars($phone['display']) ?>
</a>

Чому кеш Бітрікс конфліктує з коллтрекінгом?

Статичний коллтрекінг через PHP-логіку несумісний з повним кешуванням. Телефон — персоналізовані дані (залежить від cookie), тому сторінка з телефоном кешуватися не повинна. Як зазначено в документації з кешування, персоналізовані дані вимагають відключення кешування компонента, але JS-підміна обходить це обмеження.

Три варіанти рішення:

Чому JS-підміна — оптимальний варіант?

Оптимальний — JS-підміна. Ось скрипт:

document.addEventListener('DOMContentLoaded', function () {
    const phoneMap = {
        'yandex': {display: '+7 (495) 111-11-11', href: 'tel:+74951111111'},
        'google': {display: '+7 (495) 222-22-22', href: 'tel:+74952222222'},
        // ...
        'default': {display: '+7 (495) 555-55-55', href: 'tel:+74955555555'},
    };

    const source = getCookie('ct_source') || 'default';
    const phone  = phoneMap[source] || phoneMap['default'];
    const el     = document.querySelector('.header-phone');

    if (el) {
        el.textContent = phone.display;
        el.href        = phone.href;
    }
});

Цей підхід ми використовуємо в більшості проєктів. Заміна за мілісекунди, користувач не помічає мигання. Збереження повного кешу сторінки дає приріст швидкості завантаження до 300% порівняно з варіантом відключення кешу. Крім того, JS-підміна не потребує додаткових витрат на серверні ресурси — вся логіка на клієнті.

Для прикладу, нещодавно ми впровадили статичний коллтрекінг для клієнта зі сфери послуг з п'ятьма рекламними каналами. Після налаштування атрибуція показала, що 40% дзвінків надходять з Яндекс.Дірект, 30% — з Google Ads, 20% — із соцмереж, решта — з офлайн-реклами. Клієнт зміг перерозподілити бюджет і підвищити загальну конверсію на 25% за рахунок відмови від неефективних каналів. Економія на оренді номерів склала понад 60% порівняно з динамічним коллтрекінгом.

Які обмеження у статичного коллтрекінгу?

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

Як інтегрувати провайдера коллтрекінгу?

Провайдер (Callibri, CoMagic, Mango) потрібен для запису дзвінків та статистики. Налаштування:

1. Орендуємо потрібну кількість номерів.
2. Для кожного номера — правило: «якщо дзвінок на номер X, вважати джерелом Y».
3. Переадресація на основний номер.
4. Опціонально — запис розмов.

З Бітрікс API не потрібен — вся логіка на стороні провайдера.

Що входить в роботу

• Оренда підмінних номерів та налаштування переадресації.
• Розробка PHP-модуля визначення каналу та зберігання cookie.
• Реалізація JS-підміни телефону (кеш-сумісний варіант).
• Адаптація шаблонів (шапка, підвал, форми).
• Налаштування маппінгу каналів в адмінці.
• Документація з підтримки та навчання вашого адміністратора.

Терміни: повне налаштування під 4–6 каналів — 3–7 робочих днів. Вартість розраховується після аудиту проєкту.

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

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