Я в статье про GrowthBook рассказал, что для заведения метрики нужно прописать кусок SQL-запроса, фактовую таблицу, и навесить на него конфиги метрики: столбец со значениями, агрегирующую функцию и фильтры. И после этого GB как конструктор соберет итоговый скрипт для расчета – поджойнит фактовую таблицу на таблицу с участниками эксперимента и сагрегирует данные.
Первый раз с такой идеей я столкнулся, когда пришел работать над A/B-платформой в Профи. Помню, был сильно впечатлен – любой аналитик может за минуту добавить в платформу (почти) какую-угодно метрику.
GB в этом плане идет дальше и дает гибкость буквально во всём. При заведении эксперимента можно собрать кастомный флоу из правил в фиче флаге. При расчете длительности можно оценить трафик тремя разными способами. При анализе результатов можно навесить сегменты, кастомные фильтры, разрезы, выбрать байесовский или частотный движок, добавить последовательное тестирование.
Но часто гибкость A/B-платформы может сыграть против вас. Одна из ключевых задач платформы – унифицировать подход к дизайну и анализу экспериментов. Если у компании нет платформы, то, скорее всего, в разных командах результаты тестов будут считать по-разному. Даже если есть общая тетрадка в репозитории. И это убивает саму идею тестирования.
Если платформа слишком гибкая и эта гибкость доступна всем, то ситуация будет не сильно лучше. Взять те же метрики: когда любой аналитик или продакт может завести метрику, раздел с ними очень быстро превращается в помойку. Хорошо, если метрики из этой помойки используются только как secondary или только для пост-анализа. Плохо, если – как целевые или охранные.
Например, в продукте есть атрибуция. На странице товара – две полки рекомендаций. Меняем алгоритм в верхней и смотрим на ARPU с этой полки. Решаем учесть каннибализацию нижней полки, поэтому добавляем в охранные ARPU с нижней полки. Видим, что верхняя полка стала перформить лучше. И, более того, нижняя тоже стала перформить лучше – никакой каннибализации!
А потом смотрим на то, как считается метрика ARPU с полки, которая когда-то кем-то без какого-либо ревью была добавлена в платформу:
ARPU с полки = Выручка с полки / количество пользователей, увидевших полку
То есть это ratio-метрика. В такие моменты нужно сразу насторожиться и подумать: а с какой стати я вообще использую ratio-метрику?
Помните великую статью от vk про подходы к анализу CTR? Они переходят от кликов на пользователя к CTR вот с таким ассампшеном:
The directionality of the global CTR is the same as the directionality of the sum of clicks if we don’t change views in our experiment.
Знаменатель ratio-метрики не должен быть подвержен влиянию тритмента. С верхней полкой это действительно так. А что с нижней? Верхняя стала перформить так хорошо, что до нижней стало доходить существенно меньше пользователей – только самые жесткие шопоголики. Они в среднем тратят больше, чем другие группы пользователей. Вот мы и видим прирост в нашей (неподходящей) ratio-ARPU с нижней полки. Только это не означает, что нижняя полка после внедрения фичи приносит больше денег.
Правильный ARPU с полки = Выручка с полки / количество пользователей в группе эксперимента = CR в полку * ratio-ARPU с полки
И это уже не ratio, а обычная поюзерная метрика. Она то нам и нужна, так как учитывает и конверсию в полку, и выручку с долиставших до нее.
Я это все к чему. Если в компании никто не следит за методологией A/B-тестирования (в широком смысле), то гибкость платформы становится её недостатком. Хорошее решение проблемы, на мой взгляд, – собрать группу людей, у которых есть время на подумать над методологией. И гибкость должна быть доступна только им – по крайней мере в вопросах, касающихся дизайна экспериментов и принятия решения по ним. Пусть они раздают галочки для метрик, чтобы те можно было использовать как целевые, проверяют нестандартную настройку фиче флагов, возможность использования сегментов и т.д.
А остальным хуй