🛡 Как вы планируете работу с защитными метриками в АБ тесте (обсуждение)?

Защитные метрики - это такие метрики, которые не должны ухудшится по результатам АБ теста.

Например вы сделали, какую-то фичу с целью увеличить arpu, но боитесь, что также вырастет число обращений в тех поддержку, что увеличит затраты на ТП. Соответственно среднее число обращений на пользователя - может быть защитной метрикой, которая не должна вырасти.

Вопрос в том как именно работать с этой метрикой. Я встречал 4 сценария работы с защитными метриками.

1. Нет защитных метрик - нет проблем😁

2. По результату эксперимента просто "на глазок" определяем изменилась ли защитная метрика и принимаем решение. Такой подход выглядит очень субъективным. Принимающий решение, может трактовать результат как захочет.

3. По результатам эксперимента защитную метрику также как и целевую прогоняем через стат критерий и оцениваем стат значимость отличий в защитной метрике.

Тут субъективизма меньше чем в варианте 2, но есть другая проблема. Даже если стат критерий скажет нам, что значимого ухудшения нет - это не означает что его нет вообще, возможно нам просто не хватило мощности эксперимента(объема выборки), чтобы обнаружить это ухудшение и после выкатки метрика все же ухудшится.

4. При планировании эксперимента для защитной метрики определяем какое ухудшение для нас приемлемо(MDE) и от этого MDE считаем размер выборки и соответственно в сроке проведения эксперимента учитываем нужный размер выборки для набора мощности теста для защитной метрики.

Тут проблема другая, нам нужно запланировать какое-то ухудшение, чтобы рассчитать выборку, но как правило никто не хочет даже малейшего ухудшения)

Расскажите как вы работаете с защитными метриками?🧐