Метрики

Все темы Data Analyst

Как выбрать правильную метрику для А/B теста. Какими могут быть метрики?

При выборе метрики для A/B теста необходимо учитывать следующие аспекты:

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

2. Чувствительность к изменениям: Метрика должна достаточно чувствительно реагировать на изменения, которые вы планируете внести. Например, если вы меняете дизайн кнопки “Купить”, конверсия будет более подходящей метрикой, чем количество кликов на эту кнопку.

3. Возможность измерения и достоверность данных: Выбранная метрика должна быть легко измеряемой и иметь достаточную статистическую значимость при анализе результатов.

Примеры метрик, которые могут использоваться в A/B тестировании:

• Конверсия: Например, конверсия в покупку, подписку или регистрацию.

• Среднее время нахождения на странице: Показатель интереса пользователя к контенту.

• Количество просмотров страницы или товара: Отражает популярность или вовлеченность пользователей.

• Коэффициент отказов: Процент пользователей, покинувших страницу без взаимодействия.

Выбор правильной метрики зависит от специфики бизнеса, поставленных целей эксперимента и способности измерять и интерпретировать полученные данные.

Когда стоит использовать прокси-метрику?

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

Как проверить, что прокси-метрика отражает целевой результат?

Сначала формулируют причинную цепочку от изменения к прокси и от прокси к конечному результату. Затем проверяют историческую связь с учетом времени и сегментов, но сильнее всего доказательство дают прошлые эксперименты: изменения прокси должны предсказывать направление и размер изменения цели. Оценивают чувствительность, стабильность, лаг и случаи расхождения. В новых тестах продолжают собирать конечную метрику и guardrails. Если команду можно мотивировать улучшить прокси вредным способом, она не годится как единственный критерий.

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

Прямого надежного uninstall-события часто нет. Можно определить операционную метрику, например отсутствие активностей заданное окно, но это смешивает удаление с неактивностью. Отзыв push-token или недоставка push служат сигналом, однако зависят от ОС, разрешений и качества доставки. Метрику считают по install-когортам с одинаковым окном наблюдения, исключают переустановки и проверяют на доступной ground truth или панельной выборке. Формулировка должна быть «вероятное удаление», если точность не доказана.

Как оценить инкрементальный эффект push-уведомлений?

Нужен случайный holdout пользователей, которым push не отправляют, при сохранении обычного продукта. Сравнивают целевую конверсию по назначению, а не только open rate: открытие является промежуточным событием и подвержено отбору. В воронке полезны sent, delivered и opened для диагностики, но эффект равен разнице с контролем. Guardrails включают opt-out, жалобы, uninstall и долгосрочный retention. Рандомизацию делают на пользователе, чтобы повторные уведомления не смешивали варианты.

Когда суммарная метрика вводит в заблуждение?

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