Кейс с собеседования: дизайн AB-теста для новых тарифов
Этот кейс давали на собеседовании в дейтинг-приложение, но условие универсальное для любого подписочного сервиса.
Контекст кейса:
Этап 1: Задать правильные вопросы.⁉️
Несложно заметить, что контекста мало, а задача абстрактная. Чтобы это исправить - необходимо задать корректные наводящие вопросы.
Вопрос 1: На какую метрику смотрим?📈
Продакт перекидывает вопрос вам и предлагает предложить метрику самому.
Очевидный кандидат - ARPU (выручка на пользователя из теста), но у нее есть недостаток - она менее чувствительна, чем конверсия.
Если конверсия из триала в оплату была 20%, а после роста цены просела до 18% (минус 10% относительно), ARPU по формуле почти не сдвинется: 0.20 × P (цена подписки) против 0.18 × 1.10P = 0.198P.
Разница - около 1%. Глядя только на ARPU, вы бы решили, что почти ничего не произошло. (Особенно, если учитывать высокое стандартное отклонение ARPU)
А по факту потеряли десятую часть платящих.
Поэтому primary метрика - CR из триала в платную подписку.
ARPU, ARPPU и retention после первой оплаты идут в secondary-метрики: рост цены может держать выручку на месте, но резать базу, а в дейтинге база платящих - это ещё и часть продукта (больше платящих - больше активных профилей - лучше матчинг для всех).
Вопрос 2: На какой сегмент воздействуем?👥
Тут продакт дает нам инсайт: только на новичков.
Действующие подписчики при повышении цены увидели бы её только при продлении и некоторые среагировали бы оттоком, чего нам не хочется допустить.
Это упрощает нам дизайн.
Раз воздействие только на новых, рандомизация становится простой: по user_id в момент первого показа пейвола, без пересечений с базой "пользователей-старичков".
Вопрос 3: Какой путь у пользователя до пейвола?
Продакт отвечает:
Установка -> онбординг -> немного бесплатного взаимодействия (просмотр анкет, ограниченное число лайков) -> упирается в лимит -> экран с тремя тарифами и предложением недели триала.
В экране с тарифами и рандомизируем.
На этом этапе основные вопросы заканчиваются и можно переходить к дизайну.
Дизайн теста🧪
Из трёх ответов дизайн собирается сам:
-> гипотеза - повышение цены не снижает CR из триала в оплату сильнее, чем на X%;
-> метрика - CR триал-оплата;
-> unit рандомизации - user_id на входе в пейвол;
-> сплит 50/50: контроль видит старые цены, тест - новые
-> сегмент - только новые пользователи; guardrails - ARPU, ARPPU, retention;
-> срок - минимум полный цикл триала плюс время на накопление конверсий.
Дальше несем дизайн продакту и получаем обратную связь.
Тест слишком длинный, что делать?⏱
Продакт возвращается с этим вопросом почти всегда.
Первая мысль - использовать CUPED, снижаем дисперсию за счёт предэкспериментального значения метрики.
Но у новичков нет предпериода: они только что поставили приложение, снижать дисперсию не на чем.
Так ведь?
На самом деле - не совсем.
Ковариата должна быть измерена до воздействия, но "до воздействия" не значит "до установки приложения".
Между установкой и показом пейвола пользователь уже наследил: сколько действий сделал за бесплатный период, как вёл себя в онбординге, с какого канала пришёл, какое у него устройство.
Это и есть ковариаты, которые нам необходимы в CUPAC - предсказываем метрику моделью, обученной на этих признаках, и используем предсказание вместо честного предпериода для снижения дисперсии.
Валидно это ровно потому, что до пейвола вы ничего не меняли: функционал одинаков для всех, разной становится только цена на самом экране.
Собеседование на дизайн эксперимента редко проверяет знание формул. Оно проверяет, структурно ли вы мыслите, умеете ли вы задавать необходимые вопросы, и различаете ли вы детали
Ставьте 🔥, если пост вам зашел
Этот кейс давали на собеседовании в дейтинг-приложение, но условие универсальное для любого подписочного сервиса.
Контекст кейса:
Представьте, что вы аналитик в дейтинговом приложении.
У вас в продукте есть 3 тарифа, которые отличаются функционалом и количеством доступных действий в месяц + триал период на 1 неделю.
К вам приходит продакт и говорит: хочу поднять цену на все тарифы 10%, давай оценим эффект.
Как вы будете это делать?
Этап 1: Задать правильные вопросы.⁉️
Несложно заметить, что контекста мало, а задача абстрактная. Чтобы это исправить - необходимо задать корректные наводящие вопросы.
Вопрос 1: На какую метрику смотрим?📈
Продакт перекидывает вопрос вам и предлагает предложить метрику самому.
Очевидный кандидат - ARPU (выручка на пользователя из теста), но у нее есть недостаток - она менее чувствительна, чем конверсия.
Если конверсия из триала в оплату была 20%, а после роста цены просела до 18% (минус 10% относительно), ARPU по формуле почти не сдвинется: 0.20 × P (цена подписки) против 0.18 × 1.10P = 0.198P.
Разница - около 1%. Глядя только на ARPU, вы бы решили, что почти ничего не произошло. (Особенно, если учитывать высокое стандартное отклонение ARPU)
А по факту потеряли десятую часть платящих.
Поэтому primary метрика - CR из триала в платную подписку.
ARPU, ARPPU и retention после первой оплаты идут в secondary-метрики: рост цены может держать выручку на месте, но резать базу, а в дейтинге база платящих - это ещё и часть продукта (больше платящих - больше активных профилей - лучше матчинг для всех).
Вопрос 2: На какой сегмент воздействуем?👥
Тут продакт дает нам инсайт: только на новичков.
Действующие подписчики при повышении цены увидели бы её только при продлении и некоторые среагировали бы оттоком, чего нам не хочется допустить.
Это упрощает нам дизайн.
Раз воздействие только на новых, рандомизация становится простой: по user_id в момент первого показа пейвола, без пересечений с базой "пользователей-старичков".
Вопрос 3: Какой путь у пользователя до пейвола?
Продакт отвечает:
Установка -> онбординг -> немного бесплатного взаимодействия (просмотр анкет, ограниченное число лайков) -> упирается в лимит -> экран с тремя тарифами и предложением недели триала.
В экране с тарифами и рандомизируем.
На этом этапе основные вопросы заканчиваются и можно переходить к дизайну.
Дизайн теста🧪
Из трёх ответов дизайн собирается сам:
-> гипотеза - повышение цены не снижает CR из триала в оплату сильнее, чем на X%;
-> метрика - CR триал-оплата;
-> unit рандомизации - user_id на входе в пейвол;
-> сплит 50/50: контроль видит старые цены, тест - новые
-> сегмент - только новые пользователи; guardrails - ARPU, ARPPU, retention;
-> срок - минимум полный цикл триала плюс время на накопление конверсий.
Дальше несем дизайн продакту и получаем обратную связь.
Тест слишком длинный, что делать?⏱
Продакт возвращается с этим вопросом почти всегда.
Первая мысль - использовать CUPED, снижаем дисперсию за счёт предэкспериментального значения метрики.
Но у новичков нет предпериода: они только что поставили приложение, снижать дисперсию не на чем.
Так ведь?
На самом деле - не совсем.
Ковариата должна быть измерена до воздействия, но "до воздействия" не значит "до установки приложения".
Между установкой и показом пейвола пользователь уже наследил: сколько действий сделал за бесплатный период, как вёл себя в онбординге, с какого канала пришёл, какое у него устройство.
Это и есть ковариаты, которые нам необходимы в CUPAC - предсказываем метрику моделью, обученной на этих признаках, и используем предсказание вместо честного предпериода для снижения дисперсии.
Валидно это ровно потому, что до пейвола вы ничего не меняли: функционал одинаков для всех, разной становится только цена на самом экране.
Собеседование на дизайн эксперимента редко проверяет знание формул. Оно проверяет, структурно ли вы мыслите, умеете ли вы задавать необходимые вопросы, и различаете ли вы детали
Ставьте 🔥, если пост вам зашел