Налаштування конверсій Яндекс.Директ на 1С-Бітрікс
Ми часто стикаємося з ситуацією, коли автоматичні стратегії Яндекс.Директу працюють наосліп через некоректно налаштовані цілі. Без правильної передачі конверсій з 1С-Бітрікс звіти показують нулі, а бюджети згорають даремно. Наш досвід понад 7 років з Бітрікс та Метрикою дозволяє гарантувати точне налаштування, яке збільшує конверсію на 30–50%. Правильно налаштовані конверсії дають Директу достатньо даних для навчання алгоритмів оптимізації, що економить до 40% бюджету на однаковому обсязі продажів.
Лічильник Метрики та цілі: що має бути до налаштування Директу
Конверсії Директу спираються на цілі Метрики, тому спочатку — лічильник. У Бітріксі лічильник Метрики додається кількома способами: через модуль bitrix:main.counter у шаблоні, через пряме вставлення в header.php або через OnEpilog.
Для коректної роботи цілей критично: лічильник має завантажуватися до спрацювання цільових подій. Використовуйте синхронну ініціалізацію через ym(counterId, 'init', {...}) з параметром defer: false для сторінок з формами. На практиці більшість сайтів упускають цей момент: лічильник завантажується асинхронно через defer, і швидкі користувачі надсилають форму до ініціалізації Метрики, конверсія втрачається.
У таблиці b_option зручно зберігати ID лічильника: COption::SetOptionString("main", "ya_metrika_id", "XXXXXXXX"). Тоді при зміні лічильника не потрібно лізти в шаблон.
Цілі в Метриці для e-commerce:
-
JavaScript-ціль
order_success— на сторінці «Дякуємо» після оформлення замовлення (найважливіша для Директу) -
JavaScript-ціль
add_to_cart— при додаванні товару в кошик - Складова ціль з кроками: перегляд каталогу → картка товару → кошик → оформлення
Як уникнути дублювання цілей при перезавантаженні сторінки?
При перезавантаженні сторінки «Дякуємо» ціль не повинна фіксуватися повторно. Ми використовуємо прапорець у сесії: після першого виклику ym reachGoal записуємо $_SESSION['conversion_sent'] = true і перевіряємо його перед надсиланням. У компоненті bitrix:sale.order.ajax це реалізується в template.php.
Передача досягнення цілі з Бітрікса
Ціль order_success — найважливіша для Директу. Виклик:
ym(COUNTER_ID, 'reachGoal', 'order_success', { order_price: 4900, currency: 'RUB' }); У Бітріксі сторінка «Дякуємо» — це або окрема сторінка /personal/order/success/, або фінальний крок компонента bitrix:sale.order.ajax. В обох випадках потрібно переконатися, що JS-виклик не задвоюється — при перезавантаженні сторінки ціль не повинна фіксуватися повторно.
Надійний спосіб: у компоненті bitrix:sale.order.ajax у template.php шукаєте блок з умовою успішного створення замовлення ($arResult["NEED_PAY"] || $arResult["ORDER_ID"]) і додаєте виклик Метрики тільки там. Параметри замовлення (order_price) берете з $arResult["ORDER"]["PRICE"].
Для сторінки /personal/order/success/ — компонент bitrix:sale.order.detail дає доступ до деталей замовлення через $arResult. ID замовлення з URL-параметра + CSaleOrder::GetByID($orderId).
Чому офлайн-конверсії критичні для e-commerce?
Якщо частина замовлень обробляється менеджерами (дзвінки, заявки без оплати онлайн), стандартного JS-пікселя недостатньо. Яндекс.Метрика підтримує завантаження офлайн-конверсій через API. На практиці різниця в точності між автоматичним завантаженням з CRM та API — до 15%. API-завантаження в 2 рази точніше за автоматичне з CRM.
Офлайн-конверсії через API Метрики
У Бітріксі це реалізується через обробник події OnSaleOrderStatusUpdate. Коли менеджер переводить замовлення в статус «Виконано», надсилаєте POST-запит на https://api-metrika.yandex.net/management/v1/counter/{counterId}/uploads/client_id:
AddEventHandler("sale", "OnSaleOrderStatusUpdate", function($id, $arFields) { if ($arFields["STATUS_ID"] === "F") { // Finished // Отримуємо client_id з b_sale_order_props або користувача $httpClient = new \Bitrix\Main\Web\HttpClient(); $httpClient->post($apiUrl, $csvData); } }); client_id Метрики потрібно зберігати при оформленні замовлення — це значення з куки _ym_uid або з JavaScript-методу ym(id, 'getClientID', callback). Зберігайте його у властивості замовлення (b_sale_order_props_value) при створенні.
| Метод конверсії | Точність | Складність реалізації |
|---|---|---|
| JS-піксель | Висока (тільки онлайн) | Низька |
| API офлайн | Висока (всі канали) | Середня |
| Автоматичне завантаження з CRM | Середня | Висока |
Структура client_id
`client_id` — це 64-бітне ціле число, що зберігається в кукі `_ym_uid` у відповідях Метрики. Його можна отримати через JavaScript-метод `ym(id, 'getClientID', callback)` або з куки напряму. Для надійності краще використовувати `getClientID` у події `onload`.Зв'язка з Директом: автоматичні стратегії
Після того як цілі працюють і конверсії фіксуються, у Директу перемикаєте стратегію на «Оптимізацію конверсій» з ціллю order_success. Директу потрібно мінімум 10 конверсій за 28 днів для навчання — це важливо враховувати при запуску.
Модуль sale Бітрікса при типовому навантаженні не створює затримок для викликів Метрики, але якщо на сайті агресивне кешування через BXCache з TTL > 3600, перевірте, що сторінка «Дякуємо» не кешується — компонент bitrix:sale.order.ajax має CACHE_TYPE = 'N' за замовчуванням, але кастомні шаблони можуть це ламати.
Що входить у роботу з налаштування конверсій
- Аудит поточного налаштування лічильника Метрики та цілей
- Встановлення лічильника з правильною ініціалізацією
- Налаштування JavaScript-цілей для e-commerce
- Інтеграція офлайн-конверсій через API зі збереженням client_id
- Тестування всіх сценаріїв (онлайн-оплата, дзвінки, заявки)
- Документація з використання та підтримки
Зв'яжіться з нами для аудиту поточного налаштування — виявимо вузькі місця та підвищимо ефективність Директу. Замовте налаштування конверсій під ключ: від лічильника до оптимізації ставок. Отримайте консультацію щодо впровадження офлайн-конверсій.Яндекс.Метрика API для офлайн-конверсій