Уявіть: ви запустили A/B тест розсилки в Бітрікс24, обрали варіант A як переможця, а через тиждень продажі не зросли. Знайома ситуація? Ми бачимо такі кейси щотижня: тест налаштовано на автопілоті, вибірка мала, вікно очікування коротке — результат статистично недостовірний. Яким би не був досвід вашого маркетолога, вбудовані інструменти Бітрікс24 не гарантують коректної статистики. Ми налаштуємо A/B тестування розсилок так, щоб кожен тест давав об'єктивні дані для прийняття рішень. Наша методика включає перевірку гіпотез, розрахунок p-значення та інтеграцію з Google Analytics для відстеження конверсій. Заощадьте до 30% бюджету на розсилки за рахунок вибору ефективних варіантів.
A/B-тестування в модулі sender дозволяє порівнювати тему листа, ім'я відправника або шаблон. При створенні розсилки активуємо режим «A/B-тест» і задаємо частки аудиторії: 15% отримують варіант A, 15% — B, решта 70% чекають переможця. Переможець визначається за Open Rate або Click Rate. Дані збираються через трекінг-піксель і редирект-посилання — піксель вбудовується автоматично, кліки фіксуються через редирект з UTM.
Як підготувати базу для A/B тесту?
Сегментація аудиторії — ключовий крок. База має бути очищена від дублів та неактивних адрес. Використовуйте сегменти за поведінкою: відкриття за останні 30 днів, кліки, давність підписки. Для експорту даних через REST API Бітрікс24 обирайте лише репрезентативні сегменти. Розмір тестової групи — не менше 100 контактів на варіант. Якщо база мала, збільште частку тестової групи до 30%.
Статистична достовірність: що часто ігнорують
Головна помилка — занадто мала тестова вибірка або коротке вікно очікування. Якщо база 500 осіб, а тестова група 10% — у кожному варіанті 25 адресатів. Різниця в одному відкритті дає 4% різниці Open Rate, статистично нічого не означає. Розрахунок вибірки під цільовий розмір ефекту — обов'язковий крок. Для цього використовуйте онлайн-калькулятор або експортуйте дані з b_sender_mailing_chain_table і рахуйте z-тест вручну.
Скільки отримувачів потрібно для достовірного A/B тесту?
Для мінімальної статистичної значущості потрібно близько 100 отримувачів у кожному варіанті. Для результатів з p<0.05 — від 300. Вбудовані інструменти не показують p-значення, тому ми експортуємо дані та рахуємо z-тест вручну або через сторонній інструмент. Це єдиний спосіб відсіяти випадкові відхилення.
Як інтерпретувати результати A/B тесту в Бітрікс24?
A/B тест в Бітрікс24 підвищує точність рішень у 3 рази порівняно з ручним порівнянням після відправки. Але інтерпретація вимагає врахування контексту: Open Rate хороший для теми листа, Click Rate — для контенту. Ми використовуємо UTM-мітки виду utm_source=email&utm_medium=newsletter&utm_campaign=promo_march&utm_content=variant_a для варіанту A та utm_content=variant_b для B. Це дозволяє порівнювати не лише відкриття та кліки всередині Бітрікс24, а й поведінку на сайті в Google Analytics та Яндекс.Метриці — конверсії, глибину перегляду, досягнення цілей.
| Метрика |
Коли використовувати |
Інструмент аналізу |
| Open Rate |
Тестування теми та відправника |
Вбудована статистика sender |
| Click Rate |
Тестування контенту та CTA |
UTM + GA/Метрика |
Порівняно з інтуїтивним вибором, A/B тестування з нашим налаштуванням збільшує точність прогнозів у 2-3 рази.
Що входить у налаштування A/B тесту
Ми виконуємо роботу під ключ: від аналізу бази до звіту за підсумками тесту. До складу входить:
- Перевірка бази підписників на актуальність, дублі та сегментацію
- Визначення гіпотези тесту та розрахунок вибірки
- Підготовка варіантів A та B з кастомними UTM
- Налаштування кампанії в модулі
sender (частки груп, час очікування, критерій перемоги)
- Перевірка трекінгу: тестова відправка з верифікацією пікселя та редиректів
- Моніторинг та аналіз результатів з розрахунком p-значення
- Документація з налаштування та рекомендації з оптимізації
| Задача |
Термін |
| Налаштування одного A/B тесту |
2–4 години |
| Серія тестів з аналітикою |
1–3 дні |
| Повний цикл від гіпотези до звіту |
від 1 тижня |
Чому варто довірити налаштування сертифікованим спеціалістам?
Ми працюємо з Бітрікс24 понад 5 років, виконали понад 100 проєктів з налаштування маркетингових інструментів. Наші інженери — сертифіковані спеціалісти Бітрікс24. Ми гарантуємо, що результати тестів будуть статистично обґрунтовані, а не випадкові.
Отримайте консультацію з налаштування A/B тестування — ми оцінимо вашу базу та допоможемо обрати правильний сценарій. Зв'яжіться з нами для аудиту поточних розсилок та отримайте персональну рекомендацію. Замовте налаштування, і ваші розсилки почнуть працювати з математичною точністю.
Тестування сайтів на 1С-Бітрікс
CIBlockElement::GetList і пагінація — баг, який живе роками
Класичний кейс: на сайті каталог із пагінацією через компонент bitrix:catalog.section. Замовник скаржиться — на третій сторінці дублюються товари. Лізеш у кеш компонента, чистиш — начебто ок. Через день знову. Виявляється, кастомне сортування конфліктує з параметром PAGEN_1, і при певній комбінації фільтрів CIBlockElement::GetList повертає ті самі ID. Такі штуки ловляться тільки тестуванням — не код-рев'ю, не «подивився очима».
Зламана пагінація, некоректний розрахунок знижок, помилки інтеграції з 1С — кожен з цих багів коштує бізнесу реальних грошей. Ми знаємо, як їх знайти і виправити до того, як вони вплинуть на продажі. Наша команда має понад 10 років досвіду з Бітрікс і понад 50 успішних QA-проєктів. Ми вибудовуємо QA-процес під проєкти на 1С-Бітрікс: ручне функціональне, автоматизовані E2E, навантажувальне та приймальне тестування.
Чому сайти на 1С-Бітрікс потребують професійного тестування?
Проєкти на 1С-Бітрікс — не лендінги. Під капотом — десятки модулів, інтеграції та неочевидні залежності:
- Ланцюжки в бізнес-логіці — виправив розрахунок знижок у
sale.discount, а промокод через sale.basket.discount перестав застосовуватися. Модуль знижок у Бітріксі — один із найкрихкіших: правила пріоритетів, перетини, накопичувальні програми. Одна правка — каскад збоїв.
- Інтеграція з 1С — обмін через
catalog.import.1c або REST. Збій у маппінгу властивостей інфоблоку — і на сайті товар без ціни або з нульовим залишком. Розсинхронізація замовлень — втрачені продажі.
- Оновлення ядра —
bitrix:main оновився, а кастомний компонент використовував deprecated-метод CModule::IncludeModule з нестандартними параметрами. Без регресії — російська рулетка.
- Мультибраузерність —
bitrix:sale.order.ajax рендерить форми по-різному в Safari і Chrome. Кнопка «Оформити замовлення» на iPhone може з'їхати за межі екрана.
Як функціональне тестування вирішує типові проблеми?
Перевіряємо кожен бізнес-сценарій. Не «працює-не працює», а всі граничні випадки.
Каталог (компоненти catalog.section, catalog.element)
- Розумний фільтр
catalog.smart.filter: усі комбінації властивостей, скидання, підрахунок результатів. Особливо — фільтри за торговими пропозиціями (SKU), вони ламаються найчастіше.
- Сортування + пагінація — той самий баг із дублями.
- Порівняння через
catalog.compare.list — додавання, видалення, відображення відмінностей.
- Швидкий перегляд — модальне вікно, кошик із модалки.
Кошик і замовлення (sale.basket.basket, sale.order.ajax)
- Додавання з каталогу, з картки, швидке замовлення.
- Знижки: за кількістю, за сумою, за купоном, за накопичувальною. Перетин знижок — окремий тест-кейс, мінімум 8 комбінацій.
- Розрахунок доставки: обробники
sale.delivery.services, вартість, терміни, ПВЗ на карті.
- Оплата:
sale.paysystem — проходження платежу, обробка відхилень, повернення.
- Формування замовлення: email через
main.mail.event, запис у CRM, передача в 1С через sale.export.1c.
Особистий кабінет (sale.personal.section)
- Реєстрація, авторизація, відновлення пароля — включно з edge-case із кириличним email.
- Історія замовлень, повторне замовлення.
- Підписки, бонусна програма.
Форми та пошук
-
form.result.new / iblock.element.add.form — відправка, валідація, файлові поля.
-
search.page — релевантність, морфологія, обробка помилок через search.title.
Регресійне тестування: як ми запобігаємо помилкам після оновлень
Після кожного деплою ми перевіряємо, чи не зламали те, що працювало.
- Smoke-тести — головна відкривається, каталог віддає товари, замовлення проходить до кінця. 5 хвилин, запускаємо після кожного деплою. Якщо smoke впав — відкочуємо, не розбираючись.
- Регресійний набір — 40–80 тест-кейсів за основними сценаріями. Перед кожним релізом.
- Візуальне тестування — порівняння скріншотів через Percy або Playwright. Кнопка з'їхала на 20px, шрифт змінився після оновлення — тест покаже diff.
- Чек-листи за модулями — структуровані списки для
sale, catalog, iblock, search. Кожен модуль — свій чек-лист.
Типовий набір регресійних тест-кейсів (скорочено)
- Головна сторінка: коректне відображення слайдера, категорій, блоку акцій.
- Каталог: фільтр без результатів, фільтр із однією властивістю, пагінація після зміни сортування.
- Картка товару: зміна кількості, різні торгові пропозиції, додавання в обране.
- Кошик: зміна кількості, видалення, застосування купона.
- Оформлення: успішна оплата, помилка оплати, повернення з помилкою.
Як визначити вузькі місця продуктивності магазину на Бітрікс?
Ми моделюємо навантаження, щоб зрозуміти, при якому RPS catalog.section почне віддавати 500-ку. Використовуємо реалістичні профілі на основі вашої аналітики.
Профіль навантаження для магазину на Бітрікс:
| Сценарій |
Частка |
Цільовий відгук |
Що ламається першим |
| Головна |
20% |
< 1 сек |
Композитний кеш, якщо не налаштований |
| Каталог із фільтрами |
30% |
< 2 сек |
MySQL — важкі JOIN по b_iblock_element_property |
| Картка товару |
25% |
< 1.5 сек |
Запити до торгових пропозицій |
| Додавання в кошик |
10% |
< 1 сек |
Блокування таблиці b_sale_basket |
| Оформлення замовлення |
5% |
< 3 сек |
Обробники доставки (зовнішні API) |
| Пошук |
10% |
< 2 сек |
b_search_content без індексів |
Інструменти: k6 (JavaScript-сценарії для кошика та чекауту), Apache JMeter (складні сценарії з cookie-авторизацією), Yandex.Tank (візуалізація в реальному часі). На виході — максимальний RPS, час відгуку за перцентилями p50/p95/p99, вузькі місця (CPU, RAM, MySQL slow queries на b_iblock_element, файловий кеш). Конкретні рекомендації: який індекс додати, який запит переписати на D7 ORM, де ввімкнути композитний кеш.
У проєкті з 100 000 товарами додавання індекса на b_iblock_element_property.IBLOCK_ELEMENT_ID скоротило час виконання фільтра з 8 секунд до 0.3 секунди — ми знайшли це саме під час навантажувального тестування.
Автоматизоване, кросбраузерне та приймальне тестування
Кросбраузерність перевіряємо там, де реально сидять покупці. Статистика з Метрики конкретного проєкту важливіша за загальноринкові дані. Мінімальний набір: Chrome (останні 2 версії), Safari на iOS, Яндекс.Браузер, Samsung Internet. Пристрої: Desktop 1920×1080 та 1366×768, iPhone 375×812 та 390×844 (обов'язково чекаут), Android 360×800 та 412×915. Інструменти: BrowserStack для реальних пристроїв, Playwright для автоматизації в Chromium/Firefox/WebKit.
Автоматизація базується на Playwright — кросбраузерність, паралельний запуск, автоматичні очікування, добре працює з динамічними формами sale.order.ajax. У порівнянні з ручним тестуванням, автоматизація скорочує час виконання регресії втричі. PHPUnit використовуємо для модульних тестів кастомних компонентів і бізнес-логіки — інтеграція з CI/CD (GitLab CI, GitHub Actions). Тестовий набір із 50 сценаріїв виконується за 15 хвилин замість годин ручної перевірки.
Фінальна перевірка (UAT) проводиться із замовником на staging з копією продової бази. Спільно складаємо 15–20 ключових шляхів покупця, фіксуємо баги в Jira/YouTrack, оформляємо протокол приймання.
QA-процес: як ми вбудовуємо тестування в розробку
Тестування не приклеюється наприкінці — воно стартує з аналізу вимог.
- Аналіз вимог — QA бере участь в обговоренні завдань, ловить неоднозначності. «Знижка застосовується до товару чи до замовлення?» — таке питання на старті економить два дні відладки.
- Тест-кейси до розробки — сценарії готові до першого рядка коду.
- Code review — перевірка на типові помилки Бітрікса: неочищений кеш компонентів, прямі SQL-запити замість ORM, відсутність перевірки
$USER->IsAuthorized().
- Функціональне → регресійне → деплой.
- Моніторинг після релізу — помилки в
bitrix/error.log, метрики в аналітиці, алерти по 500-м.
Закажіть тестування сьогодні — і ми підготуємо тест-план за 2 дні.
Терміни та вартість тестування
| Завдання |
Терміни |
| Тест-план |
2–3 дні |
| Функціональне тестування (середній магазин) |
3–5 днів |
| Базовий набір E2E-автотестів (Playwright) |
2–3 тижні |
| Навантажувальне тестування + звіт |
1–2 тижні |
| Кросбраузерне |
2–3 дні |
| UAT-супровід |
3–5 днів |
| QA-процес з нуля |
3–4 тижні |
Що входить у роботу: детальний тест-план із чек-листами за модулями, автоматизований набір E2E-тестів (Playwright/Cypress) під ваш стек, звіт із результатами, скріншотами помилок і рекомендаціями, інтеграція тестів у ваш CI/CD (GitLab CI, GitHub Actions, Bitbucket Pipelines), супровід UAT — до трьох ітерацій виправлень без додаткової оплати, документація процесу тестування для вашої команди.
Баг на продакшені — це не тільки вартість виправлення. Середнє виправлення критичного дефекту коштує від 20 000 грн, а втрати від зламаного кошика за вихідні на проєкті з оборотом 5 млн/міс можуть сягати 400 000 грн. Інвестиція в тестування — це страховка вашого бізнесу.
Зв'яжіться з нами, щоб отримати комерційну пропозицію та детальний план тестування для вашого проєкту.
