Перед выбором эксперимента сформулируйте симптом и предполагаемую причину. Например: «CAC вырос на 25% из-за падения conversion после клика» полезнее, чем «давайте протестируем новую рекламу». Библиотека помогает выбрать проверку для конкретного bottleneck, а не генерировать активность.
Каждый тест должен воздействовать на один или несколько drivers: traffic, conversion, AOV, activation, retention, win rate, price realization. Если вы не можете показать, где experiment находится в Revenue Tree или Profit Tree, его business relevance сомнительна.
Хорошая гипотеза содержит механизм: «если изменить X для сегмента Y, метрика Z изменится потому что…». Формулировка «новый лендинг повысит конверсию» слабая, потому что не объясняет, какая friction снимается.
У эксперимента должна быть одна основная метрика принятия решения. Secondary metrics помогают объяснить результат, но не должны позволять выбрать удобную победу постфактум.
Рост conversion может ухудшить margin, lead quality или returns. Guardrails предотвращают локальную оптимизацию, которая вредит бизнесу. Для pricing это churn/refund; для media — retained CAC; для CRM — complaints/unsubscribe.
User, session, account, geography, campaign, store или time period. Неправильная единица создаёт contamination: один B2B-account может попасть в control и treatment через разных contacts.
Определите baseline, minimum detectable effect, alpha/power или практический decision threshold. Не заканчивайте тест только потому, что dashboard на третий день показывает зелёную стрелку.
Эксперимент должен захватывать полный business cycle: weekday/weekend, sales cycle, trial period, repeat window. Для retention-test результат D7 не заменяет D30, если решение влияет на долгосрочную ценность.
Continuous peeking повышает вероятность ложной победы. Используйте заранее определённый horizon или sequential method, если умеете его корректно применять.
Post-hoc slices помогают находить hypotheses, но не превращайте случайную победу в одном из двадцати сегментов в доказанный effect. Такие findings становятся input для следующего теста.
Impact, Confidence, Ease/Effort полезны для сравнения, но score не заменяет strategy. Эксперимент на текущий bottleneck обычно важнее красивой идеи с высоким лёгким score.
Если команда запускает 30 tests одновременно, analysis и implementation становятся bottleneck. Лучше 5 качественных экспериментов с решениями, чем 30 незакрытых.
Напишите: «если primary metric растёт ≥8% без ухудшения guardrail, внедряем; если эффект 0–8%, повторяем/уточняем; если отрицательный — закрываем». Это снижает post-hoc рационализацию.
Очень маленький effect может быть статистически значимым на большом трафике, но не окупать implementation. И наоборот, большой бизнес-effect может быть важен даже при неполной статистической уверенности в ранней стадии — тогда нужен дополнительный тест.
Experiment win должен переводиться в revenue, contribution, CAC, LTV или productivity. Укажите expected annualized effect, но не экстраполируйте короткий test без учёта saturation и rollout.
A/B test на 10% traffic и full rollout — разные режимы. После внедрения отслеживайте, сохраняется ли effect, нет ли novelty effect и operational side effects.
Rejected hypothesis экономит деньги, если learning сохраняется. В registry фиксируйте не только «не сработало», а механизм: сегмент не увидел value, friction была другой, incentive привёл low-quality demand.
Не все вопросы требуют A/B. Message, JTBD, objections и early PMF часто быстрее проверяются interviews, prototypes, concierge tests. Библиотека включает и такие методы.
Broken checkout, неработающая форма, явная ошибка pricing — это bug, а не experiment. Исправляйте дефект и наблюдайте результат.
Согласие, privacy, deceptive UX и обязательные disclosure не являются зоной «проверим, что лучше конвертит». Guardrails бизнеса выше локальной conversion.
Еженедельно — running/blocked experiments. Ежемесячно — learnings и adoption. Ежеквартально — какие drivers тестировались, где evidence достаточно и какие hypotheses повторяются.
Команда видит рост CAC и собирается тестировать новые audiences. Revenue Tree показывает, что click→lead conversion упала после редизайна landing page, а media metrics стабильны. Вместо audience experiments команда запускает два CRO tests, восстанавливает conversion и только затем возвращается к channel scaling. Библиотека помогает тестировать ограничение, а не привычный инструмент.
Отрицательный результат не означает, что experiment был бесполезным. Проверьте три слоя: была ли hypothesis неверной, было ли изменение недостаточно сильным, и был ли design способен обнаружить meaningful effect. Если mechanism не подтверждается, закрывайте направление. Если execution слабая — тестируйте новую реализацию.
Failed — достаточно evidence, что ожидаемый effect отсутствует или отрицательный. Inconclusive — данных недостаточно, sample слишком мал, tracking сломан или experiment contaminated. Эти статусы нельзя смешивать: inconclusive требует решения о повторе, failed — learning и stop.
Критические результаты полезно повторять на другом периоде, сегменте или geography. Особенно это важно, если effect неожиданно большой. Replication снижает риск масштабировать случайность, novelty effect или сезонный всплеск.
Вместо двадцати несвязанных тестов группируйте experiments вокруг одной growth hypothesis. Например, «клиенты не понимают value» может породить message, proof, demo и offer tests. После 3–5 результатов вы получаете вывод о механизме, а не коллекцию локальных побед.
У hypothesis должен быть предел терпения. Если три качественных tests не показывают effect, а qualitative evidence тоже слабое, закройте тему. Иначе команда превращает experimentation в бесконечный поиск варианта, который случайно станет зелёным.
Experiment consumes traffic, budget, engineering, analyst и management attention. Сравнивайте не только expected upside, но и что вы не сможете протестировать в этот период. Это особенно важно для low-traffic products и длинного B2B sales cycle.
На квартал выберите 3–5 стратегических вопросов: какой segment сильнее, что ограничивает conversion, какой pricing model устойчив, что создаёт retention. Experiments становятся инструментами ответа на вопросы, а не автономным backlog.
Перед запуском ищите похожие historical experiments. Возможно, hypothesis уже проверялась, но result забыли. Сохраняйте screenshots, variants, SQL, sample и context — иначе через год тест невозможно интерпретировать.