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

Налаштування push-сповіщення про залишений перегляд 1С-Bitrix

Лист про залишений перегляд відкривають 15–20% одержувачів — ті, хто взагалі відкриває email. Push-сповіщення в браузері з'являється відразу, без необхідності відкривати пошту. Конверсія в перехід у push вищі при умові, що сповіщення приходить через 20–40 хвилин після перегляду, а не через добу. Налаштування цієї механіки в Bitrix вимагає інтеграції модулю push.sender з логікою залишених переглядів.

Архітектура доставки

Push-сповіщення проходить шлях: агент Bitrix → метод MessageSender::send() → чергу в b_agent → POST-запит до push-endpoint браузера (FCM для Chrome, Mozilla Autopush для Firefox). Підписки зберігаються в b_push_sender_subscription з полями FUSER_ID, USER_ID, ENDPOINT, AUTH, P256DH.

Критичний момент: b_push_sender_subscription містить записи й для анонімів (через FUSER_ID), й для авторизованих користувачів (через USER_ID). При роботі з залишеними переглядами потрібно шукати підписку по FUSER_ID, так як перегляд міг бути анонімним.

Зв'язок триггера перегляду з підпискою на push

Агент залишених переглядів (описаний в окремій услуге) знаходить пару (fuser_id, product_id). Наступний крок — знайти активну push-підписку:

$subscription = \Bitrix\PushSender\Model\SubscriptionTable::getList([
    'filter' => [
        'FUSER_ID' => $fuserID,
        '=STATUS' => 'ACTIVE',
    ],
    'order' => ['DATE_INSERT' => 'DESC'],
    'limit' => 1,
])->fetch();

if ($subscription) {
    // Підписка є — відправляємо push
} else {
    // Повертаємось на email через b_subscribe_subscriber
}

Поле STATUS у b_push_sender_subscription може бути ACTIVE, UNSUBSCRIBED або EXPIRED. Перед відправленням перевіряємо саме ACTIVE — інакше отримаємо 410 Gone від FCM та засоримо лог помилок.

Формування payload сповіщення

Web Push payload обмежений 4 КБ. Для залишеного перегляду достатньо: заголовок, текст, URL товару, URL картинки. Дані про товар беремо з інфоблоку:

$product = \CIBlockElement::GetByID($productId)->GetNextElement();
$fields = $product->GetFields();
$props  = $product->GetProperties();

$imageId  = $fields['PREVIEW_PICTURE'] ?: $fields['DETAIL_PICTURE'];
$imageUrl = \CFile::GetPath($imageId);

\Bitrix\PushSender\MessageSender::send(
    \Bitrix\PushSender\MessageSender::TYPE_PUSH,
    [
        'FUSER_ID' => [$fuserID],
        'TITLE'    => 'Ви дивилися: ' . $fields['NAME'],
        'MESSAGE'  => 'Товар ще в наявності. Повернутися до вибору?',
        'URL'      => $fields['DETAIL_PAGE_URL'],
        'IMAGE'    => $imageUrl,
        'TAG'      => 'abandoned_view_' . $productId,
    ]
);

Поле TAG — це Web Push notification tag. Якщо користувач переглянув 5 товарів і не купив жодного, без тега він отримає 5 окремих сповіщень. З одним тегом — кожне нове сповіщення замінює попереднє, що правильніше з точки зору UX.

Час відправлення та вікно релевантності

Push про залишений перегляд втрачає сенс через 3–4 години. Якщо користувач не відкривав браузер в цей період, сповіщення прийде пізніше — і буде неуместним. Рішення: встановлювати TTL (Time-To-Live) у запиті до FCM. У Bitrix це передається через додаткові опції в MessageSender::send(), але стандартний метод TTL не підтримує напрямо. Потрібно розширити клас \Bitrix\PushSender\Transport\WebPush та передати заголовок TTL: 3600 у POST-запиті до endpoint.

Альтернативно — перевіряти в агенті дату підписки: якщо b_push_sender_subscription.DATE_INSERT старіша за 30 днів і немає активності — підписка скоріш за все застаріла, пропускати.

Сценарій з мобільним додатком

Якщо у магазину є мобільний додаток на Bitrix Mobile Framework, push йде через APNs/FCM напрямки. Підписки в цьому разі зберігаються у b_push_sender_device (а не b_push_sender_subscription). Логіка виборки аналогічна, але поля відрізняються: DEVICE_ID, TOKEN, PLATFORM (ios/android).

Що ми налаштовуємо

• Пошук push-підписок по FUSER_ID в b_push_sender_subscription
• Формування payload з даними товару з інфоблоку
• Використання поля TAG для заміни дублюючих сповіщень
• Налаштування TTL через розширення класу WebPush транспорту
• Fallback на email при відсутності push-підписки
• Таблицю дедупліцирування, загальну з триггером залишеного перегляду