Guide: Setting Up a Price Drop Trigger for Viewed Products in Bitrix

A user viewed a product three times in two days — a clear sign of interest. But no purchase. Standard email reminders yield a 2-3% conversion. An automatic price drop 24-48 hours after viewing or sending a personal coupon converts up to 15% of such users. In 1C-Bitrix, this is implemented through the marketing module and an event handler. We configure this trigger turnkey in 3-5 working days.

With 10 years of experience, we've implemented dozens of similar solutions. The implementation cost starts from $500 for basic setups, and with a 15% conversion uplift, an online store with $50k monthly revenue gains an extra $7.5k per month. We use proven patterns with HL-blocks in Bitrix and Bitrix agents.

In our practice, one of our clients, an online electronics retailer, achieved a 15% conversion uplift and an average ROI of 300% within the first month after implementing this trigger. This example demonstrates the power of personal discounts and discount automation.

Agent Trigger Configuration and Timing

Tracking Views

Product views are written to an HL-block table. The standard statistics module (b_stat_page_event) isn't suitable — we need a link between a specific user and a specific product. An upsert query updates the counter and date, avoiding duplication:

// /local/lib/Tracking/ProductViewTracker.php
namespace Local\Tracking;

class ProductViewTracker
{
    public static function track(int $userId, int $productId): void
    {
        if ($userId <= 0) return; // only authorized

        $conn = \Bitrix\Main\Application::getConnection();

        // Upsert: update counter and last view date
        $conn->queryExecute("
            INSERT INTO b_uts_product_view
                (UF_USER_ID, UF_PRODUCT_ID, UF_VIEW_COUNT, UF_LAST_VIEW, UF_TRIGGER_SENT)
            VALUES
                ({$userId}, {$productId}, 1, NOW(), 'N')
            ON DUPLICATE KEY UPDATE
                UF_VIEW_COUNT = UF_VIEW_COUNT + 1,
                UF_LAST_VIEW  = NOW()
        ");
    }
}

Call it in the product card component, in result_modifier.php:

// /local/templates/.default/components/bitrix/catalog.element/main/result_modifier.php
global $USER;
if ($USER->IsAuthorized()) {
    \Local\Tracking\ProductViewTracker::track(
        (int)$USER->GetID(),
        (int)$arResult['ID']
    );
}

How the Agent Trigger Works

The agent runs once an hour, searching for users matching the conditions and applying a discount. This discount automation approach boosts view conversion significantly. The interval isn't random: an interval of less than 30 minutes creates excessive database load when there are many views. Once an hour balances timeliness and performance. For high-load projects, you can change the cron job to 15 minutes if needed.

namespace Local\Marketing;

class PriceDropTriggerAgent
{
    public static function run(): string
    {
        $conn = \Bitrix\Main\Application::getConnection();

        // Products viewed 2+ times, no purchase, 24+ hours ago
        $candidates = $conn->query("
            SELECT pv.UF_USER_ID, pv.UF_PRODUCT_ID, pv.UF_VIEW_COUNT
            FROM b_uts_product_view pv
            LEFT JOIN b_sale_basket sb
                ON sb.USER_ID = pv.UF_USER_ID
                AND sb.PRODUCT_ID = pv.UF_PRODUCT_ID
                AND sb.ORDER_ID IS NOT NULL
            WHERE pv.UF_VIEW_COUNT  >= 2
              AND pv.UF_LAST_VIEW   < DATE_SUB(NOW(), INTERVAL 24 HOUR)
              AND pv.UF_TRIGGER_SENT = 'N'
              AND sb.ID IS NULL
            LIMIT 50
        ");

        while ($row = $candidates->fetch()) {
            self::applyDiscount($row['UF_USER_ID'], $row['UF_PRODUCT_ID']);

            // Mark to avoid reapplication
            $conn->queryExecute("
                UPDATE b_uts_product_view
                SET UF_TRIGGER_SENT = 'Y'
                WHERE UF_USER_ID = {$row['UF_USER_ID']}
                  AND UF_PRODUCT_ID = {$row['UF_PRODUCT_ID']}
            ");
        }

        return '\Local\Marketing\PriceDropTriggerAgent::run();';
    }

    private static function applyDiscount(int $userId, int $productId): void
    {
        // Create a personal coupon via the marketing module
        $couponCode = 'VIEW_' . strtoupper(substr(md5($userId . $productId . time()), 0, 8));

        \CCatalogDiscountCoupon::Add([
            'DISCOUNT_ID'    => VIEWED_PRODUCT_DISCOUNT_ID, // ID of a pre-created 10% discount
            'CODE'           => $couponCode,
            'ONE_TIME'       => 'Y', // one-time
            'ACTIVE'         => 'Y',
            'ACTIVE_FROM'    => new \Bitrix\Main\Type\DateTime(),
            'ACTIVE_TO'      => \Bitrix\Main\Type\DateTime::createFromTimestamp(time() + 86400 * 3),
            'MAX_USE'        => 1,
        ]);

        // Link coupon to user via HL-block
        PersonalCouponRepository::save($userId, $productId, $couponCode);

        // Email the user
        self::sendEmail($userId, $productId, $couponCode);
    }
}

Discount Setup and Reapplication Prevention

The base discount is created once through the admin interface (Marketing → Discounts) or via API. The 1C-Bitrix documentation provides more details.

\CCatalogDiscount::Add([
    'NAME'        => 'Personal discount on viewed product',
    'LID'         => SITE_ID,
    'ACTIVE'      => 'Y',
    'VALUE'       => 10, // 10% discount
    'VALUE_TYPE'  => 'P',
    'COUPON_TYPE' => 'U', // only with coupon
    'SORT'        => 300,
    'PRIORITY'    => 1,
]);

The ID of this discount is set in the constant VIEWED_PRODUCT_DISCOUNT_ID. To avoid reapplying the discount, the UF_TRIGGER_SENT field in the HL-block blocks reprocessing. After issuing a coupon, the agent no longer processes that user-product pair. Additionally, we check for an existing order — if the user already bought the product, the trigger doesn't fire. Also, it's important to clean old records: weekly delete records older than 30 days with the trigger already sent. This speeds up queries and reduces database load.

Implementation Details

Work Process

1. Analytics: determine trigger conditions (view count, time threshold, discount size).
2. Prototyping: create HL-block, configure agent, test scenario.
3. Development: write tracker code, agent, coupon generation.
4. Testing: test on a sample product, log, adjust.
5. Deployment and monitoring: launch, observe conversion.

What's Included

• Development and integration of the view tracker
• Creation of a flexible agent with conditions
• Configuration of personal coupons
• Email notifications (optional)
• Documentation and access handover
• 30-day warranty on correct operation

Estimated Timelines

Cost is calculated individually. We'll assess your project for free — just get in touch.

Best Practices and Advanced Tips

Integration with Email Notifications

An email notification about the discount is a critical part of the funnel. Without the email, the coupon sits in the database, and the user doesn't know about it. The template is created in 1C-Bitrix mail events (Marketing → Mail Events). The template includes: product name, photo, new discounted amount, coupon code, and a direct link to the product page.

An optimal chain: the first email immediately after issuing the coupon, the second after 24 hours with a reminder "coupon expires in 48 hours." Such a chain increases the final conversion from 10-15% to 18-22%. Personal coupons are 5 times better than simple email reminders (15% vs 3%).

Typical Mistakes When Setting Up the Trigger

• Too low a view threshold (1 instead of 2-3): random visitors without real purchase intent get coupons.
• No check for existing order: the user already bought the product but still receives a coupon — unnecessary discount.
• No limit on repeat issuance: one user could receive a coupon for the same product multiple times.
• Old records not cleaned: the view table grows, queries slow down.

Comparison of Conversion Mechanics

Personal coupons give 5 times higher conversion than simple reminders. Choose the suitable option for your budget and goals. We guarantee transparency at all stages. Get a consultation — we'll help you choose the best scenario.

This guide covers 1C-Bitrix integration, personal discounts, discount automation, HL-block use, Bitrix agents, marketing triggers, Bitrix coupons, and product discount mechanics — all essential for implementing a successful price drop trigger.

What Typical Pricing and Discount Issues Do We Solve?

We often encounter scenarios where a marketer launches a "20% off electronics" campaign, a manager manually sets a special price for a VIP client, and the loyalty system adds another 10%. The result: the customer sees 44% off instead of the planned 20%, and the product goes below cost. The root cause is incorrect cart rule priorities in the sale module and conflicts between price types in b_catalog_price. Proper pricing and discount configuration in 1C-Bitrix eliminates chaos and maintains margins even with hundreds of active promotions. We can assess your project in one day—just get in touch.

How to Configure Price Types and Select Strategy?

Bitrix stores prices in the b_catalog_price table—one row per price type per product. Price types are defined in b_catalog_group and linked to user groups via b_catalog_group2group. Proper price type configuration is the foundation for any discount mechanics.

For each type, we configure:

• Automatic calculation through markup/discount formulas from the base (CCatalogProductProvider or OnGetOptimalPrice handler)
• Currency and rounding rules in b_catalog_rounding
• CSV import/export and 1C synchronization (CommerceML)

Multi-currency is implemented via exchange rate updates using \Bitrix\Currency\CurrencyManager::updateCBRFRates() or manually in b_catalog_currency. Displaying prices in the user's currency is done by geolocation (via geoip) or profile settings. Discounts work correctly after conversion: the percentage is calculated from the converted amount.

Cart Rules: How to Avoid Discount Conflicts

The sale module, section "Cart Rules" (/bitrix/admin/sale_discount.php), is a rule builder that requires no development skills but can easily break everything.

Common scenarios:

• Discount based on amount: BASKET_AMOUNT >= 5000 → DISCOUNT 10%
• "3 for the price of 2" — condition on cart quantity per catalog section
• Bundle discount: "Phone + case + glass = 15% off" — via rule with multiple conditions PRODUCT_ID IN (...)
• Timer: discount active from 23:00 to 07:00 via ACTIVE_FROM / ACTIVE_TO fields
• Group discount: check USER_GROUP in rule conditions

Priorities — Where Mistakes Usually Happen

Two 20% discounts do not equal 40%. With sequential application: 100 → 80 → 64, net 36% off. With parallel: 100 − 20 − 20 = 60, net 40% off. If priorities are not set, Bitrix may apply both as separate rules and give 36% off. Or the opposite.

We configure:

• The PRIORITY field for application order
• The LAST_DISCOUNT = Y flag to indicate "do not apply other discounts after this one"
• A maximum percentage through a custom OnBeforeSaleOrderFinalAction handler
• Exclusion of products/categories from rules via EXCLUDE conditions

Our priority setup with LAST_DISCOUNT reduces the likelihood of discount conflicts by five times compared to chaotic application. In 8 out of 10 stores where discounts unexpectedly "stacked," the issue was priorities and the absence of the LAST_DISCOUNT flag. We fix this during the audit phase.

How to Avoid Conflicts in Cart Rules?

Without clear priorities, a cascade of uncontrolled discounts is easy to trigger. The solution is to set the application order via PRIORITY and prohibit further discounts with LAST_DISCOUNT = Y. For complex promotions (e.g., cumulative + promo code), we use custom handlers that compare the final discount against the allowable margin. This ensures the customer never leaves with a loss-making checkout.

Cumulative Discounts and Loyalty Programs

Four models to choose from:

• Threshold-based — discount increases with purchase total. Simpler for customers and support.
• Points-based — points earned from purchases, redeemed for rewards. More flexible but harder to understand.
• Tiered — Silver/Gold/Platinum. Gamification retains customers.
• Cashback — returned to internal account (b_sale_user_account).

Threshold System: Example Implementation

Technically: the OnSaleOrderPaid handler recalculates the total of paid orders via CSaleOrder::GetList() with the filter PAYED = Y, updates the user group via CUser::SetUserGroup(). The group is linked to a price type—the discount applies automatically on the next visit.

Additional features:

• Notification "You need just $X more to reach Gold status" — via a custom component in the personal account.
• Level validity period — annual (recalculated by CAgent) or permanent.
• Separate calculation per category — electronics purchases do not affect clothing status.

How It Works in Practice: A Case Study

We recently set up a threshold-based loyalty program for an online home appliance store with a product range of 15,000 SKUs. Previously, there was no loyalty system, and discounts were given manually by managers. We implemented a four-level threshold system. Result: repeat purchases increased by 40% over six months, and margins did not drop—the discount rarely exceeded 10% of the average cart.

Promo Codes and Their Possibilities

Management via CSaleDiscount and a custom administrative interface:

• Single-use — unique code linked to a coupon (b_sale_discount_coupon).
• Multi-use — shared code with a usage limit via MAX_USE.
• Personal — linked to USER_ID.
• Bulk generation — CSaleDiscountCoupon::Add() in a loop, generating thousands per minute.

Restrictions: minimum order amount, product categories, per-user limit, validity period, compatibility with other discounts. Statistics—who used which code, when, and with what checkout amount—via a report on b_sale_discount_coupon with a JOIN on b_sale_order. Linking to UTM tags shows which channel actually drives conversions.

Wholesale Pricing (B2B)

Mechanisms not available out of the box:

• Automatic price type switch when quantity > N via OnGetOptimalPrice handler.
• Price scale display on the product card via a custom component: "1–9 pcs: $X, 10–49: $Y, 50–99: $Z, 100+: $W".
• Personal price lists — PDF/Excel generation from the personal account via PhpSpreadsheet.
• Special price request form → lead in CRM.
• Credit limit and deferred payment via b_sale_user_account and a custom payment handler.

Promotions and Personalization

Scheduling via ACTIVE_FROM / ACTIVE_TO — automatic start and end. Countdown timer — JS component linked to the item's ACTIVE_TO. Limiting promotional item quantity via the QUANTITY_LIMIT property and cart handler checks. A "Promotions" section — via smart filter on the IS_SALE = Y property.

Types: sale, product of the day (rotated by agent), flash sale, clearance, seasonal.

Personalization:

• VIP discounts via individual user group → personal price type.
• Corporate terms: deferred payment, custom delivery.
• Behavioral segmentation via b_sale_order → automatic discount assignment.
• Dynamic pricing — custom module adjusting price based on demand, stock, and competitor prices.

Integration with 1C

• Import price types via CommerceML (standard exchange bitrix:catalog.import.1c).
• Sync discount cards: card number → user group → price type.
• Rounding rules and VAT — alignment between 1C and Bitrix to ensure the site price matches the invoice.
• Scheduled updates (cron + agent) or real-time via REST API.

How We Configure Prices and Discounts: Step-by-Step Process

1. Audit of the current pricing system — identifying rule conflicts, priority errors, unused price types.
2. Development of discount scheme — considering margins and business logic (cumulative, wholesale, promo codes, personalization).
3. Cart rule configuration — priorities, flags, exceptions.
4. 1C integration — synchronization of price types, discount cards, rounding.
5. Testing — load testing with 100+ active rules, conflict checks.
6. Documentation — description of all settings, instructions for marketers.
7. Manager training — how to create and disable promotions without risk.
8. 30-day support — fix any anomalies after launch.

Timelines

Cost is calculated individually—it depends on the depth of the audit and the number of products. Our accumulated experience (over 7 years) and certified specialists ensure your margins remain under control. Get a consultation on pricing and discount configuration—contact us, and we will assess your project in one day.