Как тестируешь гипотезу перед запуском A/B теста?

Pre-Test Validation: Тестирование гипотезы перед A/B тестом

Запуск A/B теста — это дорого (потеря revenue если неудачен, engineering effort, opportunity cost). Перед тем как запускать, мудро сначала валидировать гипотезу качественными методами.

Этап 1: Desk Research (без пользователей)

Анализ существующих данных:

Competitive analysis — что делают конкуренты?

• Имеют ли они похожую фичу?
• Как долго на рынке?
• Есть ли reviews или feedback о ней?

Industry benchmarks — какие показатели для похожих фич?

• Какой typical lift от такого change?
• Какой sample size обычно требуется?

Historical precedent — был ли похожий эксперимент раньше?

• Результаты и learnings
• Что отличается в текущей гипотезе?

Analytics audit — посмотрите на текущий funnel:

• Где сейчас находится bottleneck?
• Если добавить фичу, она помогает именно здесь?
• Есть ли другие factors которые можем address раньше?

Пример: "Хотим добавить cart reminder email. Текущий cart abandonment 60%. Но analytics показывает что главная проблема — product discovery (люди не находят нужный продукт). Email не решит эту проблему"

Этап 2: Qualitative Research (с пользователями)

User interviews (5-10 пользователей)

Цель: understand if problem is real и if proposed solution makes sense.

Вопросы:

• "Ты когда-нибудь сталкивался с [проблема]?"
• "Как часто это случается?"
• "Как ты сейчас решаешь эту проблему?"
• "Какое идеальное решение выглядит для тебя?"
• [покажите мокап] "Помогла бы это решение?"
• "Что тебе не нравится в этом варианте?"

Наблюдайте за реакцией:

• Энтузиазм или скептицизм?
• Какие parts нравятся, какие нет?
• Есть ли concerns?

Scoring: если 6+ из 10 говорят "точно буду использовать" — гипотеза достойна A/B теста.

Usability testing (5 пользователей на мокапе)

• Дайте пользователю прототип (figma, clickable wireframe)
• Попросите выполнить task: "Ты хочешь [goal], как ты это сделаешь?"
• Observe: делают ли они то что нужно? Интуитивно ли?
• Измеряйте: task completion rate, time to complete, error rate

Пример: тестируете новый checkout flow

• 5 пользователей
• 3 успешно завершили (60% completion rate)
• 2 были confused на шаге payment method
• Average time 2.5 min (vs 1.5 min в текущем)

Вывод: flow имеет issues, нужно доработать перед A/B тестом.

Survey (50-200 пользователей)

• Quick survey о проблеме и решении
• NPS-like вопрос: "Как вероятно вы будете использовать эту фичу?"
• Segmentation insights

Процент "очень вероятно" >60% = хороший сигнал.

Этап 3: Технический validation

Feasibility check:

• Может ли tech team реализовать за reasonable time?
• Есть ли technical debt/risk которые нужно address?
• Какой effort (story points)?

Performance impact:

• Будет ли страница медленнее?
• Увеличится ли load на database?
• Нужны ли новые infrastructure?

Если technical effort большой (> 3 недели), может быть лучше сначала улучшить более очевидные things.

Этап 4: Analytics readiness

Прежде чем запустить A/B тест, убедитесь что you can measure:

Инструменты:

• A/B testing platform (Optimizely, LaunchDarkly, custom)
• Analytics dashboard (Amplitude, Mixpanel, Google Analytics)
• Statistical calculator для sample size

Event tracking:

• Все нужные events залогированы?
• Correct parameters?
• Эта система работает стабильно?

Sample size calculation:

• Baseline conversion rate (берете из analytics)
• Minimum detectable effect (MDE): "Нам нужен lift минимум 10%, если меньше — не worth it")
• Desired significance level (95% confidence = p-value < 0.05)
• Power (80% обычно)

Пример:

• Baseline: 3% conversion
• MDE: 20% (хотим 3.6%)
• Significance: 95%
• Power: 80%
• Result: нужно 3,500 conversions на вариацию = 2+ недели traffic

Если sample size слишком большой (>4 недели) — гипотеза может быть не worth тестирования.

Этап 5: Competitive validation

Посмотрите как конкуренты тестировали:

• Есть ли case studies?
• Какие were learnings?
• Как они optimized решение?

Пример: Amazon тестировала 1-click checkout и got 15% lift. Но это потому что:

1. Большой volume (millions users)
2. Existing trust (люди уже знают Amazon)
3. Friction была реальной (checkout был 5 шагов)

Если ваш context отличается, результат может быть другим.

Этап 6: Success criteria finalization

После всех validation шагов, определите clear success criteria для A/B теста:

Primary metrics (мы хотим):

• Conversion rate +10%
• OR DAU +5%
• OR Revenue per user +8%

Secondary metrics (не должны упасть):

• Cart size не должен упасть
• Customer satisfaction score не должен упасть
• Load time не должен увеличиться >10%

Guard rails (красные флаги):

• Churn rate не должен подняться
• Error rate не должен возрасти
• Bounce rate не должен измениться >5%

Duration: 2 недели minimum (accounting for weekly seasonality)

Sample size: 3,500+ conversions на вариацию

Когда НЕ запускать A/B тест

• Qualitative research показала что мало кто заинтересован (<40%)
• Usability test имел <50% task completion
• Technical effort слишком большой для expected ROI
• Sample size требует >2 месяцев (слишком долго)
• Guard rail metrics уже violated (например, performance уже плохой)

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

Best Practices

Не влюбляйтесь в гипотезу — goal не доказать что вы правы, а узнать что work.

Документируйте pre-test findings: это baseline для понимания почему A/B тест showed X результат.

Обсудите с team — если Engineering или Data skeptical, слушайте. Иногда их insights спасают от плохих тестов.

Timing matters — не запускайте A/B тест перед праздником или сезонным event если это не related.

Тщательное pre-test validation экономит месяцы engineering effort и помогает сфокусироваться на гипотезах которые действительно имеют потенциал.