Клієнт втрачає 70% покинутих кошиків через затримку push-сповіщень у 1С-Бітрікс. А некоректні сценарії зниження ціни призводять до відправки повідомлень про товари, яких немає в наявності. Тригерні push-сповіщення 1С-Бітрікс — це не просто «відправити листа», а складна подійна архітектура, де кожен баг у логіці веде до втрати конверсії. Ми налаштовуємо таку архітектуру під ключ, гарантуючи коректну роботу кожного сценарію за 2–5 днів. За нашими даними, впровадження сценарію покинутого кошика приносить додатковий дохід від $900–1.3kів на місяць для інтернет-магазину із середнім чеком $27–39ів.
Тригерні push-сповіщення 1С-Бітрікс відрізняються від сегментованих розсилок одним: вони відправляються автоматично у відповідь на конкретну дію користувача, а не за розкладом. Покинутий кошик через 2 години, зниження ціни на переглянутий товар, надходження у продаж позиції з вішліста — це і є тригерні сценарії. Правильно налаштовані, вони дають ROI 500–1500%, що втричі вище за звичайні email-розсилки.
Подійна архітектура в Бітрікс
Тригерні push будуються на подійній моделі Бітрікс. Кожна подія в системі — потенційний тригер. Схема роботи:
- Відбувається подія (додавання в кошик, перегляд товару, зміна статусу замовлення)
- Обробник події перевіряє умови сценарію
- Якщо умови виконані — завдання на відправку push відкладається в чергу із затримкою
- Агент Бітрікс обробляє чергу та відправляє сповіщення
Черга завдань зберігається в таблиці:
Приклад таблиці черги
CREATE TABLE custom_push_queue ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, scenario VARCHAR(50) NOT NULL, payload JSON, send_at DATETIME NOT NULL, status ENUM('pending', 'sent', 'cancelled') DEFAULT 'pending', created_at DATETIME, INDEX idx_send_at (send_at, status), INDEX idx_user_scenario (user_id, scenario) ); Джерело: офіційна документація 1С-Бітрікс
Ключові сценарії
Покинутий кошик
Найцінніший сценарій. Логіка:
// Обробник OnSaleBasketItemSaved AddEventHandler('sale', 'OnSaleBasketItemSaved', function($basketItem) { $userId = (int)$basketItem->getField('USER_ID'); if (!$userId) return; // Тільки авторизовані // Скасовуємо попереднє завдання для цього користувача PushQueueTable::cancelByUserAndScenario($userId, 'abandoned_cart'); // Ставимо нове — через 2 години PushQueueTable::add([ 'USER_ID' => $userId, 'SCENARIO' => 'abandoned_cart', 'PAYLOAD' => json_encode(['cart_url' => '/cart/']), 'SEND_AT' => new \Bitrix\Main\Type\DateTime(date('Y-m-d H:i:s', time() + 7200)), 'STATUS' => 'pending', 'CREATED_AT' => new \Bitrix\Main\Type\DateTime(), ]); }); Після оформлення замовлення завдання скасовується. Якщо користувач не оформив — через 2 години приходить push.
Зниження ціни
Вимагає зберігання історії переглядів та моніторингу зміни цін:
// При зміні ціни торгової пропозиції (OnBeforeIBlockElementUpdate) AddEventHandler('iblock', 'OnAfterIBlockElementUpdate', function(&$fields) { $elementId = (int)$fields['ID']; $newPrice = getElementPrice($elementId); // Знаходимо користувачів, які переглядали цей товар $viewers = ProductViewHistoryTable::getUsersByProduct($elementId, 30); // за 30 днів foreach ($viewers as $viewer) { $oldPrice = ProductPriceHistoryTable::getLastPrice($elementId, $viewer['USER_ID']); if ($newPrice < $oldPrice * 0.9) { // Знижка 10%+ PushQueueTable::add([ 'USER_ID' => $viewer['USER_ID'], 'SCENARIO' => 'price_drop', 'PAYLOAD' => json_encode(['product_id' => $elementId, 'new_price' => $newPrice]), 'SEND_AT' => new \Bitrix\Main\Type\DateTime(), // Негайно 'STATUS' => 'pending', ]); } } }); Зниження ціни на переглянутий товар дає додатковий дохід близько $1.8k–2.6kів на місяць.
Надходження в наявність
Через обробник зміни кількості в b_catalog_store_product або при синхронізації з 1С.
Статус замовлення
Обробник події OnSaleStatusOrderChange. Push відправляється негайно при кожній зміні статусу.
Чому покинутий кошик — найприбутковіший сценарій?
Тому що користувач уже виявив намір купити. Push з нагадуванням через 2 години повертає до 15% забутих кошиків. Це вище, ніж у email-розсилок (5–10%), і значно швидше. Ми впроваджуємо цей сценарій в першу чергу, оскільки окупність настає в перший тиждень. При ROI 500–1500% витрати на розробку окупаються за 1-2 місяці.
Як налаштувати тригерні push і не прогоріти на трафіку?
Головна помилка — ігнорувати дедуплікацію та часові пояси. Без дедуплікації користувач може отримати три push за годину. Правила, які ми закладаємо:
- Один сценарій — не частіше разу на 24 години на користувача
- Не відправляти push з 23:00 до 9:00 (за таймзоною користувача)
- Якщо користувач вже купив після події — скасувати завдання
Таймзона користувача береться з його профілю або геолокації при реєстрації.
Агент обробки черги
Агент Бітрікс запускається щохвилини:
Приклад реалізації агента
function ProcessPushQueue(): string { $now = new \Bitrix\Main\Type\DateTime(); $records = PushQueueTable::getList([ 'filter' => ['=STATUS' => 'pending', '<=SEND_AT' => $now], 'limit' => 100, ]); while ($record = $records->fetch()) { $tokens = PushTokenTable::getByUserId($record['USER_ID']); if (!empty($tokens)) { $message = PushScenario::buildMessage($record['SCENARIO'], json_decode($record['PAYLOAD'], true)); PushSender::send($tokens, $message); } PushQueueTable::update($record['ID'], ['STATUS' => 'sent']); } return __FUNCTION__ . '();'; } Порівняння сценаріїв за складністю та ROI
| Сценарій | Складність | Середній ROI | Час впровадження |
|---|---|---|---|
| Покинутий кошик | Середня | 500–1500% | 2–3 дні |
| Зниження ціни | Висока | 300–800% | +2 дні |
| Надходження в наявність | Середня | 200–600% | +2 дні |
| Статус замовлення | Низька | 100–300% | 1 день |
Строки виконання
| Обсяг робіт | Строк |
|---|---|
| Покинутий кошик + зміна статусу | 2–3 дні |
| Зниження ціни + надходження в наявність | +2 дні |
| Дедуплікація + таймзони + аналітика | +1–2 дні |
Кожен робочий тригерний сценарій — це автоматизований продавець, який не бере зарплату.
Перед початком розробки ми аналізуємо поточну подійну модель, виявляємо неефективні сценарії та проектуємо нові. Для кожного тригера визначаємо точні умови та затримки, а також налаштовуємо дедуплікацію та таймзони.
Що входить у роботу
- Аналіз поточної подійної моделі та торгового каталогу
- Проектування схеми сценаріїв з урахуванням бізнес-логіки
- Реалізація обробників, черг та агентів
- Налаштування дедуплікації та часових поясів
- Інтеграція з push-сервісами (Firebase, Bitrix Push)
- Навантажувальне тестування: перевіряємо 1000+ одночасних подій
- Документація за сценаріями та інструкція для оператора
- Гарантія на кожен сценарій — 30 днів безлімітної підтримки
Наш досвід — 5+ років у Бітрікс-розробці, понад 50 проектів з тригерними push. За даними власних проектів, ROI тригерних push-кампаній досягає 1500% при правильному налаштуванні. Замовте налаштування тригерних push-сповіщень 1С-Бітрікс — отримайте перших клієнтів вже завтра. Зв'яжіться з нами для аудиту вашого проекту — ми оцінимо потенціал тригерних push за один день.