Настройка карт скроллінгу на 1С-Бітрікс
Карта скроллінгу відповідає на одне питання: до якого місця сторінки доходить більшість користувачів. На довгих сторінках каталогу та лендингах Бітрікса це критично — часто виясняється, що 70% користувачів не бачать блок «Переваги» або форму заявки, тому що вони розташовані нижче «лінії сгиба». Дані скроллінгу змінюють рішення за вёрстку швидше, ніж будь-які А/В-тести.
Яндекс.Метрика: карта скроллінгу без додаткового коду
Метрика будує карту скроллінгу автоматично — окремого трекінгу не потрібна, достатньо встановленого лічильника. Дані доступні у розділі «Вебвізор → Карти → Карта скроллінгу».
Важливий нюанс для Бітрікса: карта скроллінгу будується за конкретним URL. Якщо у каталозі включена пагінація та сторінки /catalog/?PAGEN_1=2 індексуються як окремі URL — кожна сторінка матиме свою карту. Це нормально, але при аналізі потрібно дивитись на першу сторінку (/catalog/ без параметра), так як саме вона отримує основний трафік.
Проблема виникає з ЧПУ-сторінками у Бітриксі. Якщо компонент bitrix:catalog.section генерує URL типу /catalog/category/sub/ — у Метриці карта скроллінгу буде окремою для кожного розділу, що неудобно для порівняння. Рішення: сгрупувати URL за шаблонами у настройках Метрики через «Групування URL».
Hotjar Scroll Maps: настройка глибини запису
Hotjar пише відсоток видимості кожного елемента — це точніше, ніж просто «дошов до пікселю Y». Підключення — скрипт у <head>, аналогічно тепловым картам. Для сторінок з динамічною підгрузкою контенту (нескінченний скролл у каталозі Бітрікса) Hotjar потрібно повідомити про зміну висоти сторінки:
// Після підгрузки нових товарів через AJAX
if (typeof hj !== 'undefined') {
hj('stateChange', window.location.href);
}
Без цього Hotjar вважає сторінку тої висоти, яка була при інітіалізації, та всі завантажені AJAX-товари попадають у «зону 100% скроллінгу» — карта буде некоректною.
Microsoft Clarity: безплатна альтернатива
Clarity будує карти скроллінгу автоматично, у тому числі правильно обробляє SPA-переходи. Для Бітрікса це плюс — не потрібні ручні виклики stateChange. Код встановлюється один раз:
(function(c,l,a,r,i,t,y){
c[a]=c[a]||function(){(c[a].q=c[a].q||[]).push(arguments)};
t=l.createElement(r);t.async=1;t.src="https://www.clarity.ms/tag/"+i;
y=l.getElementsByTagName(r)[0];y.parentNode.insertBefore(t,y);
})(window, document, "clarity", "script", "XXXXXXXXXX");
У Бітриксі додається у header.php шаблона або через обробник події OnBeforeProlog.
Аналіз «складок» на конкретних шаблонах
Для стандартного шаблону Бітрікса «Старт» або «Корпоративний» типова проблема — блок «Чому ми» розташований на 1500–2000px від верхівки сторінки. Карта скроллінгу покаже, що до нього доходить 15–25% користувачів. Це не означає, що блок потрібна видалити — це означає, що його потрібна підняти або перебудувати структуру сторінки.
На сторінках оформлення замовлення (компонент bitrix:sale.order.ajax) карта скроллінгу особливо цінна: вона покаже, на якому кроці користувачи перестають взаємодіяти з формою. Якщо більшість не доходить до кнопки «Оформити замовлення» — форма занадто довга або елементи розташовані неочевидно.
Продуктивність трекерів
Всі три інструменти (Метрика, Hotjar, Clarity) добавляють до сторінки сторонні скрипти. На слабких мобільних пристроях це 200–400ms додаткового часу виконання. Якщо Core Web Vitals критичні — підключати через defer або setTimeout(..., 1000) після завантаження основного контенту.