Доброго вечера, твиттеровчане! Интенсив по теории в авиашколе занимает больше времени, чем я рассчитывал, поэтому ближе к 8 вечера стартуем тред про data-driven подход к разработке.
Главное, чему меня научили полтора года в Джуме - это проверять все свои фичи, все технические нововведения количественно. Культура эксперимента возведена в компании в абсолют. Для этого существуют внутренние тулзы аналитики и экспериментов.
Если мы делаем новую фичу - мы проверяем ее ценность экспериментом. Редизайн - проверяем экспериментом. Радикальная смена имплементации - проверка экспериментом.
Для того, чтобы провести эксперимент, нам нужно разбить пользователей на минимум две группы. Первая группа будет "базовой": пользователи не увидят проверяемых фич, а ее метрики будут взяты за основу. Остальные группы будут тестовыми: именно на них мы и ставим опыты.
Важно, что эти группы нельзя набрать ретроспективно. Важно, чтобы в режиме реального времени пользователи с равной вероятностью попадали в одну из групп. Иначе мы очень подвержены влиянию времени суток, дня недели, сезонности, маркетинга и тд.
По окончании эксперимента мы имеем возможность сравнить метрики тестовых групп с базовой. Зная распределение метрик и количество людей в каждой из групп, мы можем посчитать не только разницу в %, но и доверительный интервал для этого расчета.
К примеру, эксперимент показывает рост retention на 10%, но этот результат получен на 10 пользователях и на самом деле он находится в диапазоне -80%...+90%.
Используя доверительные интервалы, мы можем определить "красные", "серые" и "зеленые" "прокрасы". "Красный прокрас" говорит о том, что метрика точно ухудшилась, "зеленый" - что точно улучшилась, "серый" - что границы доверительного интервала лежат по разные стороны от ноля.
Эксперименты бывают нескольких типов:
Улучшающие
Ухудшающие
Технические
Исследовательские
С улучшающими все просто: мы делаем новые фичи или улучшаем старые, и хотим убедиться, что они действительно делают лучше пользователям или компании (в идеале, и тем и другим). Получили "зеленый прокрас" - мы молодцы, серый или красный - надо что-то менять.
Ухудшающие эксперименты нужны, чтобы проверить, что фича, которая давно с нами все еще актуальна и полезна. В ходе такого эксперимента она отключается (или как-то сознательно портится). Если прокрас "красный", значит это ценная фича и можно вкладываться в ее дальнейшее развитие.
Технические помогают проверить, что мы ничего не сломали сменой реализации или еще какими-то ужасно полезными улучшениями. Тут ожидаемый результат - "серый", то есть техническая часть не повлияла на бизнес.
В исследовательских экспериментах я не силен. Общий принцип в том, чтобы поиграться с настройками уже имеющихся фич, чтобы получить пищу к размышлению, как дальше развивать продукт.
При этом в любом из экспериментов могут быть приемочные, охранные и вспомогательные метрики. Приемочная позволяет понять, достигли ли мы цели фичи. К примеру, мы хотели более ярким цветом кнопки повысить конверсию в нажатие.
Охранная метрика позволяет проследить, что мы при этом не уронили другие важные метрики. В том же примере с кнопкой, мы можем поднять конверсию в нажатие, но так разозлить пользователя, что конверсия всей цепочки действий неминуемо упадет.
Вспомогательные метрики помогут нам понять, что именно пошло не так. К примеру, если конверсия в нажатие не растет, мы можем посмотреть а показывается ли у нас целевой элемент.