Генерация A/B-гипотез через Claude Code

Почему гипотезы важнее самих тестов

A/B-тестирование стоит времени и трафика: нужно дождаться статистической значимости, не сломать по дороге аналитику, не запускать пересекающиеся тесты. Если гипотеза слабая, вы тратите две недели, чтобы узнать, что синяя кнопка не хуже зелёной. Ценность даёт не механика теста, а качество идей на входе — тест лишь проверяет то, что вы придумали до него.

Хорошая гипотеза строится не «мне кажется», а на данных: где отваливаются пользователи, что чаще всего спрашивают в поддержке, какие возражения повторяются в отзывах. Проблема в том, что эти данные разбросаны — воронка в аналитике, жалобы в чате поддержки, инсайты в отзывах на маркетплейсе. Человек физически не держит всё это в голове одновременно и упускает закономерности. Claude Code читает эти источники разом и находит связи, которые глаз пропускает в сотне строк выгрузки.

Какие данные скормить модели

Чем богаче вход, тем содержательнее гипотезы. Собирать всё сразу не обязательно — начните с того, что уже есть под рукой, и дополняйте.

• Воронка. Конверсии по шагам из Яндекс.Метрики или аналитики — где именно просадка, между какими шагами теряете больше всего.
• Отзывы и поддержка. Что раздражает, что непонятно, на чём люди застревают. Это прямые подсказки, что чинить.
• Тепловые карты. Данные теплокарт и вебвизора: куда не доходит скролл, что кликают вместо кнопки, где мечется курсор.
• Тексты страницы. Заголовки, офферы, CTA — чтобы модель предлагала конкретные правки формулировок, а не абстракции.

Если данные лежат в базе или таблице, подключите их через MCP — тогда Claude Code опирается на живые цифры, а не на ваш пересказ. Даже минимального набора — воронка плюс отзывы — хватает, чтобы получить десяток обоснованных гипотез вместо фантазий про цвет кнопки.

Отдельно стоит дать модели контекст бизнеса: что вы продаёте, кому и какое действие считаете целевым. Без этого она предложит абстрактные «улучшить UX» и «добавить доверия». С контекстом — конкретику: «на шаге оплаты нет ни одного упоминания гарантии возврата, а в отзывах трижды спрашивали про это». Такая гипотеза уже готова к тесту, потому что опирается и на данные, и на понимание, что именно тревожит вашего клиента перед покупкой.

Промпт для генерации гипотез

Задача — получить не «10 идей», а структурированный список с обоснованием и ожидаемым эффектом. Форматируйте вывод так, чтобы его можно было сразу приоритизировать.

Прочитай funnel.csv, reviews.txt и landing.md в этой папке.

Найди 3 самых слабых места воронки по данным.
Для каждого предложи 3 A/B-гипотезы в формате:
- Что меняем (конкретно, на какой странице и в каком блоке)
- Гипотеза: «если ..., то [метрика] вырастет, потому что ...»
- Что измеряем (основная и вспомогательная метрика)
- Риск (что может пойти не так)

Сложи в hypotheses.md таблицей.

На выходе — не абстракции, а привязанные к вашим данным идеи: «переписать заголовок на странице цен, потому что в отзывах путают тарифы». Дальше можно уточнять: «сгенерируй ещё 5 гипотез только для мобильной версии — там просадка больше», «предложи три варианта формулировки для гипотезы №3». Модель работает с тем же файлом, а не начинает каждый раз с чистого листа.

Приоритизация по ICE

Гипотез всегда больше, чем ресурсов на тесты, а трафик ограничен — параллельно много не запустишь. Приоритет расставляют по фреймворку ICE: Impact (влияние на метрику), Confidence (насколько уверены), Ease (простота реализации). Попросите Claude Code проставить оценки по 10-балльной шкале и отсортировать.

ICE — среднее трёх оценок. Тестируем сверху вниз. Видно, что «упростить форму» уверенно бьёт «цвет кнопки», хотя цвет менять проще всего. Именно эту очередь и ломают команды без приоритизации: берут самое лёгкое, а не самое ценное, и месяцами не двигают метрику. Оценки субъективны, но даже грубая шкала дисциплинирует и не даёт хвататься за косметику вперёд смысла.

Как не испортить тест формулировкой

Даже сильная идея проваливается, если тест поставлен криво, — и вы сделаете неверный вывод. Проговорите с моделью базовые правила CRO, а лучше попросите проверить ваш план на эти ошибки.

• Одно изменение за раз. Поменяли и заголовок, и кнопку — не поймёте, что сработало, а что помешало.
• Заранее выбранная метрика. Нельзя менять цель после старта под удобный результат — это подгонка, а не тест.
• Достаточная выборка. На малом трафике «победа» часто случайность, которая не повторится.

Попросите Claude Code проверить план: «оцени, нет ли в этих трёх тестах пересечения аудиторий и хватит ли трафика при конверсии 3% и 2000 визитов в неделю». Модель прикинет, сколько теста надо держать до значимости, и укажет на конфликты — например, что два теста делят один и тот же трафик и испортят друг другу результат. Это дешевле, чем узнать про ошибку через две недели и запускать всё заново.

Обучение на результатах

Ценность системы — в накоплении знаний, а не в отдельном тесте. Заведите файл results.md и после каждого теста записывайте три строки: гипотеза, результат, вывод. Через квартал у вас база того, что работает именно на вашей аудитории, — а это дороже любого чужого чек-листа «10 приёмов CRO».

Проигравший тест — не потерянное время, а вычеркнутая гипотеза и новое знание об аудитории. По-настоящему проигрывают только незаписанные тесты: их результат забывается, и через полгода команда проверяет то же самое заново.

Claude Code помогает и здесь: «прочитай results.md за квартал и найди закономерности — какие типы изменений у нас чаще выигрывают, а какие стабильно не заходят». Модель обобщит десятки строк и подскажет, куда копать дальше: например, что правки в текстах офферов дают результат, а перестановки блоков — нет. Похожую логику разбирали в тексте про генерацию гипотез для CRO.

Как встроить в рутину

Чтобы поток гипотез не иссякал, сделайте это регулярной процедурой, а не подвигом раз в квартал. Раз в две недели: выгрузка свежих данных в папку, один промпт на генерацию, приоритизация по ICE, запуск топ-1–2 тестов. Полчаса вместо часового мозгового штурма, где половина идей — снова про цвет кнопок и «давайте добавим ещё один баннер».

Такой ритм меняет культуру: команда перестаёт спорить на вкус («мне кажется, так лучше») и начинает проверять гипотезы данными. Если хочется полной автоматизации, соберите под это отдельного агента, который сам подтягивает метрики и приносит готовые гипотезы к планёрке. Но для старта хватит папки, выгрузки и одного промпта — усложнять стоит, только когда простая версия уже приносит пользу.

Ещё один эффект регулярности — растёт скорость обучения команды. Каждый цикл вы не просто запускаете тест, а пополняете базу знаний об аудитории: что её убеждает, что отталкивает, какие формулировки работают. Через полгода такой практики вы принимаете решения по лендингу и офферам увереннее и быстрее, потому что за спиной десятки проверенных гипотез, а не догадки. Инструмент здесь — ускоритель цикла «гипотеза — тест — вывод», и чем чаще крутится этот цикл, тем дороже становится накопленное знание.