Підключення Enhanced Ecommerce Яндекс.Метрики для 1С-Бітрікс

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

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

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

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

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    943
  • 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
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1074

Інтеграція Enhanced Ecommerce Яндекс.Метрики з 1С-Бітрікс

Ми часто стикаємося з ситуацією, коли власник інтернет-магазину на 1С-Бітрікс вважає, що достатньо встановити лічильник Метрики — і дані по продажах вже у звітах. На ділі без передачі подій Enhanced Ecommerce аналітика зводиться до підрахунку візитів і кліків. Наше завдання — налаштувати повну воронку: від перегляду картки до оплати, з розбивкою по товарах, брендах і категоріях. Enhanced Ecommerce в 3 рази точніше стандартної схеми з цілями, оскільки передає детальні дані про кожен товар. Розглянемо реалізацію dataLayer-подій, налагодження та гарантоване серверне надсилання транзакцій.

Принцип роботи Enhanced Ecommerce

Яндекс.Метрика отримує дані про транзакції через об'єкт dataLayer — JavaScript-масив, в який сторінка пушить події. Лічильник Метрики зчитує події визначеної структури та надсилає їх на сервери Яндексу. Основні події: detail (перегляд картки), add (додавання в кошик), remove (видалення з кошика), purchase (здійснення покупки). Кожна подія містить об'єкт ecommerce з масивом products. Продукт описується полями: id, name, price, brand, category, quantity, variant.

Як реалізувати dataLayer в 1С-Бітрікс?

Штатної інтеграції Enhanced Ecommerce в Бітрікс немає — модуль sale надсилає лише базовий код лічильника. Реалізація лягає на розробника.

Подія detail — додається в шаблон компонента catalog.element. У result_modifier.php або template.php формується масив товару і пушиться в dataLayer:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
    "ecommerce": {
        "detail": {
            "products": [{
                "id": "SKU-1234",
                "name": "Назва товару",
                "price": 2500,
                "brand": "Бренд",
                "category": "Розділ/Підрозділ"
            }]
        }
    }
});

Подія add — спрацьовує при кліку на кнопку «В кошик». У Бітрікс додавання в кошик зазвичай йде через AJAX-запит до sale.basket.basket. Потрібно перехопити успішну відповідь і пушити подію. Найнадійніший спосіб — підписатися на кастомну JS-подію BX.onCustomEvent('OnBasketChange') або обернути стандартний обробник.

Подія remove — аналогічно add, спрацьовує при видаленні з кошика. Перехоплюється через той самий OnBasketChange з аналізом різниці станів кошика.

Подія purchase — найкритичніша. Формується на сторінці «Дякуємо за замовлення» (sale.order.ajax → шаблон підтвердження). Дані замовлення беруться з \Bitrix\Sale\Order::load($orderId):

window.dataLayer.push({
    "ecommerce": {
        "purchase": {
            "actionField": {
                "id": "ORDER-5678",
                "revenue": 7500,
                "shipping": 300
            },
            "products": [
                {"id": "SKU-1234", "name": "Товар 1", "price": 2500, "quantity": 3}
            ]
        }
    }
});

Чому серверне надсилання через OnSaleOrderPaid критичне?

Покладатися лише на клієнтський dataLayer ризиковано — користувач може закрити сторінку до спрацьовування скрипта. Для гарантованого обліку транзакцій використовується обробник події OnSaleOrderPaid. При зміні статусу оплати на «Оплачено» серверний скрипт надсилає дані в Метрику через Measurement Protocol або записує їх в окрему чергу для подальшого завантаження через API офлайн-конверсій. Такий підхід виключає втрату даних і дублювання транзакцій. Середній чек магазину при правильному налаштуванні збільшується на 15–20% за рахунок точної атрибуції.

Технічні вимоги для серверного надсилання - PHP 8.1+ з підтримкою cURL - Бітрікс версія 21+ (використовується D7) - Доступ до налаштувань лічильника Яндекс.Метрики (номер лічильника та OAuth-токен) - Обробник події OnSaleOrderPaid в кастомному модулі або у файлі init.php

Налаштування цілей

В інтерфейсі Яндекс.Метрики створюються цілі типу «JavaScript-подія» для відстеження конкретних дій:

Ціль Ідентифікатор Тригер
Перегляд картки product_detail Завантаження сторінки товару
Додавання в кошик add_to_cart Клік «В кошик»
Початок оформлення begin_checkout Перехід на сторінку оформлення
Завершення замовлення purchase_complete Сторінка підтвердження

Цілі надсилаються через ym(COUNTER_ID, 'reachGoal', 'add_to_cart') паралельно з dataLayer-подіями. Вони доповнюють ecommerce-дані і дозволяють будувати складові цілі для воронок.

Подія Клієнтський dataLayer Серверне надсилання
Надійність Середня (залежить від браузера) Висока (гарантована)
Затримка Миттєво 1–5 хвилин (офлайн-конверсії)
Дублювання Можливе при оновленні сторінки Виключено через перевірку прапорця
Дані про товари Повні Тільки ID та кількість

Що входить у налаштування електронної комерції

Ми працюємо з Бітрікс 10+ років, реалізували 150+ проєктів. У стандартний пакет входить:

  • Аудит поточної структури dataLayer та лічильника
  • Розробка подій detail, add, remove, purchase
  • Інтеграція серверного надсилання через OnSaleOrderPaid
  • Створення цілей та воронок у Яндекс.Метриці
  • Тестування на тестовому та бойовому контурах
  • Навчання вашого менеджера роботі зі звітами
  • Документація з впроваджених подій

Налагодження

Налагодження Enhanced Ecommerce — найтрудомісткіший етап. Інструменти:

Консоль браузера — після кожної дії перевіряйте вміст window.dataLayer. Команда JSON.stringify(dataLayer, null, 2) покаже всі накопичені події.

Яндекс.Метрика → Параметри візитів — у звіті «Зміст → Параметри візитів» можна побачити, які ecommerce-події зафіксувала Метрика. Дані з'являються із затримкою 5-10 хвилин.

Tag Assistant від Яндекса — розширення для браузера, що показує в реальному часі, які дані надсилаються в лічильник. Дозволяє виявити: відсутність обов'язкових полів, некоректний формат ціни (рядок замість числа), дублювання подій.

Типові помилки:

  • Ціна передається як рядок з пробілами ("2 500" замість 2500) — Метрика ігнорує такі значення.
  • Подія purchase спрацьовує при кожному оновленні сторінки підтвердження — дублюються транзакції. Рішення: перевіряти прапорець window.ecommerceSent або зберігати ID відправленого замовлення в sessionStorage.
  • category містить повний хлібний шлях замість ієрархії через / — звіт за категоріями ламається.
  • Не підключено контейнер ecommerce в налаштуваннях лічильника (Налаштування → Електронна комерція → галочка «Надсилати дані електронної комерції»).

Хочете налаштувати повну аналітику продажів? Зв'яжіться з нами — оцінимо ваш проєкт за 1 день. Отримайте консультацію з інтеграції Enhanced Ecommerce.

Чому 1С-Бітрікс — флагман e-commerce?

Фасетний індекс на каталозі з 200 000 SKU не побудовано — bitrix:catalog.smart.filter відпрацьовує 4 секунди замість 200 мс, і покупець іде. Наша розробка інтернет-магазинів на 1С-Бітрікс виключає такі сценарії: від архітектури інфоблоків та типів цін до кластерної балансировки під пікові навантаження. Типова помилка новачків — не налаштовано композитний кеш (bitrix:main.composite), і сторінки карток завантажуються по 5 секунд. Це вбиває конверсію швидше, ніж будь-який баг у кошику.

Двостороння синхронізація з 1С через CommerceML — каталог, ціни, залишки, замовлення та статуси. Налаштовується з адмінки модулем catalog -> «Обмін з 1С». Вивантаження на маркетплейси через YML-фіди (catalog.export) для Яндекс.Маркет, Google Shopping, Ozon, Wildberries.

Як ми вирішуємо ключові проблеми продуктивності?

bitrix:catalog.smart.filter без фасетного індексу генерує запити, які кладуть MySQL. Рішення: будуємо b_catalog_iblock_index — час відповіді падає з 4 секунд до 100–200 мс. Для SEO-фільтрів використовуємо catalog.seo.filter — індексовані сторінки перетинів фільтрів з унікальними мета-тегами.

Композитний кеш (bitrix:main.composite) прискорює завантаження сторінок у 3–5 разів порівняно зі звичайним. Мета — TTFB картки товару < 200 мс. Для сесій використовуємо Redis (SESSION_SAVE_HANDLER = redis в .settings.php). Lazy load зображень, CDN для статики, оптимізація SQL (особливо JOIN-и на b_iblock_element_property).

Чому кешування критичне для інтернет-магазину?

Кожна секунда затримки завантаження сторінки знижує конверсію в середньому на 7%. При TTFB > 400 мс 32% користувачів залишають сайт. Композитний кеш віддає сторінку з HTML, минаючи виконання PHP та запити до бази — це дає виграш до 5 разів за часом. Для карток товарів з частими змінами цін та залишків використовуємо теговане кешування: інвалідація відбувається лише за порушеними сутностями. На практиці вдавалося знизити TTFB з 1,2 секунди до 180 мс. Економія часу на завантаження каталогу — до 60%.

Типи магазинів та їх особливості

Тип магазину Ключові модулі Особливості
B2C роздріб catalog.smart.filter, catalog.compare.list, відгуки, рейтинги Фасетний індекс, конверсійна воронка від картки до оплати
B2B опт дилерські ціни (b_catalog_group), мін. партії, кредитні ліміти Особисті кабінети, швидке замовлення за артикулом, PDF-рахунки
Цифрові товари ліцензії, підписки, файли OnSaleOrderPaid -> автоматична видача доступу
Маркетплейс модуль «Маркетплейс» або кастом Декілька продавців, роздільний облік, комісійна модель
PWA / мобільні Progressive Web App, React Native + REST API Офлайн-каталог, push-повідомлення

Інтеграції: платіжні системи, доставка, CRM, маркетплейси

Платіжні системи. Обробники в sale.handlers: ЮKassa, CloudPayments, Тинькофф, Сбербанк, Apple Pay, Google Pay, розстрочка. Callback sale.payment.notify для підтвердження статусу. Доставка. Обробники sale.delivery для СДЭК, Boxberry, Почту Росії, DPD — розрахунок вартості по API в реальному часі, трекінг. Складський облік. Резервування (RESERVED = Y в b_sale_basket), автоматичне списання при відвантаженні, сповіщення при залишках нижче порогу, передзамовлення для товарів в дорозі. CRM. Бітрікс24 або amoCRM — замовлення з b_sale_order ідуть автоматично, клієнтська база синхронізується. Тригери: покинутий кошик, запит відгуку, реактивація. Маркетплейси. Вивантаження через YML на Ozon, Wildberries, Яндекс.Маркет. Замовлення стікаються в єдину систему. Аналітика та маркетинг. GA4, Яндекс.Метрика, email-розсилки (Unisender, SendPulse). Логістика. МійСклад, Антор — етикетки, складальні листи.

Міграція з інших CMS

Перехід з OpenCart, WooCommerce, Shopify, MODX: перенесення каталогу (елементи, властивості, розділи, зображення, SEO-URL), міграція клієнтської бази (b_user) та історії замовлень (b_sale_order), 301-редиректи через urlrewrite.php. Паралельна робота на перехідний період — старий сайт продає, новий приймається. Досвід команди — 50+ проектів міграції.

Що входить в роботу (deliverables)

Deliverable Опис
Технічне завдання Бізнес-вимоги, структура каталогу, інтеграції, логіка кошика
Архітектура інфоблоків Типи цін, властивості, розділи, HL-блоки, ORM-сутності
Компоненти та шаблони Кастомні або адаптовані штатні (Component 2.0)
Інтеграції Платежі, доставка, CRM, маркетплейси, 1С
Документація Інструкції з наповнення, REST API, схема БД
Навчання команди Робота з адмінкою, вивантаженнями, оновленнями
Гарантія Безкоштовна підтримка 3 місяці після запуску, виправлення багів

Етапи та терміни

Середній проект — 2–4 місяці:

  1. Аналітика (1–2 тижні) — бізнес-вимоги, структура каталогу, інтеграції, ТЗ
  2. Дизайн (2–3 тижні) — прототипи, дизайн-система, макети
  3. Розробка (4–8 тижнів) — компоненти, шаблони, інтеграції, наповнення
  4. Тестування (1–2 тижні) — функціональне, навантажувальне, приймальне
  5. Запуск (2–3 дні) — деплой, моніторинг, оперативна підтримка

Вартість розраховується індивідуально — зв'яжіться з нами для оцінки бюджету. Наприклад, магазин на 50 000 товарів з інтеграцією 1С та CRM — бюджет варіюється в залежності від складності. MVP для старту доступний за мінімальною планкою. Економія на завантаженні каталогу до 60% часу.

Програма лояльності та конверсія

Бонусна система: бали за покупки, відгуки, рекомендації. Правила нарахування за категоріями, ліміт оплати балами, термін згоряння — все в особистому кабінеті. VIP-рівні (бронза, срібло, золото, платина) з підвищеним кешбеком та безкоштовною доставкою. Рекомендації «Вам сподобається», «Доповніть покупку» — вбудовані інструменти Бітрікс + RetailRocket або Mindbox. Тригери: знижка до дня народження, промокод для повернення, ланцюжок за інтересами. Персоналізація через catalog.recommended.products та catalog.viewed.products. A/B-тестування двох варіантів картки на реальному трафіку. Enhanced E-commerce в GA4 та Яндекс.Метриці — повний шлях від кліка до повторного візиту.

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