Competitor Price Monitoring in 1C-Bitrix: Setup & Integration

Setting Up Competitor Price Monitoring for 1C-Bitrix

We worked with a major home appliance online retailer whose competitors changed prices up to 15 times a day. Manual monitoring took a manager 2 hours daily, and reaction delays cost up to 5% margin on individual items. Our solution: automatic competitor price tracking inside 1C-Bitrix.

Price tracking is built in one of two ways: through a ready monitoring service (Competera, Metacommerce, Priceva) or via a custom parser. Ready services are simpler and more reliable but expensive for catalogs over 10,000 SKUs. Custom parsers are flexible and cheap to operate but require regular maintenance when competitor sites change. In both cases, the setup task is the same: collect data, save it in Bitrix, and present it to the manager in a convenient way.

Approach Comparison: Service vs Parser

The choice depends on your budget and volume. For catalogs over 50,000 products, a parser is usually more cost-effective.

Why You Should Not Store Competitor Prices in Infoblocks

Bitrix infoblocks are not designed for frequent mass updates. With 10,000 products and 5 competitors, you get 50,000 records rewritten every hour. The infoblock ORM generates unnecessary events (OnBeforeIBlockElementUpdate), flushes cache, and slows down the admin panel. The solution is to use HL-blocks or separate database tables. We prefer tables—they are faster, without event overhead or versioning.

Data Storage Architecture

Regardless of the data source, the storage structure is the same. We create two main tables:

Competitors bl_price_competitors:

CREATE TABLE bl_price_competitors (
    id       SERIAL PRIMARY KEY,
    name     VARCHAR(255) NOT NULL,
    domain   VARCHAR(255) UNIQUE,
    active   BOOLEAN DEFAULT true,
    logo_url VARCHAR(512)
);

Competitor Prices bl_competitor_prices:

CREATE TABLE bl_competitor_prices (
    id             SERIAL PRIMARY KEY,
    product_id     INT NOT NULL,               -- b_iblock_element.ID
    competitor_id  INT REFERENCES bl_price_competitors(id),
    price          NUMERIC(12,2) NOT NULL,
    url            VARCHAR(512),               -- URL of competitor's page
    in_stock       BOOLEAN DEFAULT true,
    checked_at     TIMESTAMP NOT NULL DEFAULT NOW(),
    UNIQUE (product_id, competitor_id)         -- one current price per competitor
);
CREATE INDEX idx_comp_prices_product ON bl_competitor_prices(product_id, checked_at DESC);

History bl_competitor_prices_history—a month-partitioned table to store changes without bloating the main table. When the current price is updated, the previous value moves to history.

API Integration via Monitoring Service

With a ready service, an agent requests data and writes to bl_competitor_prices:

function SyncCompetitorPrices(): string
{
    $client = new PriceMonitoringClient(MONITORING_API_KEY);
    $data   = $client->getPrices(['date' => date('Y-m-d')]);

    foreach ($data['products'] as $item) {
        $productId = ProductMapper::findBySku($item['sku']);
        if (!$productId) continue;

        foreach ($item['competitors'] as $comp) {
            $competitorId = CompetitorTable::getOrCreateByDomain($comp['domain']);

            // Save to history before update
            $current = CompetitorPriceTable::getByProductAndCompetitor($productId, $competitorId);
            if ($current && $current['PRICE'] != $comp['price']) {
                CompetitorPriceHistoryTable::add([
                    'PRODUCT_ID'    => $productId,
                    'COMPETITOR_ID' => $competitorId,
                    'PRICE'         => $current['PRICE'],
                    'RECORDED_AT'   => $current['CHECKED_AT'],
                ]);
            }

            CompetitorPriceTable::addOrUpdate([
                'PRODUCT_ID'    => $productId,
                'COMPETITOR_ID' => $competitorId,
                'PRICE'         => $comp['price'],
                'URL'           => $comp['url'],
                'IN_STOCK'      => $comp['in_stock'],
                'CHECKED_AT'    => new \Bitrix\Main\Type\DateTime(),
            ]);
        }
    }

    return __FUNCTION__ . '();';
}

Calculating Price Position and Aggregates

Upon each update, we calculate aggregates and position in bl_product_price_position:

-- Updated via trigger or agent after sync
INSERT INTO bl_product_price_position (product_id, our_price, min_comp, avg_comp, max_comp, rank, updated_at)
SELECT
    cp.product_id,
    bcp.PRICE as our_price,
    MIN(cp.price) as min_comp,
    ROUND(AVG(cp.price), 2) as avg_comp,
    MAX(cp.price) as max_comp,
    (SELECT COUNT(*) + 1 FROM bl_competitor_prices cp2
     WHERE cp2.product_id = cp.product_id AND cp2.price < bcp.PRICE) as rank,
    NOW()
FROM bl_competitor_prices cp
JOIN b_catalog_price bcp ON bcp.PRODUCT_ID = cp.product_id AND bcp.CATALOG_GROUP_ID = 1
GROUP BY cp.product_id, bcp.PRICE
ON CONFLICT (product_id) DO UPDATE SET
    our_price = EXCLUDED.our_price, min_comp = EXCLUDED.min_comp,
    avg_comp = EXCLUDED.avg_comp, rank = EXCLUDED.rank, updated_at = NOW();

How to Set Up Alerts for Competitor Price Changes?

An agent compares new prices with previous ones and notifies managers of significant changes—for example, when a competitor becomes cheaper than us:

foreach ($priceChanges as $change) {
    if ($change['new_price'] < $change['our_price'] && $change['old_price'] >= $change['our_price']) {
        $message = sprintf(
            'Competitor %s has lowered price on %s to %s RUB (ours: %s RUB)',
            $change['competitor_name'],
            $change['product_name'],
            number_format($change['new_price'], 2, ',', ' '),
            number_format($change['our_price'], 2, ',', ' ')
        );
        \Bitrix\Main\Mail\Event::send([
            'EVENT_NAME' => 'COMPETITOR_PRICE_ALERT',
            'LID'        => SITE_ID,
            'C_FIELDS'   => ['MESSAGE' => $message],
        ]);
    }
}

Typical Mistakes in Monitoring Setup

• Using infoblocks for storage—leads to performance degradation above 20,000 records.
• Missing indexes on product_id and checked_at—the sync agent runs hours instead of minutes.
• Parsers without error handling—when a competitor's site goes down, the agent throws an exception and stops until manual intervention.
• Too infrequent updates—with once-a-day updates, you miss intraday fluctuations that can reach 30%.

What Is Included in Our Service Setup?

• Analysis of your catalog and selection of the optimal data source (service or parser).
• Creation of tables or HL-blocks for competitors, prices, and history.
• Development of a synchronization agent with detailed error handling (logging, retries).
• Implementation of a price position calculation module with ranking.
• Display of competitor prices in the product card in the admin panel and on the storefront (optional).
• Configuration of email or Bitrix24 notifications.
• Architecture documentation and maintenance instructions.

Timelines and Our Guarantees

Pricing is determined individually based on catalog size and integration complexity. We guarantee stable agent operation for 6 months after delivery. Contact us for a free project assessment, and we'll propose an architecture for your budget. Get a consultation on price monitoring architecture, and you'll see that automation pays off within the first two months.

Over 10 years of experience in Bitrix and Bitrix24 development, more than 50 successful integrations with price monitoring systems—our expertise handles any complexity.

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.