Веб-аналітика на 1С-Бітрікс: GTM, GA4, Метрика під ключ
Після стандартного встановлення Бітрікс лічильники аналітики не підключені — розробник має вручну розмістити коди Google Analytics та Яндекс.Метрики. Типова помилка — вставити код безпосередньо в шаблон без урахування кешування: лічильник потрапляє в кеш і віддається некоректно, особливо при активному модулі cache. У результаті дані про трафік, конверсії та поведінку користувачів спотворюються, а бізнес-рішення приймаються на основі недостовірної статистики. Для інтернет-магазинів на Бітрікс втрата даних означає невірну оцінку ефективності реклами та втрачену вигоду. Ми вирішуємо цю проблему за 1–2 дні, гарантуючи коректну роботу лічильників на всіх сторінках: від головної до карток товарів з динамічними параметрами.
Як уникнути конфлікту з кешуванням лічильників?
Бітрікс кешує HTML-блоки, і якщо код лічильника потрапляє всередину кешованої області (наприклад, у $APPLICATION->StartResultCache()), він віддається однаковим для всіх користувачів — унікальні параметри cid і gclid не передаються. У GA4 це призводить до втрати 30–50% сесій. Згідно з документацією dev.1c-bitrix.ru, кешування лічильників вимагає винесення за межі кешованих областей. Ми виносимо лічильники в footer.php або використовуємо теговане кешування з динамічними винятками.
Які проблеми вирішує налаштування веб-аналітики на Бітрікс?
Відсутність наскрізної аналітики. Багато магазинів на Бітрікс інтегровані з 1С, CRM та платіжними шлюзами (ЮKassa, Сбер, АТОЛ Онлайн). Без наскрізної аналітики неможливо відстежити шлях клієнта від кліка до оплати. Ми налаштовуємо передачу Google E-commerce Enhanced через Google Tag Manager і синхронізуємо дані з b_sale_basket та b_sale_order.
Невірна фільтрація трафіку. За замовчуванням у звіти потрапляють адміністратори, що спотворює метрики. Налаштовуємо фільтрацію за IP та cookie — виключаємо внутрішніх користувачів. Для інтернет-магазинів це може знизити «чисту» конверсію на 15–25%, зате дані стають реальними.
Чому Google Tag Manager кращий за прямий код?
Використовуємо Google Tag Manager як єдиний контейнер для всіх скриптів: GA4, Яндекс.Метрика, піксель VK, Facebook Pixel. Це дозволяє оновлювати коди без правки шаблону та без перевикладання кешу. Принципова схема:
- У файлі
header.php додаємо два виклики GTM: у <head> і одразу після <body>.
- Обгортаємо їх у перевірку
(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED !== true) die(); — це обов'язково для безпеки.
- Розміщуємо код поза кешованими блоками: після закриваючого тегу
<?$APPLICATION->ShowHead()?>.
- Для кожного типу сторінок (головна, каталог, детальна, кошик) у GTM створюємо тригери, що передають параметри через Data Layer.
Приклад мінімального встановлення GTM у footer.php:
<?php
if (!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED !== true) die();
?>
<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-XXXX" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->
Порівняння методів: пряме розміщення коду (GA4, Метрика) проти GTM
| Параметр |
Прямий код у шаблоні |
Google Tag Manager (GTM) |
| Швидкість встановлення |
1–2 години |
2–3 години (з налаштуванням тригерів) |
| Зміни без розробника |
Ні |
Так, через інтерфейс GTM |
| Конфлікт з кешем |
Високий ризик |
Низький (грамотне налаштування) |
| Підтримка GA4 + Метрика + ретаргетинг |
Тільки через кілька шматків коду |
Один контейнер |
| Ймовірність помилки |
Середня |
Низька (валідація в GTM) |
GTM пришвидшує внесення змін у 3 рази: не потрібно правити шаблон, перевикладати кеш та перевіряти через dev-середовище. Всі правки робляться через інтерфейс GTM і публікуються за 1 хвилину.
Процес роботи
- Аналітика: аудит поточних лічильників, виявлення проблем з кешем, перевірка цілей.
- Проектування: схема Data Layer, тригери для подій (додавання в кошик, оформлення замовлення, реєстрація).
- Реалізація: встановлення GTM, налаштування GA4 та Метрики, фільтрація внутрішнього трафіку, створення першого набору цілей.
- Тестування: перевірка на сторінках каталогу, картках товарів, кошику. Використовуємо Google Tag Assistant та Network-запити.
- Деплой: перенесення налаштувань на бойовий сайт, моніторинг перших 48 годин.
Терміни орієнтовно
- Базове налаштування (GTM, GA4, Метрика, 5 цілей) — від 2 до 4 днів.
- Розширене (наскрізна аналітика, інтеграція з 1С, воронка конверсій, A/B-тести) — від 5 до 8 днів.
Вартість розраховується індивідуально — залежить від складності каталогу, кількості інтеграцій та необхідних звітів. Замовте попередню оцінку — ми проаналізуємо ваш проект за 1-2 дні.
Що входить у роботу
У роботу входить налаштування контейнера GTM та розміщення кодів GA4, Яндекс.Метрики і пікселів соціальних мереж, розробка наскрізної аналітики з передачею даних через Data Layer, фільтрація внутрішнього трафіку та виключення IP адміністраторів. Також ми надаємо документацію по тригерах та змінних GTM, доступ до контейнера для самостійного керування і навчання вашого співробітника. Після деплою надаємо пост-підтримку протягом двох тижнів.
Типові помилки та їх вирішення
| Помилка |
Причина |
Вирішення |
| Лічильник відсутній на внутрішніх сторінках |
Код вставлено лише в головний шаблон |
Розмістити GTM у всіх типах шаблонів через footer.php |
| Втрата даних при увімкненому кеші |
Код всередині кешованого блоку |
Винести код за межі StartResultCache() або використовувати динамічні винятки |
| Невірний Measurement ID |
Скопійовано з прикладу |
Перевірити ID в налаштуваннях GA4 |
| Завищені показники метрики |
Боти не відфільтровані |
Налаштувати фільтрацію ботів у Метриці та GA4 |
| Транзакції не передаються |
Data Layer не ініціалізовано |
Перевизначити dataLayer.push() на сторінках кошика та замовлення |
Гарантії та досвід
Ми налаштували аналітику на більш ніж 200 проектах, 70% з яких — інтернет-магазини на Бітрікс з інтеграцією 1С та платіжних систем. Використовуємо офіційну документацію dev.1c-bitrix.ru. Гарантуємо коректну роботу лічильників на всіх сторінках та конверсійних подіях.
Помилки в лічильниках призводять до невірних бізнес-рішень: ви витрачаєте бюджет на неефективні канали, не бачите реальні точки відтоку клієнтів. Наша гарантія — дані, яким можна вірити.
Отримайте консультацію по вашому проекту. Зв'яжіться з нами — ми розповімо, які метрики критичні для вашого бізнесу і як налаштувати їх без втрати даних.
Чому аналітика 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
}]
}
});
});
| Параметр |
Звідки беремо |
Грабельки |
| ID товару |
PRODUCT_ID з інфоблоку |
Не плутати з ID торгової пропозиції — це різні сутності |
| Категорія |
Ланцюжок розділів інфоблоку |
Метрика чекає формат «Електроніка/Смартфони», роздільник — / |
| Бренд |
Властивість інфоблоку |
Якщо Highload-довідник — потрібен додатковий запит |
| Ціна |
CATALOG_PRICE_1 або тип ціни контрагента |
Передавати фінальну, після знижок |
| Купон |
CSaleBasket::GetList → DISCOUNT_COUPON |
Може бути порожнім — не ламайте dataLayer |
Чому 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 за нашими тестами на великих проектах.
Як збираємо
- UTM-мітки фіксуємо в cookie з TTL 90 днів і дублюємо в наскрізну систему.
- При створенні ліда в Бітрікс24 записуємо UTM в користувацькі поля угоди.
- Коллтрекінг підміняє номер і прив'язує дзвінок до візиту.
- Менеджер веде угоду по воронці, закриває — сума прив'язана до джерела.
- Сервіс агрегує витрати через API рекламних кабінетів.
- ROI = (виручка — витрати) / витрати по кожній кампанії.
| Платформа |
Сильна сторона |
Слабке місце |
| Roistat |
Багатоканальна атрибуція, коллтрекінг, інтеграція з Бітрікс24 |
Щомісячна вартість |
| Calltouch |
Найкращий коллтрекінг на ринку |
Наскрізна аналітика слабша, ніж у Roistat |
| CoMagic (UIS) |
Зв'язка дзвінки + чат + аналітика |
Інтерфейс застарів |
| Бітрікс24 CRM-аналітика |
Безкоштовно, всередині CRM |
Не рахує витрати на рекламу, немає коллтрекінгу |
Дашборди та воронка: де шукати діри
Будуємо дашборди в DataLens або Looker Studio. Ключове — не перевантажувати.
- Дашборд для директора — виручка, кількість замовлень, середній чек, порівняння з минулим періодом. П'ять віджетів, оновлення раз на годину.
- Дашборд для маркетолога — трафік по каналах, CAC, ROI кампаній, конверсія воронки, ефективність промокодів.
- Дашборд для комерційного — конверсія менеджерів, швидкість обробки замовлень, повторні покупки. DataLens підключаємо напряму до PostgreSQL/MySQL Бітрікса через
b_sale_order і b_sale_basket.
| Етап |
Що дивимося |
Де зазвичай проблема |
| Каталог → Картка |
CTR по товарах |
Погані фото, немає ціни в списку |
| Картка → Кошик |
Add-to-cart rate |
Немає кнопки «Купити» на першому екрані |
| Кошик → Чекаут |
Checkout initiation |
Неочікувана вартість доставки |
| Чекаут → Замовлення |
Completion rate |
Обов'язкова реєстрація, падіння sale.order.ajax |
Провал на чекауті — найнайдорожчий. Користувач уже хотів купити, вже поклав у кошик, і тут 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; документація по всіх подіях та параметрах; навчання маркетологів та комерційного відділу роботі зі звітами; технічна підтримка на місяць після запуску.
| Завдання |
Термін |
| Метрика + eCommerce (з коректним dataLayer) |
3-5 днів |
| GA4 + Enhanced E-commerce |
3-5 днів |
| Наскрізна аналітика (Roistat/Calltouch + CRM) |
2-4 тижні |
| Дашборди в DataLens/Looker Studio |
1-2 тижні |
| Комплексна система |
4-8 тижнів |
Вартість розраховується індивідуально залежно від обсягу робіт та складності інтеграцій. Отримайте консультацію — ми проаналізуємо ваш поточний dataLayer та запропонуємо оптимальне рішення. Замовте аудит або налаштування аналітики, щоб перестати втрачати гроші на некоректних даних. Звертайтеся — перевіримо, чи не втрачаєте ви гроші на аналітиці, за один день.
