К предыдущему посту... 🚩 Риски и митигация. Риск 1. p value>α. Даже при α = 5% сохраняется риск ложноположительного результата (вер-ть подумать, что эффект есть, хотя его нет), мощность 80%, β=20% (вер-ть не заметить реальный эффект). Митигация: - Корректируем параметры эксперимента: α<>5%, MDE<>1 п.п, размер выборки. - Если A/B надо ускорить - CUPED, Multi-CUPED (для снижения дисперсии от 13% до 4x!). - Если A/B не "потянули" (мало трафика, времени или нельзя корректно засплитовать), смотрим корреляцию через прокси, делаем шаг назад, пробуем switchback-тестирование (сплит не пользователей, а времени), используем квазиэкспериментальные подходы, выбирая тест под вопрос, который хотим задать данным: 🔘 Если важно изменение среднего значения метрики (ARPU, время в продукте), то t-test: проверяем разницу средних; 🔘 Если важно изменение распределения, то U-критерий Манна–Уитни: проверяем сдвиг распределения через ранги; 🔘 Для метрик типа "да / нет" (например, купил / не купил, кликнул / не кликнул) - критерий χ² Пирсона: проверяет, настоящая ли разница в процентах между группами или это просто случайный шум; 🔘 Если нельзя сплитовать пользователей: 🔘🔘 Diff-in-Diff / Causal Impact - эффект до/после с контролем трендов; 🔘🔘 Propensity Score Matching - это способ "задним числом" сделать группы похожими, как будто мы их честно разделили в A/B-тесте. Например: сравниваем пользователей, которым показали новую фичу, с теми, кому не показали. Мы подбираем каждому пользователю из теста «похожего близнеца» из контроля (по возрасту, активности, чекам и т.д.), чтобы сравнение было честным.; 🔘🔘 Regression Discontinuity - это способ оценить эффект фичи, когда она включается по чёткому порогу. Например: всем пользователям с рейтингом выше 4.5 показываем новую функцию, а ниже — нет. Мы сравниваем тех, кто находится прямо рядом с этим порогом (4.49 vs 4.51). Они почти одинаковые, поэтому разница в метриках рядом с границей и есть оценка эффекта фичи. Иногда полезно сделать шаг назад и проверить ценность через продуктовые методы, например Conjoint-анализ. Риск 1.1. Подглядывание и множественные проверки. Если в процессе A/B-теста регулярно смотреть на p-value и останавливать эксперимент при "первом" p < α, то фактически мы проводим множественные проверки гипотез во времени. В этом случае уровень значимости α перестаёт контролироваться, а вероятность ложноположительного результата резко растёт. Митигация: — либо фиксированный дизайн без принятия решений до окончания теста; — либо использование sequential testing (Pocock, O’Brien–Fleming и др.); — либо Bayesian-подход, если нужен гибкий контроль во времени. Риск 1.2. Даже при корректном дизайне A/B-теста, результаты могут быть искажены, если выбранный статистический тест не соответствует данным. Например: — используется t-тест Стьюдента при разной дисперсии групп или разном размере выборок. Митигация: — проверка предпосылок теста (нормальность, равенство дисперсий); — использование t-теста Велча; — при сильных выбросах, непараметрические тесты. Риск 2. Предприниматели могут продолжать выбирать внешние решения (Tilda, Wix). Митигация: — Фокус не на “лучшем онбординге”, а на быстром пути к первым деньгам. Риск 3. Гипотеза может сработать только для микро-бизнеса и не масштабироваться на бОльшую аудиторию. Улучшить локальные, но уронить экосистемные. Митигация: — Стратификация результатов по типу бизнеса. — Принятие решения о масштабировании только при подтверждённом влиянии на NSM (MABI). — Учёт метрик смежных продуктов в экосистеме. Риск 4. Решение о приостановке развития приведёт к репутационным проблемам. Митигация: — Постепенная приостановка по мере оттока. — Отсутствие упоминаний модуля в маркетинговых каналах. Итог. Даже прирост +1 п.п. к конверсии даёт положительную экономику. Если гипотеза подтверждается — модуль масштабируется как часть b2b-воронки. Если нет, то развитие модуля в текущем виде приостанавливается, и требуется пересмотр роли Shopify-модуля в b2b-воронке. 🔜 В следующих по