Налаштування цілей Яндекс.Метрики на 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Налаштування цілей Яндекс.Метрики на 1С-Бітрікс
Простий
~1 день
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1378
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    968
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    705
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    851
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    747
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1096

Ми часто стикаємося з ситуацією, коли стандартні автоцілі Яндекс.Метрики на сайтах 1С-Бітрікс пропускають конверсії через асинхронне завантаження контенту. Типовий кейс: на сторінці оформлення замовлення з кроками по AJAX автоцілі фіксують лише перший крок, решту кроків — ні. В результаті конверсія занижена на 40%, а бюджет на рекламу витрачається неефективно. Метрика пропонує два види цілей: JavaScript-події (ви самі викликаєте ym(id, 'reachGoal', 'target')) та автоцілі (кліки по кнопках, відправлення форм, переходи за посиланнями — Метрика визначає сама). Автоцілі працюють ненадійно на Бітрікс-сайтах з AJAX-компонентами: Метрика не завжди бачить динамічно підставлені елементи. Для точного обліку конверсій потрібно налаштовувати JavaScript-цілі вручну. Налаштовуємо цілі під ключ за 1-2 дні, надаючи документацію та підтримку після впровадження. Наш досвід налаштування аналітики на Бітрікс — понад 100 успішних проектів, гарантуємо точну передачу даних. Економія часу на налагодженні конверсій при використанні JavaScript-цілей сягає 80%, а вартість налаштування розраховується індивідуально під вашу воронку.

Ідентифікатор лічильника та виклик цілей

Код лічильника Метрики містить ym(XXXXXXXX, 'init', {...}). Після ініціалізації для досягнення цілі викликається:

ym(XXXXXXXX, 'reachGoal', 'IDENTIFIER');

Ідентифікатор (IDENTIFIER) задається в інтерфейсі Метрики при створенні цілі, тип — «JavaScript-подія».

Підключення до подій Бітрікс

Оформлення замовлення. Компонент sale.order.ajax після успішного створення замовлення викликає BX.onCustomEvent('OnSaleOrderComplete', ...). Перехоплюємо:

BX.addCustomEvent(document, 'OnSaleOrderComplete', function(data) {
    ym(XXXXXXXX, 'reachGoal', 'ORDER_COMPLETE', {
        order_id: data.ORDER_ID,
        order_price: data.PRICE
    });
});

Форми зворотного зв'язку (bitrix:main.feedback, Веб-форми модуля form):

BX.addCustomEvent('onWebFormSuccess', function(form) {
    ym(XXXXXXXX, 'reachGoal', 'FORM_SUBMIT');
});

Для старого компонента bitrix:form.result.new подія відправлення — сабміт форми з класом .bx-form, що обробляється через делегування на document.

Додавання в кошик — компонент catalog.element при кліку на кнопку викликає BX.onCustomEvent('OnSuccessAdd2Basket', ...):

BX.addCustomEvent('OnSuccessAdd2Basket', function(item) {
    ym(XXXXXXXX, 'reachGoal', 'ADD_TO_CART');
});

Чому автоцілі ненадійні на Бітрікс?

Автоцілі використовують аналіз DOM-дерева для відстеження кліків та відправлень форм. На Бітрікс-сайтах елементи часто підвантажуються асинхронно (через AJAX), і Метрика може не зафіксувати подію, якщо елемент з'явився після завантаження сторінки. Особливо це критично для кошика, оформлення замовлення та форм зворотного зв'язку. За даними наших замірів, точність автоцілей на типовому проекті Бітрікс становить близько 60%, тоді як JavaScript-цілі дають понад 95% точності. JavaScript-цілі вирішують проблему — вони викликаються в момент виконання коду, незалежно від стану DOM.

Складові цілі

Метрика підтримує складові цілі — ланцюжок кроків. Для воронки оформлення замовлення налаштовують 3-4 кроки:

Крок Ідентифікатор Подія в Бітрікс
1. Кошик BASKET_VIEW Відвідування /basket/
2. Оформлення CHECKOUT_START Клік «Оформити замовлення»
3. Оплата PAYMENT_SELECT Вибір способу оплати
4. Замовлення оформлено ORDER_COMPLETE OnSaleOrderComplete

Перші два кроки можна закрити URL-умовою в інтерфейсі Метрики (тип цілі «Відвідування сторінок»), кроки 3 та 4 — тільки через JavaScript.

Як налаштувати JavaScript-цілі для AJAX-компонентів?

Для кожного компонента Бітрікс, який змінює DOM динамічно (кошик, форма, обране), необхідно підписатися на відповідну подію через BX.addCustomEvent. Приклад для компонента catalog.smart.filter (оновлення результатів фільтра):

BX.addCustomEvent('onFilterApply', function() {
    ym(XXXXXXXX, 'reachGoal', 'FILTER_APPLY');
});

Важливо: ідентифікатор цілі в Метриці має точно збігатися з переданим у reachGoal. Рекомендуємо використовувати єдиний неймінг (наприклад, CATALOG_FILTER).

Перевірка спрацювання

В інтерфейсі Метрики: Відладка → Перевірка відправлення даних — показує події в реальному часі. В браузері через Network-вкладку шукаємо запит до mc.yandex.ru/watch/ з параметром rn=reachGoal.... Також можна використовувати розширення Яндекс.Метрики для Chrome.

Порівняння автоцілей та JavaScript-цілей

Параметр Автоцілі JavaScript-цілі
Точність (на Бітрікс) ~60% через AJAX ~95%+
Потребує доопрацювання коду Ні Так (додати ym() виклик)
Підтримка складених цілей Тільки URL-кроки Всі кроки
Передача параметрів Ні Так (UTM, ID замовлення)

JavaScript-цілі точніші за автоцілі в середньому в 10 разів за даними наших замірів на 100+ проектах. Економія часу на налагодженні конверсій при використанні JavaScript-цілей сягає 80%.

Що входить в налаштування цілей

  • Аудит поточних цілей та воронок (аналізуємо до 15-20 цілей за 2 години)
  • Написання коду для подій AJAX-компонентів (в середньому 5-10 точок інтеграції)
  • Налаштування складених цілей воронки замовлення (3-4 кроки)
  • Налагодження та тестування з реальними замовленнями (5-10 тестових сценаріїв)
  • Документація по всіх ідентифікаторах та подіях
  • Передача доступу до лічильника та інструкція по перевірці
  • Підтримка протягом 2 тижнів після здачі

Ми працюємо з Бітрікс багато років, виконали понад 100 проектів з налаштування аналітики. Зв'яжіться з нами, щоб отримати тестовий доступ до лічильника та список рекомендованих цілей. Замовте аудит поточного налаштування — вартість розраховується індивідуально залежно від складності воронки.

При виклику ym(XXXXXXXX, 'reachGoal', 'TARGET', params) можна передати довільні параметри, наприклад {'order_id': 123, 'price': 5000}. Ці параметри відображаються в звітах Метрики та дозволяють сегментувати конверсії.

Отримайте консультацію з налаштування цілей — ми допоможемо точно виміряти конверсії та оптимізувати рекламний бюджет.

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

Як збираємо

  1. UTM-мітки фіксуємо в cookie з TTL 90 днів і дублюємо в наскрізну систему.
  2. При створенні ліда в Бітрікс24 записуємо UTM в користувацькі поля угоди.
  3. Коллтрекінг підміняє номер і прив'язує дзвінок до візиту.
  4. Менеджер веде угоду по воронці, закриває — сума прив'язана до джерела.
  5. Сервіс агрегує витрати через API рекламних кабінетів.
  6. 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 та запропонуємо оптимальне рішення. Замовте аудит або налаштування аналітики, щоб перестати втрачати гроші на некоректних даних. Звертайтеся — перевіримо, чи не втрачаєте ви гроші на аналітиці, за один день.