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

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

Письмо о брошенном просмотре открывают 15–20% получателей — те, кто вообще открывает email. Push-уведомление в браузере появляется сразу, без необходимости открывать почту. Конверсия в переход у push выше при условии, что уведомление приходит через 20–40 минут после просмотра, а не через сутки. Настройка этой механики в Битрикс требует интеграции модуля push.sender с логикой брошенных просмотров.

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

Push-уведомление проходит путь: агент Битрикс → метод 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. В Битрикс это передаётся через дополнительные опции в MessageSender::send(), но стандартный метод TTL не поддерживает напрямую. Нужно расширить класс \Bitrix\PushSender\Transport\WebPush и передать заголовок TTL: 3600 в POST-запрос к endpoint.

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

Сценарий с мобильным приложением

Если у магазина есть мобильное приложение на Битрикс 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-подписки
• Таблицу дедупликации, общую с триггером брошенного просмотра