A/B-тестування сайту: налаштування інструментів та експерименти

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
A/B-тестування сайту: налаштування інструментів та експерименти
Середній
від 1 дня до 3 днів

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1364
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    960
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1191
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    933
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    950

Нещодавно клієнт переробив checkout — конверсія впала на 20%. Ми запустили A/B-тест, який показав, що старий варіант працював краще на 15%. Це коштувало б бізнесу мільйони при повному впровадженні. Nielsen Norman Group стверджує, що 73% тестів зупиняють раніше часу. Метод A/B-тестування описаний у Вікіпедії — це єдиний спосіб приймати дизайнерські рішення на основі даних, а не інтуїції. За час роботи ми провели понад 200 експериментів для інтернет-магазинів, лендингів та SaaS-продуктів. Середній приріст конверсії становив 15–30%. Деякі тести приносили значний додатковий прибуток.

Без A/B-тестів кожна зміна — лотерея. Один наш клієнт витратив значний бюджет на новий дизайн головної, який просів на 8%. Тест показав би це за 2 тижні, не витрачаючи бюджет. Наприклад, спліт-тестування дозволяє порівнювати варіанти з точністю до 95% довірчого інтервалу. Економія бюджету на тестуванні може скласти до 500 000 грн на рік.

Припустимо, ви змінюєте лендинг без тесту. Якщо конверсія падає на 10%, при 1000 відвідувачів на день це 100 втрачених лідів. За місяць — втрати суттєві. Вартість тесту розраховується індивідуально.

Які проблеми вирішує A/B-тестування?

Часто команди впевнені, що новий дизайн або CTA покращать конверсію, але статистика показує зворотне. Наприклад, ми тестували зміну кольору кнопки — очікували зростання на 20%, а отримали падіння на 5%. Технічні помилки теж трапляються: неправильна сегментація користувачів, витік даних між варіантами, некоректний трекінг. Одного разу ми виявили, що через невірну реалізацію 30% користувачів потрапляли в обидва варіанти — тест довелося перезапускати. І класична пастка — передчасна зупинка тесту, коли різниця здається очевидною, але вибірка ще не набрана. За даними Nielsen Norman Group, 73% тестів зупиняють раніше часу, що призводить до хибних висновків.

Як ми це робимо

Кожен експеримент проходимо за схемою: аналітика → проектування → реалізація → трекінг → аналіз. Використовуємо сучасний стек: React 18, Next.js 14, TypeScript, Node.js, Docker. Для зберігання даних — PostgreSQL і Redis. Growthbook дозволяє ітерувати гіпотези в 3 рази швидше порівняно з VWO: ви пишете логіку на клієнті або сервері, а не через візуальний редактор. Наш підхід зменшує час налаштування тесту в 2 рази порівняно з традиційними методами.

Реалізація через Vercel Edge Middleware

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

const EXPERIMENT_COOKIE = 'exp_checkout_v2';
const VARIANTS = ['control', 'variant-a', 'variant-b'];

function assignVariant(): string {
  const rand = Math.random();
  if (rand < 0.34) return 'control';
  if (rand < 0.67) return 'variant-a';
  return 'variant-b';
}

export function middleware(request: NextRequest) {
  const response = NextResponse.next();

  // Не беруть участь: боти, вже призначені користувачі
  const existing = request.cookies.get(EXPERIMENT_COOKIE)?.value;
  if (existing && VARIANTS.includes(existing)) {
    return response;
  }

  const variant = assignVariant();
  response.cookies.set(EXPERIMENT_COOKIE, variant, {
    maxAge: 60 * 60 * 24 * 30, // 30 днів
    httpOnly: true,
    sameSite: 'lax',
  });

  // Variant передаємо в заголовку для Server Components
  response.headers.set('x-ab-checkout', variant);
  return response;
}

export const config = {
  matcher: ['/checkout/:path*'],
};
// app/checkout/page.tsx
import { cookies, headers } from 'next/headers';

export default function CheckoutPage() {
  const variant = headers().get('x-ab-checkout') ??
                  cookies().get('exp_checkout_v2')?.value ??
                  'control';

  return (
    <>
      {variant === 'control' && <CheckoutV1 />}
      {variant === 'variant-a' && <CheckoutV2OneStep />}
      {variant === 'variant-b' && <CheckoutV2TwoStep />}
      <ABTracker experiment="checkout_v2" variant={variant} />
    </>
  );
}

Трекінг результатів

// components/ABTracker.tsx (Client Component)
'use client';

import { useEffect } from 'react';

export function ABTracker({ experiment, variant }: {
  experiment: string;
  variant: string;
}) {
  useEffect(() => {
    gtag('event', 'experiment_impression', {
      experiment_id: experiment,
      variant_id: variant,
    });
    posthog.capture('$experiment_started', {
      '$experiment_id': experiment,
      '$variant_key': variant,
    });
  }, [experiment, variant]);

  return null;
}

// Трекінг конверсії — в момент покупки
function trackConversion(variant: string) {
  gtag('event', 'purchase', {
    experiment_id: 'checkout_v2',
    variant_id: variant,
    value: orderTotal,
  });
}

Statsig: швидка інтеграція

// Statsig SDK (серверна та клієнтська частини)
import Statsig from 'statsig-node';

await Statsig.initialize(process.env.STATSIG_SERVER_KEY!);

// В API route / Server Action
const experiment = Statsig.getExperiment(
  { userID: userId, email: userEmail },
  'checkout_redesign'
);
const checkoutLayout = experiment.get('layout', 'single-page');
const ctaColor = experiment.get('cta_color', 'blue');

// Клієнтська сторона (React SDK)
import { useExperiment } from 'statsig-react';
function PricingCTA() {
  const { config } = useExperiment('pricing_cta');
  const buttonText = config.get('button_text', 'Get Started');
  const buttonVariant = config.get('button_variant', 'primary');
  return (
    <Button variant={buttonVariant} onClick={() => {
      statsig.logEvent('cta_clicked', buttonText);
    }}>
      {buttonText}
    </Button>
  );
}

Чому статистична значущість критична?

Без неї ви ризикуєте прийняти випадкове коливання за перемогу. Перед запуском розраховуємо необхідну вибірку. Наприклад, для конверсії 5% і очікуваного покращення 10% потрібно 6 500 користувачів на варіант — це 2-3 тижні трафіку для середнього сайту. Один із наших клієнтів отримав зростання конверсії на 35% завдяки тесту кнопки CTA за 14 днів.

Детальніше про розрахунок вибірки
from statsmodels.stats.power import zt_ind_solve_power

baseline_rate = 0.03
expected_effect = 0.15
lift = baseline_rate * expected_effect

n = zt_ind_solve_power(
    effect_size=lift / (baseline_rate * (1 - baseline_rate)) ** 0.5,
    alpha=0.05,
    power=0.8,
)
print(f"Sample size per variant: {int(n)}")  # ~12,000

Правило: не зупиняти тест раніше запланованого розміру вибірки, навіть якщо результати виглядають добре.

Порада: не заглядайте в результати щодня — це спотворює статистику. Автоматично рахуйте p-value і зупиняйте тест тільки при досягненні запланованої вибірки. Використовуйте sequential testing, якщо потрібні проміжні рішення.

Як обрати інструмент для A/B-тестування?

Інструмент Тип Найкращий для
Growthbook Open source / SaaS Технічні команди, self-hosted
Statsig SaaS Швидкий старт, інтеграція з аналітикою
Optimizely Enterprise SaaS Великі компанії, складні експерименти
VWO SaaS Маркетингові команди без dev
Vercel Edge Experiments PaaS Next.js на Vercel
Власна реалізація - Повний контроль, мінімальний overhead

Які метрики відстежувати в A/B-тесті?

Метрика Тип Приклад
Первинна (Primary) Цільова дія Конверсія в покупку, реєстрація
Вторинна (Secondary) Залученість Час на сайті, перегляд сторінок
Бізнесова (Business) Дохід, LTV Середній чек, повернення
Побічна (Guardrail) Ризик Відмови, помилки

Усі метрики мають бути задані до старту експерименту. Відстежуйте їх в GA4: використовуйте events experiment_impression та experiment_conversion.

Що входить в роботу

  • Налаштування інструменту A/B-тестування під ваш стек (Growthbook, Statsig, VWO, Optimizely або custom).
  • Реалізація розподілу варіантів на backend/edge з гарантією консистентності.
  • Інтеграція трекінгу подій в GA4, PostHog, Amplitude.
  • Розрахунок необхідного розміру вибірки та тривалості тесту.
  • Документація результатів та рекомендації щодо подальших експериментів.
  • Навчання команди: як запускати тести та інтерпретувати результати.

Процес роботи

  1. Аналітика: вивчаємо поточні метрики, виявляємо вузькі місця, формулюємо гіпотезу.
  2. Проектування: обираємо інструмент, визначаємо варіанти та метрики успіху.
  3. Реалізація: інтегруємо розподіл та трекінг, налаштовуємо дашборди.
  4. Запуск: починаємо тест, контролюємо коректність даних.
  5. Аналіз: після набору вибірки — статистична перевірка, формування звіту.

Терміни: від 2 до 4 робочих днів на простий тест, 5–10 днів на комплексний з кастомною логікою. Вартість розраховується індивідуально. Ми пропонуємо налаштування під ключ за 2–4 дні. Наша команда має 5+ років досвіду та реалізувала понад 200 експериментів. Оцініть вартість вашого проекту — напишіть нам для консультації щодо вибору інструменту та проведення експериментів.

Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude

Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.

Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.

Чому події GA4 дублюються і як це виправити?

Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.

Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.

Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.

Як налаштувати data layer, щоб не втратити дані?

GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Назва товару',
      price: null,
      currency: null
    }]
  }
});

Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.

Як Яндекс.Метрика доповнює веб-аналітику?

Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.

Що дає product analytics в Amplitude?

Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.

Моніторинг якості даних

Аналітика без моніторингу — чорна скринька. Налаштовуємо:

  • GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
  • Alerting в GA4 — аномалія в кількості подій purchase (різке падіння = щось зламалося)
  • GTM Preview в staging-оточенні перед продакшеном
  • Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається

Якщо ви помітили розбіжності в даних — зв'яжіться, проведемо безкоштовний аудит коректності тегів.

Що перевіряємо після кожного деплою

  • Чи всі рекомендовані події присутні в DebugView
  • Чи немає задвоєнь (рахуємо кількість purchase на 100 сесій)
  • Чи не змінилася структура dataLayer після оновлення фронтенду

Що входить в роботу

Компонент Опис
Аудит поточних тегів Перевірка існуючих GTM-тегів, dataLayer, дублів та помилок
Дизайн подієвої схеми Документація: список подій, параметри, тригери
Налаштування GA4 + GTM Створення конфігурації, тегів, Custom definitions
Яндекс.Метрика Встановлення лічильника, створення цілей, налаштування Вебвізора
Amplitude (опціонально) Налаштування клієнтського та серверного SDK, когорти
QA та моніторинг Тестування в Preview Mode, Alerting
Навчання та передача Доступи, інструкція з додавання нових подій, консоль

Процес та терміни

  1. Аудит поточних тегів та даних (2 дні)
  2. Дизайн подієвої схеми (2 дні)
  3. Розробка Data Layer та налаштування тегів (3–5 днів)
  4. QA в Preview Mode та на staging (2 дні)
  5. Деплой та налаштування дашбордів (1 день)
Сценарій Термін
Базове налаштування GA4 + GTM 1 тиждень
Повний e-commerce tracking + Метрика 2–3 тижні
Server-side GTM + Amplitude 3–5 тижнів

Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.