Налаштування email-повідомлень про покинутий кошик 1С-Бітрікс

Покинутий кошик: де втрачаються замовлення і чому листи не надходять

Покинутий кошик у 1С-Бітрікс — це не «клієнт передумав», а розрив у ланцюжку подій. Користувач додає товар, переходить до оформлення, заповнює поля — і йде на кроці оплати. Замовлення при цьому не створюється: у базі немає ні запису, ні прив'язки до покупця, ні тригера для листа. З боку бізнесу це виглядає як тиша в статистиці, хоча трафік і додавання в кошик були.

Втрачені замовлення майже завжди розпадаються на два класи. Перший — події оформлення замовлення не фіксуються: модуль інтернет-магазину не пише проміжний стан кошика, а кошик живе лише в сесії браузера. Клієнт закрив вкладку — дані зникли, відновлювати нічого.

Другий — події є, але повідомлення про кошик не доходять: шаблон поштової події не прив'язаний до типу, лист іде в спам через відсутність коректних записів домену, або відправка падає на етапі черги й осідає в логах агентів.

Діагностика воронки починається з логів. Ми дивимося, чи реєструється поштова подія в журналі, чи доходить вона до агента відправки, чи є запис у таблиці відписок і як відпрацьовує повернення. Якщо подія не створюється взагалі — проблема в логіці фіксації кошика, а не в пошті.

Якщо створюється, але листів немає — розбираємо транспорт: налаштування SMTP, ліміти хостингу, репутацію домену. Часто обидва дефекти сусідять: половина кошиків не зберігається, а зі збереженої половини повідомлень частина мовчки губиться.

Розбираємо, як це закривається: спочатку відновлюємо фіксацію подій на кожному кроці оформлення, потім лагодимо доставку повідомлень і лише після цього налаштовуємо самі сценарії повернення покупця.

Що дає налаштований ланцюжок листів про покинутий кошик

Налаштований ланцюжок листів про покинутий кошик — це не «один лист через добу», а послідовність дотиків, прив'язана до поведінки користувача на сайті.

Перший лист надсилається через 30-60 хвилин після того, як кошик залишився без руху: за цей час людина ще пам'ятає, що обирала, і ймовірність повернення максимальна. Далі — другий дотик через добу і третій через 3-5 днів, якщо замовлення так і не оформлено.

Така схема повертає помітну частку покинутих кошиків, тоді як одиничний лист «ви щось забули» майже не працює.

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

Це напряму впливає на конверсію кошика: чим коротший розрив між дією і листом, тим вища частка повернень.

Друга частина — зниження ручної роботи. Коли автоматичні листи беруть на себе первинний дотик, менеджери не витрачають час на обдзвін «охололих» кошиків і підключаються лише там, де клієнт відкрив лист або перейшов за посиланням.

Навантаження на менеджерів падає, а увага йде на гарячі замовлення, де участь людини реально підвищує суму угоди.

Ми збираємо ланцюжок на даних із самого кошика: підставляємо склад замовлення, актуальну ціну та залишки, додаємо посилання повернення в кошик зі збереженим товаром.

Якщо товар закінчився або ціна змінилася, лист це враховує — клієнт не приходить на порожню сторінку і не втрачає довіру. Окремо налаштовуємо сегментацію: авторизовані та гості, повторні та разові покупці отримують різні сценарії.

Усе це працює на штатних засобах 1С-Бітрікс і Бітрікс24 без зовнішніх сервісів розсилок, тому дані про замовлення не залишають ваш контур. Ми налаштовуємо журналювання надсилань і відписок, щоб бачити, які кроки ланцюжка дають повернення замовлень, а які можна прибрати.

Способи надсилання: транзакційні листи, розсилки та зовнішні сервіси

Повідомлення про покинутий кошик — це транзакційне повідомлення: воно ініціюється дією конкретного користувача і має надійти саме йому. Якщо надіслати його через масову розсилку, лист потрапить під загальні правила прогріву та репутації домену, а тригер втратить адресність. Розбираємо, які канали доставки реально використовують і де в кожного межа.

Що визначає доставлюваність

Ключовий фактор — не рушій надсилання, а репутація домену-відправника та коректність автентифікації. Листи про покинутий кошик краще надсилати з окремого піддомену: тоді скарги та відписки не зачіпають основне ділове листування.

Шаблони листів при цьому будуються на даних кошика — склад, сума, посилання на повернення до оформлення, — і підставляються в момент спрацювання тригера, а не при вивантаженні.

Як обирають на практиці

Для інтернет-магазину з потоком у сотні замовлень достатньо транзакційних листів засобами платформи з винесеним піддоменом. Коли додаються сегменти, A/B-тести шаблонів та аналітика відкриттів, підключають сервіс розсилок.

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

Етапи налаштування повідомлень про покинутий кошик

Налаштування повідомлень про покинутий кошик — це не вмикання галочки в налаштуваннях, а послідовність робіт, де кожен етап спирається на дані попереднього. Нижче — як ми ведемо проєкт від аудиту подій до передачі регламентів.

1. Аудит подій і даних. Дивимося, які дії покупця фіксуються в системі: додавання товару, зміна кількості, вхід в оформлення, вихід зі сторінки. Перевіряємо, чи прив'язаний кошик до користувача чи до сесії, як зберігається контакт — з профілю, з форми чи з cookie.

   На цьому етапі стає зрозуміло, за якими подіями взагалі можна будувати тригери, а де даних не вистачає.

2. Проєктування схеми повідомлень. Визначаємо ланцюжок: скільки листів, через які інтервали, що відбувається при поверненні покупця. Фіксуємо умови зупинки — оформлене замовлення, відписка, повторне надсилання. Схема узгоджується до початку робіт, щоб не переробляти логіку на живому трафіку.

3. Налаштування тригерів. Реалізуємо відбір кошиків за часом бездіяльності, виключаємо службові та тестові акаунти, підключаємо шаблони листів із підстановкою товарів і посиланням на повернення до оформлення.

   Окремо налаштовуємо розклад надсилання, щоб листи не йшли вночі та у вихідні, коли їхня відкриваність падає.

4. Тестування листів. Проганяємо сценарії на тестових кошиках: одиночний товар, кілька позицій, видалений товар, уже оформлене замовлення. Перевіряємо доставку на популярні поштові сервіси, коректність верстки на мобільних, роботу посилань і відписки. Окремо дивимося, що покупець не отримує два листи підряд при повторному візиті.

5. Запуск і спостереження. Вмикаємо розсилку на частині трафіку, звіряємо фактичне надсилання з планом, відстежуємо повернення до оформлення. Якщо частка відкриттів або переходів нижча за очікувану, коригуємо інтервали та текст.

6. Передача документації та регламентів. Віддаємо замовнику опис схеми, список тригерів, шаблони листів та інструкцію щодо правок. Фіксуємо, як змінювати інтервали та умови зупинки без розробника, щоб команда клієнта керувала розсилкою самостійно.

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

Що отримує замовник після налаштування: конфігурації та регламенти

На виході — не «налаштована розсилка», а комплект, який ваша команда може супроводжувати без нас. Кожен артефакт закриває свою ділянку: листи, логіку спрацювання, сегменти, дії співробітників.

• Шаблони листів — три-чотири сценарії під різну поведінку: залишив кошик на етапі вибору, дійшов до оформлення і пішов, не відкрив перший лист. Тексти, теми, змінні підстановки (ім'я, склад кошика, посилання на повернення) — в окремих файлах, правляться без виклику розробника.
• Схема тригерів — карта: яка подія запускає лист, через скільки хвилин або годин, за яких умов зупиняється. Окремо описані винятки: оформлене замовлення, відписка, повторний кошик — щоб клієнт не отримував два листи підряд.
• Правила сегментації — за якими ознаками аудиторія ділиться на групи: нові та повторні покупці, категорія товару, активність у листах. Для кожного сегмента зазначено, який шаблон і яка затримка застосовуються.
• Інструкція для співробітників — що менеджер бачить у панелі, як вручну зняти клієнта з розсилки, куди дивитися при скарзі на зайвий лист. Без цього налаштування живе до першого питання відділу продажів.
• Документація із супроводу — де лежать шаблони, як поміняти текст і інтервал, як перевірити, що лист пішов, як відкотити зміну. З описом точок, де найчастіше ламається логіка.
• Регламент перевірки — періодичність звірки: чи доходять листи, чи немає зростання відписок, чи коректно підставляються дані. Із зазначенням відповідального та порогу, після якого потрібно втрутитися.
• Схема відкату — як повернути попередню поведінку, якщо нова логіка дає збій: які налаштування зберігаються перед запуском і в якому порядку відновлюються.

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

Кейс: як відновили надсилання листів і повернули замовлення

Проєкт — інтернет-магазин на 1С-Битрикс з кількома тисячами позицій і потоком замовлень на день. Клієнт скаржився на «тишу»: покупці додавали товари, йшли, але листів із нагадуванням не отримували. Фактично покинутий кошик накопичувався, а наздогнати покупця було нічим.

Що знайшли

Розбір показав, що шаблон листа й поштовий обробник були налаштовані коректно, а ось подія, яка мала запускати надсилання, не спрацьовувала.

В обробнику кошика стояла умова, яка відсікала частину сценаріїв: лист формувався лише за певного статусу замовлення, а частина покинутих кошиків у цей статус не потрапляла.

Плюс до цього частина адрес відсікалася через помилку в перевірці формату — валідні скриньки не проходили фільтр.

Що зробили

Переписали логіку обробника подій: прибрали жорстку прив'язку до статусу й зав'язали надсилання на сам факт незавершеного кошика.

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

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

Метрики до і після

Через місяць після запуску частка повернутих замовлень вийшла на 11% від усіх покинутих кошиків — це замовлення, які раніше просто губилися. Окремо винесли метрику в панель: якщо частка надісланих листів падає нижче 95%, надходить повідомлення відповідальному. Такий контроль ловить помилку в подіях того ж дня, а не через місяць за падінням виторгу.

Чим відрізняється повідомлення про покинутий кошик від транзакційного листа

Транзакційний лист — це підтвердження вже виконаної дії: замовлення оформлено, оплата пройшла, реєстрація завершена, статус замовлення змінився.

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

Повідомлення про покинутий кошик — тригерне, а не транзакційне. Воно прив'язане не до завершеної дії, а до її відсутності: кошик наповнений, але замовлення не оформлено.

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

Без цих перевірок лист піде тому, хто оформив замовлення в сусідній вкладці, і перетвориться на подразник.

Різниця проявляється й у змісті. Транзакційний лист — суха виписка: номер, склад, статус, посилання на деталі. Тригерний про кошик — повернення до незавершеного вибору: нагадування про товари, посилання на кошик зі збереженим складом, м'який привід повернутися. Тут важлива персоналізація за даними каталогу й складу, інакше лист втрачає сенс.

Для налаштування це означає різну інфраструктуру. Транзакційні надсилання йдуть через один шаблон і один обробник події, їх небагато і вони передбачувані.

Тригерні потребують планувальника, який періодично перевіряє незавершені кошики, зберігає історію надсилань і вміє зупиняти ланцюжок при оформленні замовлення. Змішувати ці потоки в одному шаблоні не можна: різні умови запуску, різна частота, різні вимоги до відписки.

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

Якщо цього не зробити, частина листів піде не тим адресатам, а повторні нагадування почнуть приходити після покупки.

Часті технічні питання щодо налаштування сповіщень

Лист про покинутий кошик — це транзакційне повідомлення, але поштові провайдери оцінюють його за тими самими правилами, що й розсилку: репутація домену та IP, наявність SPF, DKIM і DMARC, частка скарг і переходів.

Якщо домен молодий або з нього паралельно йде масова розсилка, листи починають потрапляти в «Промоакції» та «Спам» — кошик формально покинуто, а клієнт сповіщення не бачить.

Лікується це не текстом листа, а налаштуванням автентифікації відправника та винесенням транзакційного потоку на окремий піддомен, щоб репутація не змішувалася з маркетинговою.

Дублі — друга за частотою причина роздратування. Вони з'являються, коли подію додавання до кошика обробляють і агенти, і обробник події, або коли повторний запуск агента не перевіряє, чи надіслано лист за цим кошиком раніше.

Рішення — ідемпотентність: унікальний ключ за користувачем і кошиком, прапорець відправлення в базі та блокування повторного запуску.

Як гарантовано уникнути дублів листів?

Ідемпотентність на рівні даних: пишемо факт відправлення в окрему таблицю з унікальним індексом за парою «користувач + кошик». Повторний запуск агента бачить запис і не надсилає лист вдруге.

Додатково виключаємо перетин агентів і обробників подій, щоб одна дія не тригерила відправлення двічі.

Що робити, якщо відправлення падає або поштовий сервер недоступний?

Ставимо відправлення в чергу з повторними спробами та зростаючою паузою. Якщо зовнішній сервер не відповідає, лист не губиться, а чекає в черзі.

Усі спроби та помилки пишемо в лог — за ним видно, на якому кроці й чому зірвалося відправлення, і можна розібрати інцидент без здогадок.

Як зрозуміти, що сповіщення реально доходять?

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

Обговоримо ваше завдання щодо сповіщень про покинутий кошик

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

• Платформа та редакція. Бітрікс або Бітрікс24, редакція, модуль інтернет-магазину, підключені канали сповіщень. Від цього залежить, які події вже віддають дані про кошик, а які доведеться збирати.
• Схема кошика. Де зберігається: прив'язана до користувача, до сесії чи до обох; як довго живе покинутий; чи є об'єднання кошиків при вході. Це визначає, за якою ознакою вважати кошик покинутим.
• Сценарії повернення. Що вже надсилається — листи, повідомлення в месенджери, дзвінок менеджера. Які кроки і через скільки після покидання. Так ми не дублюємо те, що працює.
• Дані про клієнта. Згоди на розсилку, поля профілю, історія замовлень. Потрібні, щоб сповіщення було доречним і не надходило тим, хто вже купив.
• Інфраструктура. Як влаштоване надсилання листів, хто провайдер, чи є обмеження за обсягом і репутацією домену. Черга та повторні спроби — частина роботи.
• Доступи. Тестовий контур, копія бази, доступ до налаштувань і логів. Без стенда перевіряти сценарії наосліп не можна.
• Очікування щодо термінів. До якої дати потрібен запуск і чи є прив'язка до акції чи сезону.

Опишіть завдання у вільній формі — що не влаштовує в поточних сповіщеннях і який результат потрібен. Ми повернемося з оцінкою та планом: етапи, що робимо на кожному, які дані потрібні від вас і в які терміни вкладаємося. Формат роботи — віддалено, з фіксованими точками синхронізації за прогресом.