A/B Testing on 1C-Bitrix: Server-Side and Client-Side Methods
Imagine: you rewrote the product card, changed the order form, and conversion dropped by 20%. Without an A/B test, you won't know which element caused it. Bitrix developers often face the fact that the built-in abtest module does not consider caching and integrates poorly with analytics. From our practice: an electronics e-commerce store with 5,000 products wanted to test a new dynamic discount system. We implemented a server-side A/B test with cookie-based split, passing the group to dataLayer and tracking conversion in GA4. Baseline conversion was 2.5%, after 3 weeks of testing variant B reached 3.1% — a 24% increase with a p-value of 0.03. Let's evaluate your project and suggest the optimal solution. Contact us for a consultation.
Problems We Solve
-
Caching: if a component caches its result, both variants get the same HTML. Solution — add the cookie
BITRIX_SM_ABTEST_{ID}to the cache key or disable caching for the tested block. - Analytics integration: the built-in module does not directly send data to Yandex.Metrica or GA4. We configure dataLayer and custom parameters to build reports broken down by groups.
- Server-side logic: testing prices, discounts, or algorithms requires custom PHP code. The built-in module is not suitable for this.
How We Do It: Stack and Case Study
We use PHP 8.1+, infoblocks v2.0, and tag-based composite caching. For the electronics e-commerce store (from our practice), we implemented a server-side A/B test with custom PHP code. The group detection code:
function getABGroup(string $testName, int $percentB = 50): string { $cookieName = 'ab_' . md5($testName); if (isset($_COOKIE[$cookieName])) { return $_COOKIE[$cookieName]; } $group = (mt_rand(1, 100) <= $percentB) ? 'B' : 'A'; setcookie($cookieName, $group, time() + 86400 * 30, '/'); return $group; } // Usage if (getABGroup('discount_algorithm') === 'B') { // New discount algorithm } else { // Current algorithm } How the Built-in abtest Module Works
The abtest module is available in Business and Enterprise editions. You create a test specifying the percentage of traffic for variant B and choose the type (template, component, include area, PHP code). Bitrix assigns groups via cookie. API creation:
\Bitrix\ABTest\ABTestManager::addTest([ 'NAME' => 'Buy button: red vs green', 'SITE_ID' => 's1', 'DURATION' => 14, 'PORTION' => 50, 'TEST_DATA' => [ 'type' => 'template', 'original' => '/local/templates/main/', 'modified' => '/local/templates/main_test/', ], ]); How to Choose the Approach: Server-Side or Client-Side?
Client-side tests (VWO, Optimizely) require no server code changes but suffer from FOUC delay and cannot test server logic. The server-side approach, on the other hand, allows testing prices, discounts, algorithms — everything that runs on PHP. If you need to test a template or include area change, the built-in module is sufficient. For complex scenarios (different prices for groups, personalization) — custom server-side code. We help you choose the method for your tasks.
Why Caching Is the Main Enemy of A/B Tests
A typical mistake: a component caches HTML, and both variants show identical content. The solution — add the test identifier to the cache key or disable caching for the tested block. For example, via $arParams['CACHE_TIME'] = 0; or by using \Bitrix\Main\Data\Cache::setCacheTag(). Without this, test results will be incorrect.
How to Achieve Statistical Significance
A typical mistake — stopping the test after 2 days seeing a 0.5% difference. For reliability, you need a sufficient sample size: with a baseline conversion of 2% and a desired effect of 20%, you need approximately 20,000 visits per variant. On a site with 1,000 visits per day — 40 days. Do not stop the test until the p-value drops below 0.05. We use a statistical significance calculator for precise calculations.
Comparison of Approaches
| Criterion | Built-in abtest module | Custom server-side approach |
|---|---|---|
| Test types | Templates, components, include areas, PHP code | Any logic (prices, discounts, algorithms) |
| Analytics integration | Weak, via goals | Full via dataLayer and API |
| Segmentation | No | Can be implemented |
| Multivariate testing | No (only A/B) | Yes (A/B/C/D) |
| Setup complexity | Low | Medium-High |
| Edition dependency | Requires Business/Enterprise | Any edition |
What Is Included in Our Work
- Audit of current architecture and traffic
- Formulation of hypotheses and metric definition
- Approach selection and testing mechanism setup
- Caching problem resolution and analytics integration (dataLayer, GA4, Yandex.Metrica)
- Required sample size and duration calculation
- Monitoring, data collection, and statistical processing
- Report with conclusions and recommendations
Work Process
| Stage | Description |
|---|---|
| 1. Audit | Analyze current site, traffic, goals, hypotheses |
| 2. Hypothesis development | Define key metrics, choose test type |
| 3. Test setup | Configure built-in or custom mechanism |
| 4. Caching resolution | Separate cache by test groups |
| 5. Analytics integration | Send data to dataLayer, set up reports in Yandex.Metrica/GA4 |
| 6. Duration calculation | Determine required sample size and time |
| 7. Monitoring and reporting | Collect results, statistical processing, conclusions |
Estimated Timeline
From 2 days to 2 weeks depending on complexity. Pricing is determined individually after an audit. Get a consultation on setting up A/B testing.
Typical Mistakes
- Stopping the test prematurely: even if you see a visible difference, wait for statistical significance.
- Ignoring caching: remember to disable caching for tested components or separate it by groups.
- Incorrect segmentation: if the test runs on all users, results can be diluted. Account for seasonality and audience.
We have 10+ years of Bitrix development experience and certification. We guarantee correct setup and interpretation of results. Contact us for a project audit.

