"Caveats and Limitations of A/B Testing at Growth Tech Companies"

Пересказ заметки "Caveats and Limitations of A/B Testing at Growth Tech Companies".

Начнем с того, что для A/B тестов есть несколько очевидных фундаментальных ограничений:

1. Для того, чтобы измерить эффекты в тесте, целевая метрика должна быть в принципе измеримой + у вас эти данные должны собираться;

2. Результаты A/B тестов показывают различимые отличия между группами на периоде проведения теста.

Теперь перейдем к более глубоким вопросам.

Измеримые метрики обычно лишь прокси для какого-то внешнего (и слабоизмеримого) влияния.

Например, если мы говорим об оттоке. Мы предполагаем, что высокий или низкий отток во время теста говорит о качестве нашего изменения. Но суть в том, что при достаточно коротком времени проведения эксперимента, мы скорее увидим только экстремально негативные проявления оттока (мы быстро успели достать нашего пользователя).

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

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

Особенно это важно для случаев редкого пользования сервисами (например, большая закупка продуктов и товаров на месяц). Для такого рода модели потребления нам становится еще сложнее отследить это накопление негатива.

Вторая история тут - это измеримость. Не каждую метрику мы вообще можем измерить.

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

Но если уж мы начали измерять что-то, то у нас могут быть вопросы и к качеству данных. Если кто-то вносит эти данные руками в систему каждый день, то есть ощущение, что такая метрика может иметь достаточно немало ошибочных или неточных значений. И вряд ли мы сможем ее использовать для качественных исследований.

Некоторые метрики являются обманчивыми и не ведут к реальной цели. Некоторые эффекты не являются стационарными.

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

Но тут возникает несколько проблем:

1. Мы не учитываем скрытые факторы цены. Например, мы не можем измерить потребительское восприятие выгоды от продукта, т.к. мы не можем залезть потребителю в голову. Соответственно, при более низком восприятии выгоды, мы через какое-то время потеряем потребителя, даже если на периоде теста все ок;
2. Цена, которая максимизирует прибыль, может зависеть от макро-экономических факторов и/или от поведения конкурентов.

Соответственно, нашу метрику прибыли можно вполне назвать обманчивой, т.к. она будет учитывать только кратковременную прибыль, но в итоге отталкивать от нас пользователей.

Еще одной проблемой будет нестационарность цены, т.к. конкуренты определенно решат что-то предпринять, если увидят резкое изменение нашей цены на продукт. Что, в свою очередь, повлияет на наши результаты.

Тут кроется весьма важная проблема с использованием результатов A/B тестирования. Если мы решим принимать "data-driven" решения на краткосрочном периоде проведения пилота, то это может привести к тому, что достаточно полезный по своей сути инструмент будет использоваться для того, чтобы "на данных" показывать эффективность наиболее простых и краткосрочных решений (например, поднятия цены), которые впоследствии приведут к итоговым негативным результатам. Обычно, к моменту проявления таких негативных эффектов, любители таких "эффективных" решений уже получают свою премию и уходят в другую компанию.

A/B-тесты, как правило, дают меньшие размеры эффекта по мере роста приложения.

Предположим, что у нас есть 5 фичей в продукте - ABCDE. И вы тестируете дополнительную фичу F. То есть, по сути, мы ищем различие между ABCDE и ABCDEF или условное ожидание от F при условии ABCDE.

И тут есть возникает интересная проблема. Она состоит в том, что нам становится важен порядок тестирования и раскатки фичей. И он может быть куда важнее, чем "качество фичи в вакууме".

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

В итоге, мы получаем насыщение фичами. В худшем случае, новые фичи начинают мешать нам, снижая метрики. И мы уже не сможем добавить ничего нового к продукту.

Компании обычно не решают эту проблему в лоб (что разумно).

Давайте еще раз посмотрим на наш эксперимент. У нас есть набор фичей ABCDE и мы добавляем F. Учитывая вышеописанное, более "честным" сравнением будет рассматривать разные варианты сочетаний последовательности. Что предполагает тестирование некоторых уже показавших себя фичей заново.

Но такой подход имеет достаточное количество минусов для бизнеса:

• Множество вариантов означает больше затрат на их поддержание;
• Сложно организовывать маркетинговые активности для разных сочетаний (очень сложно потом отвечать на вопрос, куда пропала полюбившаяся пользователю фича);
• Тестирование "худшего" варианта влечет за собой упущенную выгоду, т.к. мы отключаем что-то, что уже вроде бы приносит деньги.

Дополнительно, у нас могут быть и иные плюсы того, чтобы оставить старую фичу, даже если "в вакууме" она будет хуже новой, а именно:

• Поддержка уже сделанных и протестированных изменений гораздо проще и дешевле нововведений;
• Пользователи могут уже привыкнуть к старой фиче;
• Пользователи могут быть более чувствительны к отключению какого-то привычного функционала, чем к подключению непривычного (то есть, у нас несимметричный эффект от включения и выключения изменения).

Соответственно, это может влечь за собой неверное понимание и интерпретацию получаемых результатов. Не обязательно, что F в нашем примере - это плохое изменение, если оно ничего не принесло. Возможно, мы просто уже "пресытили" пользователя. И нам уже нужно какое-то серьезное изменение окружающего ландшафта, чтобы пользователя "встряхнуть" (и это серьезное изменение может как-то использовать наработки F, либо какие-то идеи и/или реализацию оттуда).

Какие же советы тут дает автор?

1. Не тестировать абсолютно любую гипотезу через А/Б тест (некоторые продакты очень любят такое развлечение). Помимо одного инструмента, у нас еще должен быть какой-то здравый смысл и теория, в рамках которой мы проверяем гипотезы. А вот случайное блуждание по как-то выдуманным идеям вряд ли хорошо скажется на продукте;
2. Когда вы видите уменьшение эффектов от новых инициатив, переходите к большей длительности экспериментов;
3. Стоит внимательно относиться ко времени проведения эксперимента. Далеко отстоящие во времени эксперименты часто становятся несравнимыми между собой;
4. При рассмотрении эксперимента следует рассматривать и импульсную переходную функцию вашего целевого показателя, считая ваше экспериментальное вмешательство импульсом.

Многие компании не понимают, что они вообще делают.

Получается так, что уже много кого в индустрии научили, что нужно "провести A/B тест", но не научили правильно учитывать вводные для проведения эксперимента, корректно интерпретировать результаты и делать верные выводы по факту проведения эксперимента. Что, в итоге, приводит к требованию "data-driven" выводов там, где они и не особо-то нужны, некорректным экспериментам и итоговой неразберихе. Что называется, "микроскопом гвозди забивать".

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

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

Реальность, конечно же, будет более сложна. И будет комбинацией факторов:

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

Обычно, такого рода подтверждение люди ищут, если не очень понимают, что делают. Либо, чтобы подтвердить какие-либо "серые" решения или в качестве психотерапии.

Автор приводит итоговое высказывание в стиле Байесовской статистики. Если брать в широком смысле, то результаты нашего анализа чаще полезны тогда, когда у нас нет никакого prior о ситуации, либо, когда наш prior оказывается ложным и опровергается. В принципе, весьма похоже на получение evidence, которые как-то влияют на наш prior. И в итоге, если prior очень силен, то может и не нужно искать для него подтверждений.

А сильный prior можно получить только из опыта работы в конкретной области. При этом, даже при большом опыте сложно соглашаться с не очень интуитивными выводами. Еще сложно спорить с "data-driven" подходом (особенно, если он насаждается сверху). И уж куда сложнее правильно интерпретировать результаты и слабые места используемых методов, чтобы потом адекватно оценивать получаемые результаты и иметь возможность их защитить.

Заканчивает автор личной историей токсичного использования data-driven подхода менеджментом. В примере автора, более высокий по должности менеджер требовал "показать ему на данных", что нужно предпринимать какие-то действия, (предположительно) осознанно используя тот факт, что указанные данные не собирались, либо собирались не особо качественно. И "данные" выступали лишь предлогом, чтобы и далее ничего не делать с проблемой, выигрывая споры посредством такого вот приема речи.