Аналіз воронки конверсій інтернет-магазину 1С-Bitrix
У карточці товару 3000 переглядів на день, у корзину кладуть 120, до оформлення доходять 40, оплачують 25. Де втрачаються решта 2975? Відповідь — у конкретних кроках воронки, й на 1С-Bitrix ці кроки можна виміряти, розкласти по пристроям і джерелам, а потім точково відремонтувати.
Налаштування цілей у Яндекс.Метриці
Для кожного кроку воронки потрібна окрема ціль. Тип — JavaScript-подія, не «Відвідування сторінки». Оформлення замовлення у Bitrix працює через AJAX у компоненті sale.order.ajax без зміни URL — ціль за адресою сторінки просто не спрацює.
| Крок воронки | Ідентифікатор цілі | Де спрацьовує |
|---|---|---|
| Перегляд каталогу | catalog_view |
Компонент catalog.section |
| Перегляд карточки товару | product_view |
Компонент catalog.element |
| Додавання до корзини | add_to_cart |
Обробник кнопки «У корзину» |
| Початок оформлення | checkout_start |
Компонент sale.order.ajax |
| Замовлення оформлено | order_complete |
Сторінка підтвердження замовлення |
Виклик: ym(XXXXXXXX, 'reachGoal', 'add_to_cart'). Код вставляється у шаблони компонентів або через BX.ready() у спільному скрипті. Для ecommerce-даних (ID товару, ціна, категорія) використовуйте ym(id, 'ecommerce:send', dataLayer) — це дає детализацію до конкретних товарів і розділів.
Ecommerce-події для GA4
Google Analytics 4 працює через gtag.js або GTM. Стандартні ecommerce-події:
-
view_item_list— перегляд каталогу -
view_item— карточка товару -
add_to_cart— додавання у корзину -
begin_checkout— початок оформлення -
purchase— покупка
Дані про товар (ID, назва, ціна, категорія) беруться з $arResult компонентів каталогу. Виводьте їх у data-атрибути елементів або у JS-змінні через result_modifier.php — так розмітка не залежить від шаблону й переживає редизайн.
Де втрачаються покупці: розбір по кроках
Після двох-трьох тижнів збору даних будуйте воронку у Метриці (Звіти -> Конверсії) або GA4 (Explore -> Funnel exploration). Нормальні показники для інтернет-магазину й червоні прапори:
Каталог -> карточка товару: 30–50%. Нижче 20% — проблема з навігацією. Перевірте фасетний фільтр: якщо catalog.smart.filter рендериться довше 400 мс, користувачі йдуть до того, як побачать результат. Включіть індексацію фасетів у налаштуваннях інфоблока — запити до b_iblock_element_property з множинними JOIN на каталозі в 30 000+ товарів без індекса працюють невприйнятно повільно.
Карточка -> корзина: 8–15%. Нижче 5% — слабка карточка. Немає відзивів, не вказані строки доставки, фото в низькій якості. Технічна сторона: кнопка «У корзину» повинна дати миттєвий візуальний відгук. Стандартний catalog.element налаштовується через USE_ELEMENT_COUNTER — але часто простіше написати кастомний AJAX-обробник з анімацією додавання.
Корзина -> оформлення: 40–60%. Нижче 30% — користувач бачить щось несподіване. Зазвичай це вартість доставки, яка з'являється лише в корзині, або відсутність звичного способу оплати. Компонент sale.order.ajax за замовчуванням виводить надлишкову форму. Видаліть необов'язкові поля через Магазин -> Налаштування -> Властивості замовлення: «По батькові», «Індекс», «Факс» — кандидати на вилучення.
Оформлення -> оплата: 50–70%. Нижче 40% — технічна проблема або UX-провал. Редирект на зовнішний платіжний шлюз втрачає 10–15% покупців. Вбудовані віджети (ЮKassa, CloudPayments) утримують користувача на сайті — iframe замість перенаправлення.
Обов'язково сегментуйте по пристроям. Мобільна конверсія на етапі оформлення часто в 2–3 рази нижча за десктопну — це нормальна стартова точка для оптимізації.
Швидкість завантаження й її вплив на воронку
Кожна додаткова секунда завантаження сторінки каталогу скорочує конверсію. На 1С-Bitrix ключові інструменти:
Композитний кеш — видає статичну HTML-версію сторінки й підгружає динамічні блоки (корзину, авторизацію) окремими AJAX-запитами. Включається у налаштуваннях модуля «Композит». Блоки, які не повинні кешуватися, оборачиваються у \Bitrix\Main\Page\Frame.
Монітор продуктивності (Налаштування -> Продуктивність) — показує час рендера кожного компонента. Якщо catalog.section працює довше 500 мс — шукайте проблему у кількості підгружених властивостей або у відсутності індексів.
CDN для статики — налаштовується через модуль CDN. Зображення товарів, CSS, JS роздаються з edge-серверів.
A/B-тестування змін
Google Optimize закритий, але завдання вирішується кастомно:
- При завантаженні сторінки генеруйте варіант (0 або 1), збережіть у
localStorage - Підключіть один із шаблонів блока — наприклад, одношаговий vs багатошаговий checkout
- Передайте варіант у Метрику:
ym(id, 'params', {ab_test: 'checkout_v2'}) - Порівняння — за цільовою конверсією у звіті з сегментацією по параметру
Мінімальний строк тесту — 2 тижні при трафіку від 500 унік на день. Менше — статистична значимість під питанням.
Мікророзмітка й якість трафіку
Schema.org Product у карточці товару підвищує CTR у пошуковій видачі. Більше кліків від цільової аудиторії — вища конверсія на вході у воронку. Стандартний catalog.element підтримує розмітку, але часто генерує її з помилками — перевіряйте через Google Rich Results Test після кожного оновлення шаблону.
Аналіз воронки — регулярний процес, не разова акція. Знімайте метрики щомісячно, фіксуйте кожну змону (видалили поле, змінили кнопку, підключили віджет оплати) й порівнюйте показники повіквартально. Лише так відокремлюється ефект конкретної доопрацювання від сезонних коливань трафіку.