Experimentation Playbook: как запускать 10 A/B-тестов в месяц соло-фаундеру
Что такое experimentation playbook для соло-фаундера?
Experimentation playbook для соло-фаундера — это структурированная система запуска A/B-тестов с высокой частотой: LLM-генерация гипотез, ICE-скоринг, обязательная документация до запуска и автоматизированный статистический анализ в PostHog или Statsig. При 10 тестах/месяц с win rate 20% фаундер получает 18–24 успешных оптимизации в год, которые дают кумулятивный рост 165% (1.05^20) — против практически нулевого эффекта при 1–2 тестах/месяц. Ключевой фактор — не инструменты, а дисциплина процесса: шаблонизация сокращает время на один тест с 45–90 до 15–20 минут.
TL;DR
- -10 A/B-тестов/месяц при win rate 20% дают 18–24 победы/год со средним приростом 5% каждая — кумулятивный рост 165% против практически нулевого при 1–2 тестах/месяц.
- -LLM-промпт генерирует 15 приоритизированных гипотез за один вызов; топ-10 по ICE-скорингу (Impact × Confidence × Ease) идут в работу текущего месяца.
- -Каждый эксперимент требует experiment doc с критериями решения, зафиксированными до запуска — без этого p-hacking практически неизбежен.
- -PostHog использует байесовскую статистику («вероятность 94.3%, что B лучше A») и допускает ежедневную проверку без инфляции ошибок первого рода; Statsig автоматически завершает тест при достижении значимости.
- -Месячный бюджет времени — 210 минут (3.5 часа): 60 мин на генерацию гипотез, 100 мин на два пакета по 5 запусков, 20 мин мониторинг, 30 мин анализ в конце месяца.
Эксперименты воспринимаются как привилегия команд из 10+ человек с выделенным data-аналитиком. Это не так. Один человек может запускать 10 полноценных A/B-тестов в месяц. Нужны три вещи: фреймворк генерации гипотез, шаблонизированный процесс и правильные инструменты. Статья описывает все три.
Почему 10 тестов в месяц, а не 2
Экспериментирование работает через объём. Один тест в месяц — это 12 гипотез в год. При среднем win rate 15–20% (норма для индустрии) получается 2 удачных теста за год. Два улучшения за 12 месяцев не дают кумулятивного эффекта.
10 тестов в месяц — 120 гипотез в год. При том же win rate — 18–24 победы. Каждая победа даёт 3–10% прирост метрики. 20 побед со средним приростом 5% — кумулятивный рост на 165% за год (1.05^20). Не линейный, а экспоненциальный.
Ключевое ограничение для соло-фаундера — время. На один эксперимент от гипотезы до анализа уходит 45–90 минут ручной работы, если процесс не шаблонизирован. С фреймворком — 15–20 минут. 10 тестов × 20 минут = 200 минут в месяц. Три с половиной часа. Остальное делают инструменты.
Фреймворк генерации гипотез
Главная ошибка — тестировать то, что “кажется правильным”. Интуиция соло-фаундера ценна, но предвзята. Систематическая генерация гипотез покрывает слепые зоны.
Четыре источника гипотез
1. Данные (количественный анализ). Воронка конверсии показывает, где теряются пользователи. Если 60% пользователей уходят на странице оплаты — это не “проблема UX”. Это конкретная точка для 3–5 гипотез: цена, способы оплаты, trust signals, упрощение формы, guest checkout.
2. Обратная связь (качественный анализ). Отзывы, саппорт-тикеты, записи сессий (Hotjar, PostHog Recordings). Один паттерн жалоб = одна гипотеза. “Не понимаю, за что плачу” — гипотеза о ценностном предложении на странице pricing.
3. Конкуренты. Не копирование, а систематический анализ. Конкурент добавил social proof на лендинг — гипотеза: добавление отзывов на главную увеличит конверсию в регистрацию на X%.
4. LLM-ассистент. Промпт ниже генерирует 10–15 гипотез за один вызов. Фильтровать по ICE-скорингу.
Промпт для генерации гипотез
Контекст:
- Продукт: [описание продукта, целевая аудитория]
- Текущие метрики: [конверсия регистрации X%, activation rate Y%, churn Z%]
- Последние 3 теста: [краткие результаты]
- Известные проблемы: [из аналитики и фидбека]
Задача: Сгенерируй 15 гипотез для A/B-тестов.
Формат каждой гипотезы:
1. Гипотеза: "Если [изменение], то [метрика] изменится на [ожидаемый эффект], потому что [обоснование]"
2. Метрика: основная метрика для измерения
3. ICE Score: Impact (1-10), Confidence (1-10), Ease (1-10), Total
4. Минимальный размер выборки для обнаружения эффекта
Требования:
- Разнообразие: покрой онбординг, activation, retention, monetization, referral
- Не менее 5 гипотез с Ease >= 7 (реализуемых за 1-2 часа)
- Укажи, какие гипотезы противоречат друг другу
Результат — приоритизированный список. Верхние 10 по ICE-скорингу идут в работу. Оставшиеся — в backlog на следующий месяц.
ICE-скоринг: быстрая приоритизация
| Параметр | Что оценивает | Пример (высокий балл) |
|---|---|---|
| Impact | Потенциальный эффект на метрику | Изменение главного CTA — высокий |
| Confidence | Уверенность в результате | Есть данные, подтверждающие проблему — высокий |
| Ease | Простота реализации | Изменение текста кнопки — высокий |
Total = (I + C + E) / 3. Тесты с Total >= 7 запускать немедленно. 5–7 — в текущий спринт. Ниже 5 — backlog.
Шаблон Experiment Doc
Каждый эксперимент документируется до запуска. Без документа нет эксперимента. Это не бюрократия — защита от подгонки результатов (p-hacking) и потери контекста.
# Experiment: [EXP-2026-03-001] [Название]
## Гипотеза
Если [конкретное изменение], то [метрика] увеличится/уменьшится на [X%],
потому что [обоснование на основе данных или качественного анализа].
## Метрики
- Primary: [одна метрика, по которой принимается решение]
- Secondary: [1-2 метрики для контроля побочных эффектов]
- Guardrail: [метрика, которая НЕ должна ухудшиться]
## Дизайн
- Тип: A/B | A/B/C | feature flag
- Аудитория: [все пользователи | новые | сегмент]
- Распределение: [50/50 | 90/10]
- Длительность: [7-14 дней или до набора N событий]
- Минимальный размер выборки: [рассчитать до запуска]
## Варианты
- Control (A): [текущее поведение]
- Treatment (B): [что меняется, скриншот или описание]
## Критерии решения (зафиксировать ДО запуска)
- Ship (B wins): primary metric + X% при p < 0.05
- Kill (B loses): primary metric - Y% или guardrail degraded
- Inconclusive: недостаточно данных → продлить или увеличить трафик
## Результаты (заполнить после)
- Дата начала / Дата окончания:
- Размер выборки: Control N / Treatment N
- Primary metric: Control X% → Treatment Y% (delta Z%, p-value, CI)
- Решение: Ship / Kill / Iterate
- Выводы: [что узнали, даже если тест провалился]
Критически важный раздел — “Критерии решения”. Он фиксируется до запуска теста. Без него возникает соблазн “подвинуть” порог после получения данных.
Статистика A/B-тестов: минимум для принятия решений
Размер выборки
Формула: n = (Z_{α/2} + Z_β)² × 2 × p(1-p) / δ²
Где:
- p — текущая конверсия (например, 5%)
- δ — минимальный детектируемый эффект (MDE), например 1 п.п.
- Z_{α/2} = 1.96 (для α = 0.05)
- Z_β = 0.84 (для power = 80%)
Практическая таблица:
| Базовая конверсия | MDE (абсолютный) | Выборка на вариант |
|---|---|---|
| 2% | 0.5 п.п. | 12 500 |
| 5% | 1 п.п. | 3 800 |
| 10% | 2 п.п. | 1 900 |
| 20% | 3 п.п. | 1 400 |
| 50% | 5 п.п. | 770 |
Для продукта с 100 DAU набрать 3 800 событий на вариант = 38 дней при 50/50 сплите. Это реальность маленького продукта. Два выхода: увеличить MDE (ловить только крупные эффекты) или использовать sequential testing.
Sequential testing vs. fixed-horizon
Fixed-horizon: определить размер выборки заранее, ждать полного набора, анализировать один раз. Классический подход, надёжный, но медленный.
Sequential testing: анализировать результаты по мере поступления данных с поправкой на множественные сравнения. PostHog и Statsig поддерживают этот подход из коробки. Тест, который при fixed-horizon шёл бы 30 дней, можно остановить на 15-м дне, если эффект достаточно сильный.
Ошибки, которые убивают валидность
Подглядывание (peeking). Проверять результаты каждый день и останавливать тест при первом p < 0.05 — гарантированный способ получить ложноположительный результат. При α = 0.05 и ежедневной проверке за 14 дней реальный false positive rate вырастает до 25–30%. Sequential testing решает эту проблему математически.
Множественные метрики. Тест с 10 метриками при α = 0.05 даёт хотя бы один “значимый” результат с вероятностью около 40% просто по случайности. Поправка Бонферрони: делить α на количество метрик. Или, проще, зафиксировать одну primary metric.
Недостаточная длительность. Минимум — один полный бизнес-цикл. Для B2C SaaS это 7 дней (разница между буднями и выходными). Для B2B — 14 дней (разная активность в начале и конце месяца).
PostHog: настройка экспериментов с нуля
PostHog — open-source платформа для продуктовой аналитики и A/B-тестирования. Бесплатный план покрывает до 1 млн событий в месяц. Для соло-фаундера на ранней стадии этого достаточно.
Интеграция за 10 минут
// posthog-js — клиентская библиотека
import posthog from 'posthog-js'
posthog.init('phc_YOUR_KEY', {
api_host: 'https://app.posthog.com',
autocapture: true, // автоматический трекинг кликов, pageviews
capture_pageview: true,
capture_pageleave: true,
persistence: 'localStorage'
})
Autocapture собирает базовые события без дополнительного кода. Для A/B-тестов нужны кастомные события на ключевых точках воронки:
// Регистрация
posthog.capture('user_signed_up', {
method: 'email', // или 'google', 'github'
source: 'landing_page'
})
// Активация (пользователь сделал ключевое действие)
posthog.capture('activation_completed', {
time_to_activate_seconds: 340,
steps_completed: 3
})
// Конверсия в платную подписку
posthog.capture('subscription_started', {
plan: 'pro',
price: 29,
trial_days: 14
})
Создание эксперимента в PostHog
PostHog использует feature flags как основу для экспериментов. Процесс:
- Создать feature flag с вариантами (control + treatment)
- Привязать flag к эксперименту
- Указать целевую метрику и минимальный размер выборки
- Запустить
// В коде проверяем вариант:
if (posthog.getFeatureFlag('exp-new-pricing-page') === 'test') {
renderNewPricingPage()
} else {
renderCurrentPricingPage()
}
// PostHog автоматически трекает exposure:
// событие $feature_flag_called с payload {flag: 'exp-new-pricing-page', variant: 'test'}
PostHog рассчитывает статистическую значимость автоматически. Dashboard эксперимента показывает: конверсию по вариантам, credible interval (байесовский подход), рекомендацию (ship / continue / discard).
Байесовский подход PostHog
PostHog не использует p-values. Вместо этого — байесовская статистика. Результат выглядит так: “Вероятность, что вариант B лучше A — 94.3%”. Порог для принятия решения — 95% (настраивается).
Байесовский подход интуитивно понятнее (“вероятность 95%, что B лучше”) и менее подвержен peeking problem. Можно проверять результаты каждый день без инфляции ошибок первого рода.
Statsig: для тех, кому нужна скорость
Statsig — managed платформа для экспериментов. Бесплатный план: до 500 000 событий в месяц и до 10 одновременных экспериментов. Главное преимущество перед PostHog — скорость настройки и автоматическое завершение тестов.
Отличия от PostHog
| Параметр | PostHog | Statsig |
|---|---|---|
| Хостинг | Self-hosted или Cloud | Cloud only |
| Статистика | Байесовская | Frequentist + sequential |
| Автоматическое завершение | Нет | Да (при достижении significance) |
| Warehouse-native | Нет | Да (Snowflake, BigQuery, Redshift) |
| Open source | Да | Нет |
| Бесплатный план | 1M событий | 500K событий |
Statsig автоматически останавливает эксперимент при достижении статистической значимости. Для соло-фаундера, у которого нет времени ежедневно проверять дашборды, это критично. Настроил, забыл, получил уведомление с результатом.
Интеграция Statsig
import statsig from 'statsig-js'
await statsig.initialize('client-YOUR_KEY', {
userID: user.id,
email: user.email,
custom: { plan: user.plan, signup_date: user.created_at }
})
// Проверка варианта
const experiment = statsig.getExperiment('new_onboarding_flow')
const variant = experiment.get('variant', 'control')
if (variant === 'streamlined') {
renderStreamlinedOnboarding()
} else {
renderCurrentOnboarding()
}
// Логирование события
statsig.logEvent('onboarding_completed', null, {
steps_shown: 3,
time_seconds: 180
})
Warehouse-native эксперименты
Statsig Warehouse Native запускает статистический анализ прямо на данных в Snowflake/BigQuery. События не нужно отправлять в Statsig — они остаются в хранилище, Statsig подключается и считает результаты.
Для соло-фаундера с существующей аналитикой в BigQuery это устраняет дублирование данных. Feature flags по-прежнему через Statsig SDK, а метрики — из собственного хранилища.
Процесс: 10 тестов за 3.5 часа в месяц
Неделя 1: генерация и приоритизация (60 минут)
- Собрать данные за прошлый месяц: воронка, retention, фидбек (20 мин)
- Запустить LLM-промпт для генерации гипотез (10 мин)
- ICE-скоринг: оценить каждую гипотезу (15 мин)
- Выбрать топ-10, заполнить experiment docs (15 мин)
Неделя 1-2: запуск (50 минут)
5 тестов × 10 минут на настройку feature flag и события. Параллельный запуск нескольких тестов допустим, если аудитории не пересекаются или тесты затрагивают разные части продукта. PostHog и Statsig поддерживают mutual exclusion groups — гарантию, что один пользователь попадает только в один эксперимент.
Неделя 2-3: мониторинг (20 минут)
Два чекпоинта: на 7-й и 14-й день. Проверить: нет ли багов (нулевые конверсии = сломанный вариант), guardrail-метрики в норме, набирается ли выборка. Решений по результатам не принимать.
Неделя 3-4: запуск второй пачки (50 минут)
Ещё 5 тестов по аналогичной схеме.
Конец месяца: анализ и документация (30 минут)
Закрыть завершённые тесты. Заполнить раздел “Результаты” в experiment docs. Ship победителей. Перенести inconclusive тесты в backlog. Обновить базу знаний: что работает, что нет, какие паттерны повторяются.
Итого: 210 минут = 3.5 часа в месяц
При 10 тестах это 21 минута на тест от идеи до результата. Основная экономия — шаблоны (experiment doc заполняется за 2 минуты) и автоматизация (инструменты считают статистику).
Связка с observability
Эксперименты генерируют данные. Данные требуют наблюдаемости. Если продукт использует LLM-вызовы (чат-бот, AI-фичи), результаты A/B-тестов нужно коррелировать с качеством LLM-ответов. Пользователь получил плохой ответ от модели в варианте B — конверсия упала не из-за дизайна, а из-за деградации модели.
LLM observability через Langfuse решает эту задачу: трейсы LLM-вызовов размечаются feature flag вариантом, и на дашборде видно качество ответов по каждому варианту эксперимента.
Автоматизация: experiment pipeline
Для масштабирования за пределы 10 тестов нужен pipeline. Минимальная автоматизация:
Notion/Linear (backlog гипотез)
↓ ICE score > 7
PostHog/Statsig (feature flags + experiments)
↓ автоматический анализ
Slack/Telegram notification (результат готов)
↓ решение: ship/kill
Feature flag → permanent / removed
↓ документация
Experiment doc → обновлён
Statsig отправляет webhook при завершении эксперимента. PostHog интегрируется со Slack. Уведомление приходит само. Соло-фаундер открывает дашборд, видит результат, принимает решение за 2 минуты.
Типичные ошибки и как их избежать
Тестировать мелочи. Цвет кнопки, размер шрифта, placeholder в поле ввода. Эти изменения дают эффект менее 1%, который невозможно обнаружить при маленьком трафике. Тестировать нужно структурные изменения: другой онбординг, другая модель ценообразования, другой value proposition.
Запускать без минимальной выборки. Тест с 50 пользователями на вариант не покажет ничего, кроме шума. Рассчитать минимальный размер выборки до запуска. Если трафика не хватает — укрупнить MDE или отказаться от теста в пользу качественного исследования (интервью, юзабилити-тест).
Не документировать проигравшие тесты. Тест, который “не сработал”, содержит информацию. Документация проигравших тестов предотвращает повторение одних и тех же гипотез и формирует базу знаний о том, что не влияет на пользователей.
Останавливать тесты раньше времени. “Уже видно, что B лучше” на третий день — это шум, не сигнал. Дождаться минимальной выборки или использовать sequential testing.
Запускать эксперимент без guardrail-метрики. Увеличение конверсии в регистрацию бесполезно, если retention упал на 20%. Guardrail-метрика защищает от оптимизации одной метрики за счёт другой.
Чеклист для запуска
Перед каждым экспериментом:
- Experiment doc заполнен (гипотеза, метрики, критерии решения)
- Минимальный размер выборки рассчитан
- Primary metric одна
- Guardrail-метрика определена
- Feature flag настроен и протестирован (обе ветки работают)
- События трекаются корректно (проверить в debug mode)
- Критерии решения зафиксированы до запуска
- Длительность — минимум один полный бизнес-цикл
Десять экспериментов в месяц — не подвиг и не хак роста. Это дисциплина: фреймворк генерации гипотез, шаблон документации, два инструмента и три с половиной часа в месяц. Результат — данные вместо интуиции, кумулятивный рост вместо разовых всплесков.
Нужна помощь с запуском экспериментов? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.
FAQ
Как запускать A/B-тесты при продукте с менее чем 500 DAU?
При менее 500 DAU стандартная статистическая значимость требует месяцев на один тест, что лишает смысла весь процесс. Два практических решения: во-первых, поднять Minimum Detectable Effect до 10–20% (тестировать только изменения, способные дать большой эффект — структурные изменения онбординга, лейаут страницы с ценами, основной CTA). Во-вторых, перейти на байесовский sequential testing в PostHog, который при низком трафике обнаруживает достаточно сильный сигнал за 7–14 дней. Третий вариант: заменить A/B-тесты качественными исследованиями (интервью, записи сессий) до набора трафика — usability-тест с 5 пользователями часто даёт больше, чем статистически мощностно-недостаточный эксперимент.
Можно ли запускать A/B-тесты на одних и тех же пользователях в нескольких экспериментах одновременно?
Да, но с одной критической защитой: эксперименты не должны взаимодействовать. PostHog и Statsig поддерживают mutual exclusion groups — механизм, гарантирующий, что один пользователь попадает только в один эксперимент одновременно. Без mutual exclusion пользователь, одновременно участвующий в «новом онбординге» и «новой странице с ценами», создаёт interaction effects, которые искажают оба результата. Практическое правило: тесты на разных страницах или функциях без пересечения пользовательского пути можно запускать параллельно; тесты, использующие один и тот же user flow, должны быть последовательными или использовать mutual exclusion.
В чём разница между guardrail-метрикой и secondary-метрикой в experiment doc?
Secondary-метрика отслеживает потенциальные побочные эффекты, которые интересны, но не используются для решения ship/kill (например, время сессии при тестировании конверсии регистрации). Guardrail-метрика — жёсткое ограничение: если она ухудшается сверх порога, эксперимент останавливается независимо от результата primary-метрики. Например, тест, поднявший конверсию регистрации на 15%, но снизивший 7-дневный retention на 25%, будет убит guardrail-метрикой. Secondary-метрики формируют гипотезы для следующих тестов. Guardrail-метрики защищают бизнес от локально позитивной, но глобально деструктивной оптимизации.