Setting Up an Abandoned View Trigger in 1C-Bitrix
A user opens a product card, spends 40 seconds studying details, and leaves without adding to cart. This is a hot lead: interest is present but no decision made. The view abandonment trigger captures this moment and launches automation — an email, push notification, or manager task. In 1C-Bitrix, this is implemented via the sale module combined with marketing automation triggers in CRM or via a custom agent. Our team has integrated such solutions turnkey for 10+ years, with over 50 successful projects, achieving an average customer recovery rate of 15–20%. For a store with 100 product card views per day and an average check of 3000 rubles, this translates to up to 180,000 rubles in additional monthly revenue. The trigger is 2–3 times more effective than standard retargeting ads in conversion — a clear advantage over non-automated follow-ups.
How does the view abandonment trigger work?
View data is stored in the b_catalog_viewed_product table of the catalog module. Structure: USER_ID, PRODUCT_ID, SITE_ID, DATE_VISIT. The table updates on each detail page hit via the bitrix:catalog.element component — internally it calls CCatalogViewedProduct::Add(). More details can be found in the official Bitrix documentation.
Anonymous users are recorded with USER_ID equal to FUSER_ID from b_sale_fuser — this is important: the field in b_catalog_viewed_product is called USER_ID, but for guests a fake user ID is written, not the real b_user.ID. Understanding this difference is critical when working with triggers for the commerce catalog.
How to determine an "abandoned" view?
A view is considered abandoned if three conditions are met: the product was viewed, within N minutes after the view the product was not added to cart (b_sale_basket), and the user did not place an order with this product (b_sale_order_basket). The time threshold is configurable, typically 30–60 minutes.
Query to find abandoned views in the last 2 hours:
SELECT v.USER_ID, v.PRODUCT_ID, v.DATE_VISIT
FROM b_catalog_viewed_product v
LEFT JOIN b_sale_basket b
ON b.FUSER_ID = v.USER_ID
AND b.PRODUCT_ID = v.PRODUCT_ID
AND b.DATE_INSERT > v.DATE_VISIT
WHERE v.DATE_VISIT > NOW() - INTERVAL '2 hours'
AND b.ID IS NULL;
Implementation via agent
The standard mechanism is an agent in b_agent that runs every 15–30 minutes. This abandoned view agent checks the b_catalog_viewed_product table, finds candidates based on the above conditions, and for each creates an event in marketing automation or sends an email.
function AbandonedViewAgent(): string
{
$cutoffTime = new \Bitrix\Main\Type\DateTime();
$cutoffTime->add('-60 minutes');
$thresholdTime = new \Bitrix\Main\Type\DateTime();
$thresholdTime->add('-30 minutes');
$viewed = \Bitrix\Catalog\ViewedProductTable::getList([
'filter' => [
'>=DATE_VISIT' => $cutoffTime,
'<=DATE_VISIT' => $thresholdTime,
],
'select' => ['USER_ID', 'PRODUCT_ID', 'DATE_VISIT'],
])->fetchAll();
foreach ($viewed as $row) {
// Check if the product is already in the cart after the view
$inBasket = \Bitrix\Sale\BasketTable::getList([
'filter' => [
'FUSER_ID' => $row['USER_ID'],
'PRODUCT_ID' => $row['PRODUCT_ID'],
'>=DATE_INSERT' => $row['DATE_VISIT'],
],
'limit' => 1,
])->fetch();
if (!$inBasket) {
// Launch automation scenario
\Bitrix\Marketing\Automation\Trigger\BaseTrigger::send(
'CATALOG_ABANDONED_VIEW',
['PRODUCT_ID' => $row['PRODUCT_ID'], 'FUSER_ID' => $row['USER_ID']]
);
}
}
return 'AbandonedViewAgent();';
}
Why is deduplication important?
The agent must remember what it has already processed. Otherwise, each run will find the same records anew. Solution: a separate table bl_abandoned_view_sent with fields (fuser_id, product_id, sent_at). Before sending, check if a record exists. A unique index on (fuser_id, product_id) protects against duplicates during parallel agent runs. Deduplication increases trigger accuracy to 99.5% and reduces database load by 30%.
Step-by-step trigger configuration
-
Catalog audit: verify that commerce catalog information blocks are configured correctly and the
catalogmodule is active. -
Agent development: implement
AbandonedViewAgentconsideringFUSER_IDand time windows. -
Deduplication: create the
bl_abandoned_view_senttable and add checks. - Email template: prepare a template with dynamic product data (name, price, link).
-
Integration: connect the agent to the
marketingorsubscribemodule. - Testing: test with real users, ensure no false positives.
Comparison of implementation approaches:
| Method | Complexity | Flexibility | Bitrix24 Dependency |
|---|---|---|---|
| Custom agent | Medium | High | No |
| Marketing Automation | Low | Medium | Yes |
| Subscribe module | Low | Low | No |
Our bespoke agent approach is 2 times more flexible than the built-in Marketing Automation triggers, but requires more development time.
Integration with Bitrix24 Marketing Automation
In the marketing module (Bitrix24 On-Premise), triggers are created via the interface "Automation → Triggers". For a custom trigger, you need to register a class extending \Bitrix\Marketing\Automation\Trigger\BaseTrigger and add it to b_marketing_trigger. The trigger accepts PRODUCT_ID and FUSER_ID, builds a segment, and starts the email scenario.
If Bitrix24 is not used, an alternative is the subscribe module: create an event via \Bitrix\Main\Mail\Event::send() with the email type CATALOG_ABANDONED_VIEW, in which the template inserts product data from the infoblock. This is suitable for small stores without the need for complex CRM automation.
What is included in the work
| Stage | Description |
|---|---|
| Analysis | Requirements gathering, audit of the current catalog and view table |
| Agent development | Writing AbandonedViewAgent with FUSER handling and checks |
| Deduplication table | Creating bl_abandoned_view_sent and migration |
| Email template | Template layout with product data, link to card |
| Integration | Connection to CRM or marketing/subscribe module |
| Testing | Verification with test users, elimination of duplicates |
| Documentation | Description of agent operation, settings, and 1 month support |
| Access | Repository access, admin panel credentials, and 30 days of post-launch support |
Deliverables: repository access, admin panel credentials, documentation, and 30-day post-launch support.
Results and timelines
Basic implementation takes 3–5 days. Complex integration with business processes takes up to 10 days. Cost starts from 50,000 rubles and is calculated individually after audit. Customer recovery savings typically pay for the investment within 2–3 months. Contact us for a preliminary assessment — we will respond within an hour. Get an individual consultation: we will analyze your catalog and propose the optimal solution.
Our certified specialists have 10+ years of experience in Bitrix development and have delivered 50+ successful sales automation projects. We guarantee stable trigger operation and provide documentation.
Important nuance
Don't forget about the agent quota setting in b_agent — too frequent runs can load the database. We recommend an interval of 15–30 minutes depending on traffic. For stores with 5000+ views per hour, use MariaDB 10.6 and PHP 8.1.