A/B тестування на 1С-Бітрікс: серверні та клієнтські методи
Уявіть: ви переписали картку товару, змінили форму замовлення, а конверсія впала на 20%. Без A/B тесту ви не дізнаєтеся, який елемент спрацював. Бітрікс-розробники часто стикаються з тим, що штатний модуль abtest не враховує кешування і слабко інтегрується з аналітикою. З нашої практики: один інтернет-магазин електроніки з каталогом 5000 товарів хотів протестувати нову систему динамічних знижок. Ми реалізували серверний A/B тест з розділенням по cookie, передачею групи в dataLayer і відстеженням конверсії в GA4. Вихідна конверсія 2.5%, через 3 тижні тесту у варіанті B конверсія досягла 3.1% — приріст 24% при p-value 0.03. Оцінимо ваш проект і запропонуємо оптимальне рішення. Зв'яжіться з нами для консультації.
Проблеми, які вирішуємо
- Кешування: якщо компонент кешує результат, обидва варіанти отримають однаковий HTML. Рішення — додаємо cookie
BITRIX_SM_ABTEST_{ID}у ключ кешу або вимикаємо кеш для тестованого блоку. - Інтеграція з аналітикою: штатний модуль не передає дані безпосередньо в Яндекс.Метрику або GA4. Ми налаштовуємо dataLayer та користувацькі параметри, щоб будувати звіти з розбивкою по групах.
- Серверна логіка: тестування цін, знижок або алгоритмів вимагає кастомного PHP-коду. Штатний модуль для цього не підходить.
Як ми це робимо: стек і кейс
Використовуємо PHP 8.1+, інфоблоки v2.0, Комплексне кешування з тегами. Для інтернет-магазину електроніки (з нашої практики) реалізували серверний A/B тест з кастомним PHP-кодом. Код визначення групи:
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; } // Використання if (getABGroup('discount_algorithm') === 'B') { // Новий алгоритм знижки } else { // Поточний алгоритм } Як працює штатний модуль abtest?
Модуль abtest доступний у редакціях «Бізнес» та «Ентерпрайз». Створюєте тест із зазначенням відсотка трафіку для варіанту B, обираєте тип (шаблон, компонент, область, що включається, PHP-код). Бітрікс призначає групу через cookie. API-створення:
\Bitrix\ABTest\ABTestManager::addTest([ 'NAME' => 'Кнопка купити: червона vs зелена', 'SITE_ID' => 's1', 'DURATION' => 14, 'PORTION' => 50, 'TEST_DATA' => [ 'type' => 'template', 'original' => '/local/templates/main/', 'modified' => '/local/templates/main_test/', ], ]); Як обрати підхід: серверний чи клієнтський?
Клієнтські тести (VWO, Optimizely) не потребують змін серверного коду, але мають затримку (FOUC) і не працюють із серверною логікою. Серверний підхід, навпаки, дозволяє тестувати ціни, знижки, алгоритми — все, що виконується на PHP. Якщо потрібно перевірити зміну шаблону або області, що включається, достатньо штатного модуля. Для складних сценаріїв (різні ціни для груп, персоналізація) — кастомний серверний код. Ми допомагаємо обрати метод під ваші завдання.
Чому кешування — головний ворог A/B тестів?
Типова помилка: компонент кешує HTML, і обидва варіанти показують однаковий контент. Рішення — додаємо ідентифікатор тесту в ключ кешу або вимикаємо кеш для тестованого блоку. Наприклад, через $arParams['CACHE_TIME'] = 0; або використовуючи \Bitrix\Main\Data\Cache::setCacheTag(). Без цього результати тесту будуть некоректні.
Як досягти статистичної значущості?
Типова помилка — зупинити тест через 2 дні, побачивши різницю 0.5%. Для достовірності потрібен обсяг вибірки: при базовій конверсії 2% і бажаному ефекті 20% потрібно ~20 000 візитів на варіант. На сайті з 1000 візитів на день — 40 днів. Не зупиняйте тест, поки p-value не опуститься нижче 0.05. Використовуємо калькулятор статистичної значущості для точного розрахунку.
Порівняння підходів
| Критерій | Штатний модуль abtest | Кастомний серверний підхід |
|---|---|---|
| Типи тестів | Шаблони, компоненти, області, що включаються, PHP-код | Будь-яка логіка (ціни, знижки, алгоритми) |
| Інтеграція з аналітикою | Слабка, через цілі | Повна через dataLayer та API |
| Сегментація | Немає | Можна реалізувати |
| Мультиваріантність | Ні (тільки A/B) | Так (A/B/C/D) |
| Складність налаштування | Низька | Середня-висока |
| Залежність від редакції | Потрібна Бізнес/Ентерпрайз | Будь-яка редакція |
Що входить у роботу
- Аудит поточної архітектури та трафіку
- Формулювання гіпотез та визначення метрик
- Вибір підходу та налаштування механізму тестування
- Вирішення проблем кешування та інтеграція з аналітикою (dataLayer, GA4, Яндекс.Метрика)
- Розрахунок необхідного обсягу вибірки та тривалості
- Моніторинг, збір даних та статистична обробка
- Звіт з висновками та рекомендаціями
Процес роботи
| Етап | Зміст |
|---|---|
| 1. Аудит | Аналіз поточного сайту, трафіку, цілей, гіпотез |
| 2. Розробка гіпотез | Визначення ключових метрик, вибір типу тесту |
| 3. Налаштування тесту | Налаштування штатного або кастомного механізму |
| 4. Рішення кешування | Розділення кешу по групах тесту |
| 5. Інтеграція з аналітикою | Передача даних у dataLayer, налаштування звітів у Яндекс.Метриці/GA4 |
| 6. Розрахунок тривалості | Визначення необхідного обсягу вибірки та часу |
| 7. Моніторинг і звітність | Збір результатів, статистична обробка, висновки |
Строки орієнтовно
Від 2 днів до 2 тижнів залежно від складності. Вартість розраховується індивідуально після аудиту. Отримайте консультацію з налаштування A/B тестування.
Типові помилки
- Зупинка тесту раніше часу: навіть при видимій різниці дочекайтеся статистичної значущості.
- Ігнорування кешування: не забудьте вимкнути кеш для тестованих компонентів або розділити його по групах.
- Неправильна сегментація: якщо тест запущено на всіх користувачів, результати можуть бути розмитими. Враховуйте сезонність та аудиторію.
Ми маємо 10+ років досвіду розробки на Бітрікс та сертифікацію. Гарантуємо коректне налаштування та інтерпретацію результатів. Зв'яжіться з нами для аудиту вашого проекту.