Developing a Content Personalization Module for 1C-Bitrix

Imagine an online store on 1C-Bitrix with 50,000 products. A new visitor sees the same landing page as a wholesale client. Conversion drops, and personalization is absent. This is a typical situation for many projects: static blocks of content do not consider the interests of different segments. We develop a content personalization module that solves this problem. Our team has 7+ years of experience in 1C-Bitrix development and has completed over 50 projects.

Personalized blocks yield CTR 35–50% higher than static ones, and conversion in segmented groups grows 1.5–2 times. The module integrates easily with the existing trade catalog and CRM. According to our data, implementing personalization increases LTV by 20% and shortens the purchase path by 30%.

Why standard Bitrix tools are insufficient for content personalization?

User groups with access restrictions do not provide flexible personalization. You cannot show different content to a new visitor and a client with orders. As 1C-Bitrix documentation notes, user groups are not intended for flexible personalization. For that, you need segments with dynamic conditions, behavioral profiles, and recalculation agents. Our module vendor.personalize adds this functionality without changing the kernel.

How does the content personalization module improve conversion?

The module builds a data model that includes the following entities:

• b_vendor_ps_rule — personalization rules: id, name, priority, conditions (JSON), action (JSON), is_active, created_at
• b_vendor_ps_segment — audience segments: id, name, conditions (JSON), is_active
• b_vendor_ps_user_segment — user membership in segments: user_id, segment_id, assigned_at
• b_vendor_ps_impression — impressions of personalized content: id, rule_id, user_id, session_id, element_id, created_at
• b_vendor_ps_profile — behavioral profile: user_id or session_id, data (JSON: viewed sections, categories, source, RFM metrics)

Segmentation and condition evaluation — developing the personalization module

Segments are defined by a set of conditions. Example conditions for the "warm users" segment — visited 3+ times in the last 7 days, came from search, haven't purchased yet:

{ "logic": "AND", "rules": [ {"type": "visit_count", "operator": ">=", "value": 3}, {"type": "has_orders", "operator": "=", "value": false}, {"type": "last_visit_days", "operator": "<=", "value": 7}, {"type": "traffic_source", "operator": "=", "value": "google"} ] } 

Condition evaluation is performed by the SegmentEvaluator class:

class SegmentEvaluator { public function evaluate(array $conditions, PersonalityProfile $profile): bool { $logic = $conditions['logic'] ?? 'AND'; $results = []; foreach ($conditions['rules'] as $rule) { $results[] = $this->evaluateRule($rule, $profile); } return $logic === 'AND' ? !in_array(false, $results) : in_array(true, $results); } private function evaluateRule(array $rule, PersonalityProfile $profile): bool { return match ($rule['type']) { 'visit_count' => $this->compare($profile->getVisitCount(), $rule['operator'], $rule['value']), 'has_orders' => $profile->hasOrders() === (bool)$rule['value'], 'last_visit_days' => $this->compare($profile->getDaysSinceLastVisit(), $rule['operator'], $rule['value']), 'traffic_source' => $profile->getTrafficSource() === $rule['value'], 'city_id' => in_array($profile->getCityId(), (array)$rule['value']), default => true, }; } } 

Behavioral profile

Each visit updates the session/user profile. Over 100,000 profiles are processed overnight.

// Initialized in init.php via the OnProlog event PersonalityProfileCollector::collect([ 'page' => $_SERVER['REQUEST_URI'], 'referrer' => $_SERVER['HTTP_REFERER'] ?? null, 'utm_source' => $_GET['utm_source'] ?? null, 'iblock_section' => $APPLICATION->GetCurDir(), // current section ]); 

The profile is stored in b_vendor_ps_profile as JSON and contains: visit counter, viewed categories, first and last visit dates, first visit source, order presence flag.

Personalized blocks

The vendor:personalize.block component — replaces a static content block:

// In the page template: $APPLICATION->IncludeComponent('vendor:personalize.block', '', [ 'ELEMENT_ID' => 'hero_cta', // block identifier on the page ]); 

The component finds the active personalization rule for the current user and renders the corresponding content. Rule actions can be:

• show_text — show text/HTML
• show_iblock_element — show a specific info block element
• show_banner — show a banner from b_vendor_ps_banner
• redirect — redirect to a URL

Segment recalculation

Segment membership is not determined on every request — that's expensive. An agent recalculates segments nightly:

// For each active segment — recalculate from b_vendor_ps_profile // Result — INSERT/DELETE in b_vendor_ps_user_segment SegmentCalculator::recalculate(); 

For new session users (not authenticated) — evaluation in real time using session data. Recalculation takes 2 minutes for 5000 users.

Analytics

• CTR of personalized blocks vs standard (comparison with control group)
• Distribution of users by segments
• Conversion by segment to orders

Comparison: standard groups vs personalization module

What's included in the work

• Module source code with migrations
• Installation and agent configuration guide
• Administrator training on working with rules and segments
• 6-month warranty on module code

How to set up the module in 5 steps

1. Install the vendor.personalize module via Marketplace or manual upload.
2. Run migrations to create ORM tables.
3. Configure the profile collection agent in the module settings.
4. Create segments and rules through the administrative interface.
5. Place the vendor:personalize.block component in the desired templates.

Development timeline

Total: 11 working days. Integration with ML recommendation models (collaborative filtering) is a separate project.

Assess the effectiveness of personalization for your store — get a preliminary estimate. Contact us for a consultation. Order development of a personalization module for your tasks.