TL;DR
- Продуктовый AB-тест проверяет не "какой экран красивее", а влияет ли изменение на важную метрику без вреда для guardrails.
- В тесте заранее фиксируются гипотеза, аудитория, unit of randomization, exposure event, primary metric, guardrails и дата анализа.
- Нельзя останавливать тест только потому, что сегодня вариант B выглядит лучше.
- Продуктовые тесты должны смотреть дальше клика: activation, retention, revenue, support, crash rate, refund, fraud.
- Если трафика мало, лучше сделать качественное исследование, feature flag rollout или доработку воронки, чем запускать тест, который все равно ничего не докажет.
1. Что такое продуктовый AB-тест
AB-тест сравнивает две или больше версии опыта на сопоставимых группах пользователей. Контроль видит текущую версию, тестовая группа - изменение. Разница в метриках показывает, стоит ли раскатывать изменение дальше.
В продукте AB-тест отличается от рекламного сплит-теста. Здесь изменение может влиять на долгосрочное поведение: retention, повторные заказы, скорость приложения, support load, churn. Поэтому "клик вырос" - слабое доказательство, если через неделю пользователи хуже возвращаются.
2. Что фиксировать до запуска
Хороший test brief помещается на одну страницу.
| Поле | Пример |
|---|---|
| Гипотеза | Если показать шаблон onboarding, больше команд завершит первый workflow |
| Аудитория | Новые workspace в web app |
| Randomization unit | Workspace, не отдельный пользователь |
| Exposure event | onboarding_template_seen |
| Primary metric | first_workflow_completed_within_24h |
| Guardrails | Error rate, support tickets, D7 retention |
| Minimum runtime | 14 дней или полный недельный цикл |
| Decision rule | Ship, если primary растет и guardrails не падают |
Без такого brief команда почти всегда спорит постфактум: одни смотрят клики, другие revenue, третьи выбирают красивый сегмент, где результат "точно победил".
3. Unit of randomization
Нужно решить, кого вы рандомизируете.
| Unit | Когда подходит | Риск |
|---|---|---|
| User | Индивидуальный продукт | Один человек на нескольких устройствах |
| Device | Mobile/app тесты без login | Трудно связать с revenue |
| Account/workspace | B2B SaaS | Внутри аккаунта люди влияют друг на друга |
| Order/session | Checkout UX | Пользователь может попасть в разные варианты |
Для B2B SaaS часто нужно рандомизировать workspace, а не пользователя. Иначе один участник команды увидит новый onboarding, второй старый, а их поведение смешается.
4. Exposure важнее assignment
Пользователь может попасть в тестовую группу, но не увидеть изменение. Поэтому важно отличать assignment от exposure.
Если считать всех assigned users, результат размывается. Особенно это заметно в продуктах, где новая фича находится глубоко: например, виджет рекомендаций видят только те, кто дошел до карточки товара.
5. Primary metric и guardrails
Один тест должен иметь одну основную метрику. Остальные метрики помогают понять вред и контекст.
| Тип | Примеры |
|---|---|
| Primary | Activation, checkout conversion, first value, paid conversion |
| Secondary | Time to convert, feature adoption, repeat action |
| Guardrail | Crash-free users, refunds, support tickets, latency, unsubscribe |
| Diagnostic | Segment split, path after drop-off, device/app version |
Если тест улучшает primary metric на 4%, но увеличивает refund rate на 20%, это не победа. Это перенос проблемы в другое место P&L.
6. Статистика без магии
Команде не обязательно превращаться в кафедру статистики, но базовые правила нужны:
- заранее оценить sample size;
- не останавливать тест каждый день по настроению;
- не менять primary metric во время теста;
- проверять sample ratio mismatch;
- учитывать недельные циклы;
- отдельно смотреть новые и returning users, если опыт для них разный.
Sample Ratio Mismatch, или SRM, возникает, когда группы распределились не так, как ожидалось. Например, план был 50/50, а вышло 62/38. Это может быть признаком бага в assignment, фильтрах, eligibility или логировании. Такой тест нельзя спокойно интерпретировать.
7. Продуктовые тесты и долгий эффект
Некоторые фичи выигрывают быстро и проигрывают позже.
| Быстрый выигрыш | Долгий риск |
|---|---|
| Агрессивный paywall | Churn после trial |
| Скидка в checkout | Падение margin |
| Больше push-уведомлений | Unsubscribe и uninstall |
| Упрощенный KYC | Fraud и compliance |
| Автоподписка | Refunds и жалобы |
Поэтому для серьезных продуктовых изменений полезно смотреть не только same-day conversion, но и D7/D30 retention, revenue retention, support и качество заказов.
8. Rollout
AB-тест не обязан сразу запускаться на 50% аудитории. Часто безопаснее идти ступенями.
Порядок особенно важен для платежей, KYC, onboarding, рекомендаций, pricing и любых фич, где ошибка стоит денег или доверия.
9. Локальный контекст СНГ/РК
На локальном рынке часто встречается аргумент "у конкурента так сделано". Это не эксперимент. У конкурента другая аудитория, бренд, платежные привычки, доставка, support и технический долг.
Практичные тесты для РК:
| Продукт | Что тестировать | Guardrail |
|---|---|---|
| E-commerce | Порядок payment methods: Kaspi, card, installment | Paid orders, payment errors |
| EdTech | Первый урок до заявки или после заявки | Trial quality, refunds |
| Fintech | KYC flow and document hints | Approval rate, fraud, support |
| Delivery | Address flow and delivery fee display | Completed orders, cancellation |
| B2B SaaS | Template-based onboarding | Activation, support tickets |
Маленький рынок не отменяет эксперименты, но заставляет честнее относиться к мощности теста. Если аудитории мало, лучше выбрать крупное изменение с большим ожидаемым эффектом, а мелкие UI-споры решать через usability research.
10. Ошибки
| Ошибка | Последствие |
|---|---|
| Нет заранее записанной гипотезы | После теста выбирают удобную интерпретацию |
| Меняют primary metric в процессе | Результат превращается в подгонку |
| Смотрят только клики | Можно ухудшить retention или revenue |
| Нет guardrails | Рост покупается качеством |
| Не проверяют SRM | Баг assignment выглядит как эффект фичи |
| Слишком рано останавливают тест | Случайный шум принимается за победу |
| Тестируют много изменений сразу | Непонятно, что сработало |
11. Практический чеклист
- Есть test brief.
- Определены eligibility и randomization unit.
- Настроен exposure event.
- Выбрана одна primary metric.
- Добавлены guardrails.
- Понятен minimum runtime или sample size.
- Проверяется sample ratio mismatch.
- Результат анализируется по ключевым сегментам.
- После rollout есть мониторинг.
12. Видео
13. Главный совет
AB-тест нужен не для того, чтобы доказать правоту команды. Он нужен, чтобы дешево узнать, где команда ошибается. Самый полезный тест часто тот, который не дал раскатить красивую, но вредную фичу.
Sources / Notes
- Firebase: A/B Testing
- Firebase: Create Remote Config experiments
- Statsig: Managing Sample Ratio Mismatch
- Optimizely: Stats Engine