Уявіть: запускаєте рекламну кампанію в Яндекс.Дірект та Google Ads, дзвінки йдуть — але ви не знаєте, з якого каналу прийшов кожен клієнт. Без атрибуції дзвінків зливаєте бюджет на неефективні джерела. Статичний коллтрекінг на 1С-Бітрікс вирішує це завдання, але впирається в кешування. Якщо просто вивести динамічний номер у шаблоні, Бітрікс перестане кешувати сторінку — продуктивність впаде.
Ми налаштовуємо статичний коллтрекінг на проєктах під Бітрікс понад п'ять років. Розберемося, як працює схема, які підводні камені приховує кешування і чому JS-підміна — оптимальне рішення. Цей підхід дешевший за динамічний: потрібно менше номерів. Наприклад, при відстеженні п'яти каналів щомісячна оренда номерів обходиться на 30–50% дешевше, ніж при динамічній схемі, де потрібен один номер на кожного унікального відвідувача. Але атрибуція йде тільки до рівня каналу, не до ключового слова. Для B2B, медицини, нерухомості — виправдано.
Механізм статичного коллтрекінгу
Беремо N номерів у провайдера — за кількістю відстежуваних каналів. Кожен номер переадресовує на основний. Система коллтрекінгу фіксує, на який зі статичних номерів подзвонили, і записує це в статистику.
| Канал | Номер | Переадресація |
|---|---|---|
| Яндекс.Дірект | +7 (495) 111-11-11 | → основний |
| Google Ads | +7 (495) 222-22-22 | → основний |
| ВКонтакті | +7 (495) 333-33-33 | → основний |
| Офлайн / візитки | +7 (495) 444-44-44 | → основний |
| Сайт (дефолт) | +7 (495) 555-55-55 | → основний |
Реалізація на стороні Бітрікс
Маппінг каналів та номерів зберігаємо в налаштуваннях модуля. Визначаємо канал за 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-підміна | Дефолтний номер в HTML, підміна клієнтським скриптом | Зберігається | Низька |
| Винесення з кешу | Відключення кешу для блока через $component->arResult |
Частково | Середня |
| ESI | Фрагмент через Edge Side Includes | Зберігається | Висока |
Чому 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) потрібен для запису дзвінків та статистики. Налаштування:
- Орендуємо потрібну кількість номерів.
- Для кожного номера — правило: «якщо дзвінок на номер X, вважати джерелом Y».
- Переадресація на основний номер.
- Опціонально — запис розмов.
З Бітрікс API не потрібен — вся логіка на стороні провайдера.
Що входить в роботу
- Оренда підмінних номерів та налаштування переадресації.
- Розробка PHP-модуля визначення каналу та зберігання cookie.
- Реалізація JS-підміни телефону (кеш-сумісний варіант).
- Адаптація шаблонів (шапка, підвал, форми).
- Налаштування маппінгу каналів в адмінці.
- Документація з підтримки та навчання вашого адміністратора.
Терміни: повне налаштування під 4–6 каналів — 3–7 робочих днів. Вартість розраховується після аудиту проєкту.
Для оперативного запуску зв'яжіться з нами — ми підготуємо пропозицію за один день. За плечима понад 50 впроваджень для агентств та прямих рекламодавців. Гарантуємо збереження кешування та коректну атрибуцію дзвінків. Отримайте консультацію — оцінимо ваш проєкт.