За пределами фичей и метрик: место концептуализации в разработке продуктов

[Dhwtj]

Математик спешит на помощь:

Если мы дадим пользователям конструктор, они соберут из него идеал?

Думаю, нет.

Так что же мы ждём от a/b гипотез?

Если взять математические аналоги, то a/b гипотезы это метод градиентного спуска, медленный, он склонен упираться в медленные места и надо его оттуда выгонять (если А и Б дают почти одинаковый результат, то попробовать несколько похожих) или стохастически или паттернами. А ещё есть метод сопряженных градиентов.

А ещё при определенной размере выборки (а/б гипотезы) у нас будет такой шум, что параллельно нельзя изучать много гипотез и скорость оптимизации (одной и всех) будет низкой. Что же делать?

если вам нужно отличить +0,2 % от 0 % при суточной дисперсии 20 %, то без ≈ (3,9·σ/δ)² ≈ 1,5 млн наблюдений вообще ничего не поделаешь

Факторный (multivariate / factorial) дизайн, испытываем не одну гипотезу, а сразу из комбинации. Желательно, чтобы гипотезы были ортогональны, не влияли взаимно.

Адаптивное распределение и ранняя остановка. При достаточной достигнутой точности останавливаем эксперимент, а не по запланированному времени.

Если цель не столько исследования, столько оптимизация, то есть смешной название Мультиарм-бандиты (ε-Greedy, UCB, Thompson)      

• Быстро «подсаживают» победителя на 80–90 % трафика,      

• остальные 2–3 % трафика всё-таки уходят на исследование → гипотез в параллели может жить десятки.      

Минус — детальной статистики «контроль vs X» уже нет; используем, когда цель — онлайн-оптимизация, а не строгая публикация

Ну а главное, как вы уже сказали (?) это подавать на вход умные гипотезы, а не белый шум.