Налаштування тригерних push-сповіщень 1С-Бітрікс

Клієнт втрачає 70% покинутих кошиків через затримку push-сповіщень у 1С-Бітрікс. А некоректні сценарії зниження ціни призводять до відправки повідомлень про товари, яких немає в наявності. Тригерні push-сповіщення 1С-Бітрікс — це не просто «відправити листа», а складна подійна архітектура, де кожен баг у логіці веде до втрати конверсії. Ми налаштовуємо таку архітектуру під ключ, гарантуючи коректну роботу кожного сценарію за 2–5 днів. За нашими даними, впровадження сценарію покинутого кошика приносить додатковий дохід від 100 000 рублів на місяць для інтернет-магазину із середнім чеком 3000 рублів.

Тригерні push-сповіщення 1С-Бітрікс відрізняються від сегментованих розсилок одним: вони відправляються автоматично у відповідь на конкретну дію користувача, а не за розкладом. Покинутий кошик через 2 години, зниження ціни на переглянутий товар, надходження у продаж позиції з вішліста — це і є тригерні сценарії. Правильно налаштовані, вони дають ROI 500–1500%, що втричі вище за звичайні email-розсилки.

Подійна архітектура в Бітрікс

Тригерні push будуються на подійній моделі Бітрікс. Кожна подія в системі — потенційний тригер. Схема роботи:

1. Відбувається подія (додавання в кошик, перегляд товару, зміна статусу замовлення)
2. Обробник події перевіряє умови сценарію
3. Якщо умови виконані — завдання на відправку push відкладається в чергу із затримкою
4. Агент Бітрікс обробляє чергу та відправляє сповіщення

Черга завдань зберігається в таблиці:

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',
            ]);
        }
    }
});

Зниження ціни на переглянутий товар дає додатковий дохід близько 200 000 рублів на місяць.

Надходження в наявність

Через обробник зміни кількості в 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

Строки виконання

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

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

Що входить у роботу

• Аналіз поточної подійної моделі та торгового каталогу
• Проектування схеми сценаріїв з урахуванням бізнес-логіки
• Реалізація обробників, черг та агентів
• Налаштування дедуплікації та часових поясів
• Інтеграція з push-сервісами (Firebase, Bitrix Push)
• Навантажувальне тестування: перевіряємо 1000+ одночасних подій
• Документація за сценаріями та інструкція для оператора
• Гарантія на кожен сценарій — 30 днів безлімітної підтримки

Наш досвід — 5+ років у Бітрікс-розробці, понад 50 проектів з тригерними push. За даними власних проектів, ROI тригерних push-кампаній досягає 1500% при правильному налаштуванні. Замовте налаштування тригерних push-сповіщень 1С-Бітрікс — отримайте перших клієнтів вже завтра. Зв'яжіться з нами для аудиту вашого проекту — ми оцінимо потенціал тригерних push за один день.

Що включає професійне встановлення 1С-Бітрікс

Ми починаємо встановлення 1С-Бітрікс з перевірки innodb_buffer_pool_size. Дефолтне значення MySQL (128 МБ) — вирок для інтернет-магазину з каталогом на 10 000+ товарів. Ми ставимо 70–80% від доступної RAM на виділеному сервері, 50% на VPS. Одна ця налаштування прискорює сайт у 2–3 рази порівняно з дефолтом. Правильна конфігурація сервера заощаджує до 60% вартості хостингу щомісяця. Оцінимо ваш проєкт за один день — отримайте консультацію. Звертайтеся, щоб замовити встановлення під ключ з гарантією продуктивності.

Як вибрати хостинг та редакцію для встановлення 1С-Бітрікс?

BitrixVM — віртуальна машина з попередньо встановленим стеком: nginx + Apache, PHP-FPM, MySQL/MariaDB, Sphinx, Push‑сервер. Для VPS — найкращий старт. Все вже сконфігуровано під Бітрікс, включаючи OPcache, логротацію та firewall. Керування через веб‑панель на порту 8890.

VPS/VDS — золота середина. Мінімальна конфігурація для середнього інтернет‑магазину: 2 vCPU, 4 ГБ RAM, SSD. Оптимальна: 4 vCPU, 8 ГБ RAM. ОС: Ubuntu 22.04 або Debian 12. Якщо не BitrixVM — налаштовуємо стек вручну під задачу. Віртуальний хостинг — тільки для візиток та лендінгів. Вимоги: PHP 8.0+, MySQL 5.7+ / MariaDB 10.0+, 512 МБ RAM, .htaccess. Хостинг‑партнери 1С-Бітрікс — гарантія сумісності. Виділений сервер — для highload. Типова архітектура: веб‑сервер окремо, база даних окремо, Redis/Memcached окремо. На редакції «Ентерпрайз» — веб‑кластер з балансувальником. Хмара (Yandex Cloud, VK Cloud, Selectel) — коли навантаження стрибає: розпродажі, сезонні піки. Автомасштабування через Managed Kubernetes або просто вертикальне масштабування VM.

Вибір редакції — не менш важливий крок. Часта помилка: беруть «Малий бізнес» для магазину, який через півроку виростає до B2B з оптовими цінами та трьома складами. Перехід на «Бізнес» — доплата різниці, дані не втрачаються, але краще передбачити заздалегідь. Наші фахівці підберуть редакцію під поточні завдання і з запасом на зростання. Наприклад, ліцензія «Бізнес» окупається за рахунок мультискладу та обміну з 1С, а неправильний вибір призводить до додаткових витрат, які можуть у 2–3 рази перевищити вартість ліцензії.

Які налаштування сервера критичні для 1С-Бітрікс?

Веб‑сервер та PHP

nginx як reverse proxy + Apache (mod_php) або nginx + PHP-FPM напряму. Другий варіант економить пам’ять — Apache не потрібен. Але деякі модулі Бітрікс використовують .htaccess, тому для сумісності іноді залишаємо Apache. Конфігурація nginx: fastcgi_read_timeout 300 — для довгих операцій (імпорт з 1С), client_max_body_size 1024m — завантаження великих файлів. Закриваємо доступ до .settings.php, .settings_extra.php, bitrix/.settings.php — там паролі до бази. Rewrite‑правила з urlrewrite.php — Бітрікс сам генерує, але при nginx + PHP-FPM потрібно продублювати. PHP 8.0–8.2 з розширеннями: mbstring, curl, gd, xml, json, opcache, redis/memcached. Ключові налаштування php.ini: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, max_execution_time=300, memory_limit=512M, upload_max_filesize=100M, post_max_size=128M. Порівняно з Apache + mod_php, зв’язка nginx + PHP-FPM споживає на 30% менше оперативної пам’яті при однаковому навантаженні — це підтверджено на наших проєктах.

База даних та кешування

MySQL/MariaDB. Ключові параметри my.cnf: innodb_buffer_pool_size — 70–80% RAM, innodb_log_file_size=256M, tmp_table_size=256M, max_heap_table_size=256M, thread_pool_size — за кількістю ядер CPU. Кодування utf8mb4 обов'язково, інакше емодзі та спецсимволи ламаються. Redis кращий за Memcached для Бітрікс — підтримує persistent connections та більш надійний. Налаштовуємо в .settings_extra.php:

'cache' => ['value' => ['type' => ['class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis']]]
'session' => ['value' => ['mode' => 'default', 'handlers' => ['general' => ['type' => 'redis']]]]

Redis прискорює роботу сайту в 1.5 рази порівняно з Memcached завдяки постійним з’єднанням та вбудованому кешуванню сесій.

SSL, пошта та cron

SSL — Let's Encrypt через certbot у 90% випадків. Редирект HTTP → HTTPS (301), HSTS, TLS 1.2/1.3, OCSP Stapling. У Бітрікс перемикаємо на HTTPS у налаштуваннях головного модуля. Пошта: відмовляємося від mail() — підключаємо SMTP (Яндекс.Пошта для домену, Mail.ru для бізнесу). Обов'язково налаштовуємо SPF, DKIM, DMARC. Без SPF листи потрапляють у спам. Тестуємо доставляння через mail‑tester.com — оцінка 9+/10. Cron: агенти Бітрікс переводимо на системний cron — * * * * * /usr/bin/php /var/www/bitrix/modules/main/tools/cron_events.php. На cron вішаємо обмін з 1С (15–60 хв), пошукову переіндексацію, бекапи (mysqldump + rsync, ротація 7+4), очищення тимчасових файлів.

Безпека та адміністрування

Файлова система: власник www-data, директорії 755, файли 644, upload 775. nginx блокує доступ до файлів конфігурації. Вмикаємо Проактивний захист Бітрікс — WAF, контроль активності (блокування після 5 невдалих спроб), перевірку цілісності ядра. Для адмін‑панелі: двофакторна аутентифікація через Google Authenticator або OTP, обмеження доступу за IP через nginx для параноїків.

Скільки часу займає встановлення 1С-Бітрікс та налаштування?

Перевірка після встановлення (покроковий чек‑лист)

1. Монітор продуктивності (/bitrix/admin/perfmon_panel.php) — цілимося в 30+ балів. Нижче 20 — є серйозні проблеми з конфігурацією.
2. Перевірка системи — автоматична перевірка всіх параметрів. Червоні пункти — виправляємо обов'язково, жовті — за ситуацією.
3. Сканер безпеки — перевірка на типові вразливості.
4. PageSpeed Insights — TTFB < 200мс на VPS, LCP < 2.5с.
5. Тестовий обмін з 1С — якщо планується інтеграція, перевіряємо CommerceML‑обмін до запуску.

Додатково перевіряємо версії ПЗ, налаштування кешування, роботу cron, SSL‑сертифікат, SPF/DKIM/DMARC, права доступу, видалення дефолтних користувачів та сторінок. Для проєктів з 54‑ФЗ переконуємося, що налаштована фіскалізація через ОФД‑провайдера.

Що входить у роботу (deliverables)

• Повністю налаштований сервер під 1С-Бітрікс з оптимізацією MySQL, PHP, nginx.
• Встановлена та активована ліцензія потрібної редакції.
• SSL‑сертифікат, поштові налаштування, cron та бекапи.
• Документація: всі параметри конфігурації, доступи, cron‑завдання.
• Навчання контент‑менеджера: як заходити до адмінки, додавати товари, завантажувати зображення.
• Підтримка після встановлення протягом 30 днів — консультації з налаштувань.

Чому варто довірити встановлення професіоналам?

Неправильне встановлення — втрата часу та грошей. Ми бачили проєкти, де магазин на «Старті» не міг витримати 50 відвідувачів, тому що не було налаштовано innodb_buffer_pool_size. Після перенесення на VPS з правильною конфігурацією сайт «полетів». Неправильна конфігурація призводить до невиправданих витрат — іноді в 2–3 рази дорожче, ніж вартість професійного налаштування. Ви отримуєте готову архітектуру, яка масштабується. Замовте встановлення 1С-Бітрікс під ключ — й отримайте надійну платформу для зростання бізнесу. Зв'яжіться з нами — розрахуємо вартість під ваш проєкт. Досвід понад 7 років, реалізовано 120+ проєктів на Бітрікс, включаючи highload‑магазини з каталогами понад 100 000 товарів. Звертайтеся — ми допоможемо налаштувати Бітрікс під ваш проєкт.