Implementing Abandoned View Push Alerts in 1C-Bitrix

In our practice, push notifications about abandoned views show conversion rates 2–3 times higher than email campaigns when configured properly. We set up push notifications to arrive 20–40 minutes after a view — within this window, the visitor still remembers the product. Email open rates for abandoned views hover at 15–20%, while browser push appears instantly without checking inbox. Push click-through rates are higher, provided the notification arrives 20–40 minutes after the view, not a day later. Configuring this mechanic in Bitrix requires integrating the push.sender module with abandoned view logic. Our team has 7+ years of experience in 1C-Bitrix development and has implemented dozens of such integrations. Typical project cost ranges from $500 to $1500, with average monthly savings of $2000 compared to email marketing.

Key Challenges and Solutions

We address three main issues:

• Anonymous users without email: Push subscriptions are tied to FUSER_ID, not email. We search by FUSER_ID — otherwise, anonymous users miss notifications.
• Stale subscriptions: If a subscription is inactive (UNSUBSCRIBED or EXPIRED), sending causes FCM errors (410 Gone). Before sending, we verify STATUS = ACTIVE.
• Duplicate notifications: Without a TAG, each viewed product triggers a separate notification. We use TAG to replace old notifications with a new one.

Technical Implementation

Delivery Architecture

Push notifications travel: Bitrix agent → MessageSender::send() method → queue in b_agent → POST request to browser push endpoint (FCM for Chrome, Mozilla Autopush for Firefox). Subscriptions are stored in b_push_sender_subscription with fields: FUSER_ID, USER_ID, ENDPOINT, AUTH, P256DH. Critical point: b_push_sender_subscription contains records for both anonymous users (via FUSER_ID) and authorized users (via USER_ID). When dealing with abandoned views, we need to search by FUSER_ID, because the view might be anonymous.

Linking View Trigger to Push Subscription

The abandoned view agent finds pairs (fuser_id, product_id). The next step is to find an active push subscription:

$subscription = \Bitrix\PushSender\Model\SubscriptionTable::getList([ 'filter' => [ 'FUSER_ID' => $fuserID, '=STATUS' => 'ACTIVE', ], 'order' => ['DATE_INSERT' => 'DESC'], 'limit' => 1, ])->fetch(); if ($subscription) { // Subscription exists — send push } else { // Fallback to email via b_subscribe_subscriber } 

Field STATUS in b_push_sender_subscription can be ACTIVE, UNSUBSCRIBED, or EXPIRED. Before sending, we check for ACTIVE — otherwise, we get 410 Gone from FCM and clutter error logs.

Formulating Notification Payload

Web Push payload is limited to 4 KB. For an abandoned view, we include: title, text, product URL, image URL. Product data comes from the information block:

$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' => 'You viewed: ' . $fields['NAME'], 'MESSAGE' => 'Still in stock. Return to choose?', 'URL' => $fields['DETAIL_PAGE_URL'], 'IMAGE' => $imageUrl, 'TAG' => 'abandoned_view_' . $productId, ] ); 

The TAG field is a Web Push notification tag. If a user views 5 products without buying, without a tag they get 5 separate notifications. With one tag, each new notification replaces the previous one — better UX.

Sending Time and TTL

A push about an abandoned view loses meaning after 3–4 hours. Solution: set TTL (Time-To-Live) in the request to FCM. In Bitrix, we extend the \Bitrix\PushSender\Transport\WebPush class and pass the TTL: 3600 header in the POST request to the endpoint. Alternatively, check the subscription's date in the agent: if b_push_sender_subscription.DATE_INSERT is older than 30 days with no activity, the subscription is likely stale; skip it.

Mobile App Scenario

If the store has a mobile app on Bitrix Mobile Framework, push goes directly via APNs/FCM. Subscriptions in this case are stored in b_push_sender_device (not b_push_sender_subscription). The selection logic is similar, but fields differ: DEVICE_ID, TOKEN, PLATFORM (ios/android).

Comparison of Methods

Browser push beats email by 2x in open rate for the same content. According to 1C-Bitrix documentation, the push.sender module is optimized for highload.

Service Details

What's Included

• Finding push subscriptions by FUSER_ID in b_push_sender_subscription
• Formulating payload with product data from infoblock
• Using the TAG field to replace duplicate notifications
• Configuring TTL via extending the WebPush transport class
• Fallback to email when no push subscription exists
• Deduplication table with 5 fields shared with the abandoned view trigger
• Documentation on access rights and logic
• 1-hour training for the client's developer
• 30-day support after delivery

Process

1. Analysis – examine current push.sender configuration, subscription structure, and infoblocks.
2. Design – agree on agent scheme, TTL, and fallback mechanism.
3. Implementation – write the agent, extend WebPush transport, configure caching.
4. Testing – test sending on Chrome, Firefox, Edge; simulate anonymous view.
5. Deployment – roll out to production server, monitor first 48 hours.

Setup typically takes 3 to 5 working days. Average cost savings on push notifications compared to email is 25%. Pricing is calculated individually based on integration complexity and catalog size. Request a setup — get a free consultation.

Why Push Outperforms Email

Email can land in spam, is not opened immediately, while push delivers instantly and appears even on a locked mobile screen. For e-commerce, push notifications increase return visits by 15–25% according to our data. We configure turnkey with a work guarantee. Contact us to discuss your project.