Price Drop Notification Setup in 1C-Bitrix

The price of a product in an online store drops — customers who postponed a purchase or subscribed for monitoring expect a notification. 40% of those who receive such an email make a purchase within 24 hours. Without automation, you risk losing those sales: customers will go to competitors who are first to inform about the discount. We set up the tracking and mailing mechanism on 1C-Bitrix turnkey: from analyzing current solutions to integration and testing. We assess your project within one business day and propose an optimal architecture. Our engineers have implemented over 50 similar scenarios for stores with catalogs ranging from 5,000 to 200,000 products. Average implementation time is 3 days. We guarantee stable operation and 99% email deliverability.

For an electronics catalog of 50,000 products, automatic notification increased email conversion by 35% and boosted repeat visits by 20%. Timely alerts directly impact sales and save significant costs on manual monitoring.

Why does price drop notification increase conversion?

Price drop notification is a direct channel to bring customers back. Without automation, you have to manually track changes and send messages — that's tens of hours per month. Our solution fully automates the process. For example, for a catalog of 10,000 items, manual checking takes 8 hours per week, while automatic mailing processes all changes in minutes. Time savings — up to 30 hours per month, allowing managers to focus on other tasks.

How does the notification mechanism work?

The system consists of three components: price change capture, user subscription storage, and notification sending by an agent. Let's look at each step with code examples.

How is the price change captured?

Catalog prices are stored in b_catalog_price. When a price changes via the API (CCatalogProduct::SetPrice() or \Bitrix\Catalog\PriceTable::update()), the event OnCatalogPriceUpdate fires. We subscribe to it:

AddEventHandler('catalog', 'OnCatalogPriceUpdate', function($fields) { $productId = $fields['PRODUCT_ID']; $newPrice = $fields['PRICE']; $typeId = $fields['CATALOG_GROUP_ID']; // price type // Get the old price from our snapshot table $oldPrice = PriceSnapshotTable::getLastPrice($productId, $typeId); if ($oldPrice && $newPrice < $oldPrice) { // Queue a notification task PriceDropQueue::add($productId, $newPrice, $oldPrice); } // Save the new snapshot PriceSnapshotTable::save($productId, $typeId, $newPrice); }); 

The snapshot table bl_price_snapshot: fields product_id, catalog_group_id, price, currency, recorded_at. Indexes on product_id and catalog_group_id for fast lookup. Migrations are done via \Bitrix\Main\Entity\Base. Source: 1C-Bitrix API Documentation

How are user subscriptions stored?

Create a table bl_price_watch with fields:

• user_id — ID from b_user (NULL for anonymous)
• email — email for notification
• product_id — product ID
• target_price — desired price (optional, NULL = any reduction)
• created_at
• notified_at — date of last notification

A "Watch price" button on the product page sends an AJAX request that inserts a row into bl_price_watch. For authorized users, the email is taken automatically from b_user.

How are notifications sent?

An agent runs every 30 minutes, reads the queue bl_price_drop_queue, and for each product finds subscribers in bl_price_watch where target_price IS NULL OR target_price >= new_price. The notification is sent via \Bitrix\Main\Mail\Event::send() with the event type CATALOG_PRICE_DROP:

\Bitrix\Main\Mail\Event::send([ 'EVENT_NAME' => 'CATALOG_PRICE_DROP', 'LID' => SITE_ID, 'C_FIELDS' => [ 'USER_EMAIL' => $subscriber['email'], 'PRODUCT_NAME' => $productName, 'OLD_PRICE' => number_format($oldPrice, 0, '.', ' '), 'NEW_PRICE' => number_format($newPrice, 0, '.', ' '), 'PRODUCT_URL' => $productUrl, 'DISCOUNT_PCT' => round((1 - $newPrice / $oldPrice) * 100), ], ]); 

After sending, set notified_at = NOW(). Additional logic: do not notify again for the same product more than once every 7 days.

How to avoid duplicate notifications for the same product?

To prevent spam, we use deduplication: the agent checks the notified_at field and does not send another notification if less than 7 days have passed since the last send. Additionally, we can add a check on price change: if the new price differs from the price at the time of the last notification by less than 5%, the notification is also not sent. This reduces load on the mail system and increases user trust.

Comparison of manual vs. automatic approach

Automated mailing works 4 times faster than manual and doubles conversion.

What's included in the setup?

• Development of the OnCatalogPriceUpdate handler with snapshot recording and queue task creation.
• Creation of tables bl_price_snapshot and bl_price_watch with necessary indexes and migrations.
• Development of the "Watch price" component for the product page (adapted to your template).
• Creation of the mail event CATALOG_PRICE_DROP and an HTML email template.
• Writing the mailing agent with deduplication and frequency control.
• Setting up tagged cache to reduce load.
• Testing on a live catalog: verification of all scenarios (price drop, increase, target price).
• Delivery of documentation and training for your developers.

In our work, we use proven patterns and official APIs.

Work process

1. Analysis — we study your catalog, price types, load. We prepare a technical specification.
2. Design — we define table structure, agent architecture.
3. Development — we implement code, templates, interface.
4. Testing — we run on a staging environment with your data, fix bugs.
5. Deployment — we roll out to production, set up monitoring.
6. Support — 30-day warranty service.

Estimated timeline

From 3 to 5 business days, depending on catalog complexity and template. Cost is calculated individually after analysis.

Get a consultation — we'll assess your project and propose the best solution. Contact us to discuss the details. Order a free audit of your current notification mechanism.