Аналітика та звіти для 1С-Бітрікс

Чому 90% лічильників на Бітрікс-сайтах брешуть

Ставиш лічильник Метрики, підключаєш GA4, вішаєш пікселі — наче аналітика є. А потім дивишся: конверсія e-commerce не передається, UTM-мітки зліщають на редиректах, у CRM ліди без джерела. Типова картина — маркетолог дивиться в один звіт, комерційний директор в інший, цифри не збігаються, і всі приймають рішення за відчуттями.

Ми налаштовуємо аналітику на проєктах 1С-Бітрікс — від коректної передачі dataLayer до наскрізної аналітики з ROI по кожній кампанії.

Яндекс.Метрика: більше, ніж просто лічильник

Базове налаштування — і чому його зазвичай роблять криво

Лічильник Метрики ставлять усі. Правильно — одиниці.

• Встановлення через GTM, а не вставкою в header.php — інакше при оновленні шаблону лічильник злетить
• Цілі: не абстрактні «клік по кнопці», а конкретні — basket_add, надсилання форми bx_form_submit, перехід на /personal/order/make/
• Вебвізор — вмикаєш, а він записує 1% сесій, бо в налаштуваннях стоїть семплування. Потрібно явно задати відсоток запису і не забути про GDPR/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 з урахуванням знижок

Дані, які йдуть у Метрику

GA4: подієва модель та її підводні камені

Чому 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 мовчки проковтне невалідні дані та покаже порожні звіти. Жодних помилок у консолі не буде.

Користувацькі параметри, які реально потрібні

Не треба передавати все підряд. П'ять параметрів, які дають 80% користі:

• user_type — guest / registered / wholesale. Поведінка та конверсія відрізняються в рази
• user_group — група користувача з Бітрікс. Дозволяє будувати сегменти по роздрібних vs оптових
• order_count — скільки замовлень у користувача загалом. Перше замовлення і двадцяте — різні воронки
• cumulative_discount — накопичувальна знижка. Впливає на середній чек
• first_source — UTM першого візиту. Зберігається в cookie або в UF_SOURCE користувача

Наскрізна аналітика: де гроші

Метрика бачить візити. CRM бачить угоди. Рекламний кабінет бачить витрати. А зв'язок між ними — розрив. Менеджер закрив угоду на 500К, але Метрика показує джерело (direct), бо клієнт прийшов за прямим посиланням із закладок, а перший контакт був через контекстну рекламу три місяці тому.

Наскрізна аналітика замикає ланцюжок: рекламний клік → візит → лід у CRM → угода → оплата → ROI.

Як збираємо

1. UTM-мітки фіксуємо в cookie з TTL 90 днів та дублюємо в roistat_visit
2. При створенні ліда в Бітрікс24 записуємо UTM у користувацькі поля угоди — UF_CRM_UTM_SOURCE, UF_CRM_UTM_MEDIUM, UF_CRM_UTM_CAMPAIGN
3. Колтрекінг підміняє номер та прив'язує дзвінок до візиту
4. Менеджер веде угоду воронкою, закриває — сума прив'язана до джерела
5. Roistat (або Calltouch, CoMagic) агрегує витрати через API рекламних кабінетів
6. ROI = (виручка - витрати) / витрати. По кожній кампанії, групі, ключовому слову

Інструменти

Дашборди: три екрани замість десяти звітів

Будуємо дашборди в DataLens або Looker Studio. Ключове — не перевантажувати. Директор не буде розбиратися у 40 графіках.

Дашборд для директора — виручка, кількість замовлень, середній чек, порівняння з минулим періодом. П'ять віджетів, оновлення раз на годину.

Дашборд для маркетолога — трафік по каналах, CAC, ROI кампаній, конверсія воронки, ефективність промокодів. Можна детальніше — маркетолог вміє читати дані.

Дашборд для комерційного — конверсія менеджерів, швидкість обробки замовлень, повторні купівлі. Тут DataLens підключаємо напряму до PostgreSQL/MySQL Бітрікса через b_sale_order та b_sale_basket.

Воронка: де саме дірка

Типова воронка Бітрікс-магазину:

Провал на чекауті — найдорожчий. Користувач вже хотів купити, вже поклав у кошик, і тут sale.order.ajax кидає 500-ку, бо не налаштований обробник доставки. Або форма вимагає ІПН у фізичної особи. Кожен такий кейс — прямі втрати.

Когортний аналіз та LTV

Групуємо за місяцем першої купівлі, дивимося retention через 30, 60, 90 днів. У DataLens будується через SQL-запит до b_sale_order з GROUP BY DATE_TRUNC('month', DATE_INSERT).

Головний інсайт когортного аналізу — який канал залучає клієнтів із високим LTV, а не просто дешевих. Контекстна реклама може давати дешеві перші замовлення, але нульовий repeat rate. А SEO-трафік конвертується гірше, зате повертається.

Терміни

Аналітика на Бітріксі — не «поставив лічильник і забув». DataLayer ламається після оновлення модуля sale, UTM-мітки губляться на редиректах ЧПУ, GA4 змінює формат подій. Систему потрібно підтримувати — і ми це робимо.