Настройка карт скроллинга на 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) после загрузки основного контента.