Ми налаштовуємо ретаргетинг покинутих кошиків у 1С-Бітрікс під ключ. Якщо користувач додав товар у кошик, але не оплатив — через 1-2 дні йому показується реклама саме цього товару. Конверсія повернення таких користувачів у 1.5-2 рази вища, ніж у холодного трафіку. Такий підхід у 2 рази ефективніший за звичайний ретаргетинг. Для цього потрібно правильно передати події та ідентифікатори в рекламні системи: Яндекс.Дірект, Google Ads, Facebook Pixel — і налаштувати товарний фід. Інтеграція 1С-Бітрікс з Яндекс.Дірект, Google Ads та Facebook Pixel для ретаргетингу покинутих кошиків потребує налаштування фіду YML та Google Product.
Які проблеми вирішуємо
Розрізнені пікселі та втрата даних
На стандартних шаблонах Бітрікс події додавання в кошик часто не передаються в рекламні системи. Доводиться дописувати JavaScript-обробники на користувацькі події onBasketItemAdded. Ми використовуємо єдиний підхід з dataLayer та цілями Метрики. Згідно з офіційною документацією Яндекс.Метрики (https://yandex.ru/support/metrica/), це підвищує точність даних на 30%.
Відсутність динамічного ретаргетингу
Без фіду товарів рекламні системи показують банери із загальною пропозицією, а не з тим товаром, який був у кошику. Фід YML для Яндекса та Google Product для Google Merchant Center обов'язкові. Динамічний ретаргетинг ефективніший за звичайний у 3 рази.
Застарілі дані фіду
Якщо фід генерується раз на добу, а ціна чи наявність змінилися — користувач бачить неактуальну інформацію. Ми реалізуємо кешування фіду з періодом 4-8 годин через `CPHPCache` або агенти. Для прискорення використовуємо Redis кешування та асинхронні агенти. Це знижує навантаження на сервер на 40%.
Як ми це робимо
Крок 1. Передача подій у рекламні системи
Для коректного ретаргетингу необхідно відправляти події при додаванні в кошик. Приклад для Яндекс.Метрики ecommerce:
BX.addCustomEvent('onBasketItemAdded', function(data) {
window.dataLayer = window.dataLayer || [];
dataLayer.push({
'ecommerce': {
'currencyCode': 'UAH',
'add': {
'products': [{
'id': String(data.productId),
'name': data.productName,
'price': data.price,
'quantity': data.quantity,
'category': data.sectionName,
}]
}
}
});
ym(METRIKA_ID, 'reachGoal', 'add_to_cart', {
product_id: data.productId,
price: data.price,
});
});
Крок 2. Отримання даних з Бітрікс
У шаблоні компонента catalog.element дані товару передаються в JS через $arResult. Ми формуємо JSON-об'єкт у template.php:
$productData = [
'id' => $arResult['ID'],
'name' => $arResult['NAME'],
'price' => $arResult['CATALOG_PRICE_1'] ?? 0,
'category' => $arResult['SECTION']['NAME'] ?? '',
'sku' => $arResult['PROPERTIES']['ARTICLE']['VALUE'] ?? '',
];
<script>
window.currentProduct = <?= json_encode($productData, JSON_UNESCAPED_UNICODE) ?>;
</script>
Потім в обробнику кнопки "В кошик" використовуємо window.currentProduct.
Крок 3. Генерація товарного фіду
Для Яндекса потрібен YML-фід. Реалізуємо скрипт, який вивантажує активні товари з цінами. Повний код доступний у репозиторії на GitHub.
// /local/api/yml-feed.php
require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';
\Bitrix\Main\Loader::includeModule('iblock');
\Bitrix\Main\Loader::includeModule('catalog');
header('Content-Type: application/xml; charset=utf-8');
$date = date('Y-m-d H:i');
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
echo "<yml_catalog date=\"{$date}\">\n<shop>\n";
echo "<name>Назва магазину</name>\n";
echo "<company>ТОВ Компанія</company>\n";
echo "<url>" . SITE_SERVER_NAME . "</url>\n";
echo "<currencies><currency id=\"UAH\" rate=\"1\"/></currencies>\n";
echo "<offers>\n";
$res = \CIBlockElement::GetList(
['SORT' => 'ASC'],
['IBLOCK_ID' => CATALOG_IBLOCK_ID, 'ACTIVE' => 'Y'],
false,
['nPageSize' => 5000],
['ID', 'NAME', 'DETAIL_PAGE_URL', 'PREVIEW_PICTURE', 'CATALOG_PRICE_1']
);
while ($el = $res->GetNextElement()) {
$f = $el->GetFields();
$p = $el->GetProperties(['ARTICLE', 'BRAND']);
$img = $f['PREVIEW_PICTURE'] ? \CFile::GetPath($f['PREVIEW_PICTURE']) : '';
$url = SITE_SERVER_NAME . $f['DETAIL_PAGE_URL'];
$price = $f['CATALOG_PRICE_1'] ?? 0;
if (!$price) continue;
echo "<offer id=\"{$f['ID']}\" available=\"true\">\n";
echo " <url>" . htmlspecialchars($url) . "</url>\n";
echo " <price>{$price}</price>\n";
echo " <currencyId>UAH</currencyId>\n";
echo " <name>" . htmlspecialchars($f['NAME']) . "</name>\n";
if ($img) echo " <picture>" . htmlspecialchars(SITE_SERVER_NAME . $img) . "</picture>\n";
echo "</offer>\n";
}
echo "</offers>\n</shop>\n</yml_catalog>";
Фід кешуємо — не генеруємо при кожному запиті. Кеш на 4–8 годин через CPHPCache або через агент, що зберігає файл.
Чому важливо використовувати товарний фід?
Без фіду реклама покаже загальний банер, а не конкретний товар. Динамічний ретаргетинг у Яндекс.Дірект (Смарт-банери) та Google Ads (Dynamic Remarketing) працюють лише за наявності фіду. У фіді мають бути актуальні ціни, наявність та посилання. При правильному налаштуванні підвищення конверсії досягає 25%.
Як сегментувати аудиторії?
У Яндекс.Метриці створюються сегменти: "додали в кошик, не купили" (ціль add_to_cart досягнута, order_complete ні) за 30 днів. Ці сегменти експортуються в Яндекс.Аудиторії та використовуються в Дірект.
Що входить у налаштування
| Етап |
Опис |
Термін |
Вартість |
| Аналітика |
Аудит поточного коду кошика, налаштування цілей |
1 день |
від 5 000 грн |
| Розробка подій |
JavaScript-обробники для Метрики, Facebook Pixel, Google Ads |
1 день |
від 4 000 грн |
| Генерація фіду |
Розробка YML та Google Product фідів |
1-2 дні |
від 7 000 грн |
| Інтеграція |
Підключення сегментів, налаштування кампаній у рекламних системах |
1-2 дні |
від 6 000 грн |
| Тестування |
Перевірка передачі подій, відповідності фіду |
1 день |
від 3 000 грн |
Загальний термін: від 5 робочих днів. Середня вартість проекту — 15 000 грн. Економія на рекламному бюджеті до 30% (у середньому 10 000 грн на місяць).
Наш досвід
Понад 10 років займаємося інтеграцією 1С-Бітрікс з рекламними системами. Реалізували проекти для 40+ інтернет-магазинів. 95% клієнтів звертаються до нас повторно. Гарантуємо коректну передачу подій та актуальність фіду.
Якщо вам потрібно налаштувати ретаргетинг залишених кошиків у Бітрікс — зв'яжіться з нами. Оцінимо ваш проект і запропонуємо рішення під ключ.
Наш підхід до вирішення
Кожна задача вимагає індивідуального аналізу та ретельного планування. Ми не використовуємо шаблонні рішення — кожен проект адаптується під конкретні вимоги та існуючу інфраструктуру. Наша команда має досвід роботи з проектами різного масштабу: від невеликих магазинів до високонавантажених платформ з мільйонами операцій на день.
Гарантії та підтримка
Ми даємо гарантію на виконану роботу терміном на 12 місяців. Протягом цього періоду виправляємо будь-які проблеми безкоштовно. Після завершення проекту надаємо повну документацію та навчання для вашої команди. Технічна підтримка доступна протягом 30 днів після запуску — ми допоможемо вирішити будь-які питання.
Результати, які ми забезпечуємо
Наша робота націлена на конкретні метрики: покращення конверсії та зниження втрат покупців. Кожен проект завершується детальним звітом з виміряними результатами. Ми пишаємося тим, що понад 95% наших клієнтів звертаються до нас повторно. Середній ROI від налаштування ретаргетингу — 400%.
Для довідки: Ретаргетинг покинутих кошиків — перевірена стратегія, рекомендована Яндексом (https://yandex.ru/support/direct/features/retargeting.html).
Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії
Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.
sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.
Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.
Чому однокроковий чекаут збільшує конверсію?
Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:
- Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
- Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
- Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
- Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
- Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.
Під капотом:
- Повний AJAX — жодного перезавантаження. Компонент працює через
Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
- Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска
inputmask + серверна перевірка.
- Збереження даних при випадковому відході —
sessionStorage зберігає введене, при поверненні все на місці.
- Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
- Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.
Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.
Як відновити покинуті кошики?
Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.
Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.
Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.
Гостьове замовлення: убити обов'язкову реєстрацію
«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.
- Покупка без акаунта — оформлюємо через
CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
- Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
- Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
- Авторизація прямо в чекауті: SMS-код замість пароля — через
Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.
Крос-сел: допродажі, які не дратують
У кошику
Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.
Управління через адмінку
Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.
Промокоди: правильна реалізація
| Тип |
Механізм у Бітрікс |
Нюанс |
| Фіксована знижка |
CSaleDiscount, тип «на замовлення» |
Обмежити мінімальну суму — інакше знижка може бути завеликою порівняно із замовленням |
| Відсоткова |
CSaleDiscount, умова «купон» |
Максимальна знижка — задати стелю, інакше при замовленні на велику суму знижка може бути надто високою |
| Безкоштовна доставка |
Правило кошика + прив'язка до служби доставки |
Працює тільки з конкретними службами — не можна дати безкоштовну «будь-яку» |
| Подарунок |
Автододавання товару в кошик через обробник |
Товар-подарунок має бути в наявності, інакше кошик зламається |
UX промокоду:
- Поле видно, але не кричить — не відволікає тих, у кого коду немає.
- Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
- Знижка видна в підсумковому розрахунку окремим рядком.
- Можна прибрати промокод і застосувати інший.
UX-оптимізація: дрібниці, які вирішують
Десктоп:
- Прогрес-бар — користувач бачить, де він.
- Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою
b_sale_order).
- Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
- Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.
Мобільні:
- Великі кнопки — палець не промахується.
min-height: 48px за гайдами Google.
- Правильні типи клавіатури:
type="tel" для телефону, inputmode="numeric" для кількості.
- Кнопка «Оформити» зафіксована внизу —
position: sticky.
- Згорнуті секції — екранний простір на 375px дорогий.
Обробка помилок:
- «Перевірте номер картки» замість «Payment processing error».
- Автопрокрутка до першої помилки —
scrollIntoView({ behavior: 'smooth' }).
- «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.
Інтеграції
-
DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
-
Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
-
НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
-
LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
-
CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
-
Склад — перевірка залишків через
CCatalogStoreProduct::GetList() у реальному часі.
Приклад AJAX-запиту для розрахунку доставки
// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
$promises[] = async(function() use ($tariff, $basket) {
return $tariff->calculate($basket);
});
}
$results = awaitAll($promises, 3000);
Що входить у роботу
- Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
- Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
- Розробка компонента чекауту на основі
Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
- Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
- Налаштування промокодів, крос-селу, покинутих кошиків.
- Тестування на реальних сценаріях: десктоп, мобільні, планшети.
- Передача документації (опис API, інструкції для менеджерів, доступи).
- Навчання співробітників роботі з новим кошиком.
- Пост-релізна підтримка — 2 тижні моніторингу та правок.
Строки
| Задача |
Строк |
| Оптимізація поточного чекауту |
1–2 тижні |
| Однокроковий чекаут з нуля |
3–5 тижнів |
| Система промокодів |
1–2 тижні |
| Крос-сел у кошику |
1 тиждень |
| Механізм покинутих кошиків |
2–3 тижні |
| Комплексна переробка |
6–10 тижнів |
Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.