A client loses 70% of abandoned carts due to push notification delays in 1C-Bitrix. Incorrect price drop scenarios lead to sending messages about out-of-stock items. Trigger push notifications in 1C-Bitrix are not just 'sending an email' — they are a complex event architecture where every bug in the logic leads to conversion loss. We configure such architecture turnkey, guaranteeing correct operation of each scenario in 2–5 days. According to our data, implementing an abandoned cart scenario brings additional revenue from 100,000 rubles per month for an online store with an average check of 3,000 rubles.
Trigger push notifications in 1C-Bitrix differ from segmented mailings in one way: they are sent automatically in response to a specific user action, not on a schedule. Abandoned cart after 2 hours, price drop on a viewed product, back in stock of a wishlist item — these are trigger scenarios. Properly configured, they yield an ROI of 500–1500%, three times higher than regular email campaigns.
Event Architecture in Bitrix
Trigger push notifications are built on the event model of Bitrix. Each event in the system is a potential trigger. The workflow:
- An event occurs (adding to cart, viewing a product, order status change)
- The event handler checks the scenario conditions
- If conditions are met, the push task is postponed in a queue with a delay
- A Bitrix agent processes the queue and sends notifications
The task queue is stored in a table:
Example queue table
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)
);
Source: official 1C-Bitrix documentation
Key Scenarios
Abandoned Cart
The most valuable scenario. Logic:
// Обработчик 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(),
]);
});
After checkout, the task is cancelled. If the user does not complete checkout, the push arrives after 2 hours.
Price Drop
Requires storing view history and monitoring price changes:
// При изменении цены торгового предложения (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',
]);
}
}
});
Price drop on a viewed product generates additional revenue of around 200,000 rubles per month.
Back in Stock
Via handler for quantity change in b_catalog_store_product or during 1C sync.
Order Status
Handler for OnSaleStatusOrderChange. Push is sent immediately on each status change.
Why Is Abandoned Cart the Most Profitable Scenario?
Because the user has already shown intent to buy. A reminder push after 2 hours returns up to 15% of forgotten carts. This is higher than email campaigns (5–10%) and significantly faster. We implement this scenario first, as it pays off within the first week. With an ROI of 500–1500%, development costs are recouped in 1–2 months.
How to Configure Trigger Pushes Without Burning Traffic?
The main mistake is ignoring deduplication and time zones. Without deduplication, a user can receive three pushes in an hour. The rules we implement:
- One scenario no more than once every 24 hours per user
- Do not send pushes from 23:00 to 9:00 (user timezone)
- If the user has already purchased after the event — cancel the task
The user's timezone is taken from their profile or geolocation during registration.
Queue Processing Agent
The Bitrix agent runs every minute:
Example agent implementation
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__ . '();';
}
Scenario Comparison by Complexity and ROI
| Scenario | Complexity | Average ROI | Implementation Time |
|---|---|---|---|
| Abandoned Cart | Medium | 500–1500% | 2–3 days |
| Price Drop | High | 300–800% | +2 days |
| Back in Stock | Medium | 200–600% | +2 days |
| Order Status | Low | 100–300% | 1 day |
Delivery Timeline
| Scope | Timeline |
|---|---|
| Abandoned Cart + Order Status | 2–3 days |
| Price Drop + Back in Stock | +2 days |
| Deduplication + Time Zones + Analytics | +1–2 days |
Every working trigger scenario is an automated salesperson that doesn't take a salary.
Before starting development, we analyze the current event model, identify inefficient scenarios, and design new ones. For each trigger, we define exact conditions and delays, and configure deduplication and time zones.
What's Included
- Analysis of current event model and product catalog
- Designing scenario scheme considering business logic
- Implementing handlers, queues, and agents
- Configuring deduplication and time zones
- Integration with push services (Firebase, Bitrix Push)
- Load testing: we check 1000+ simultaneous events
- Scenario documentation and operator instructions
- Guarantee on each scenario — 30 days of unlimited support
Our experience includes over 5 years in Bitrix development, with more than 50 projects involving trigger pushes. According to our own project data, ROI of trigger push campaigns reaches 1500% with proper setup. Order setup of trigger push notifications in 1C-Bitrix — get your first clients tomorrow. Contact us for an audit of your project — we will assess the potential of trigger pushes in one day.