Вы работаете над приложением Т-Банка. Вы с командой придумали фичу “Проактивные переводы”. Как это работает: если у пользователя есть номер карты или телефона в буфере обмена, он заходя в банковское приложение видит рекомендацию о переводе. Вопросы:

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

Улучшения сценария

• Переместить модальное окно под палец • Сделать быструю команду на главной, чтобы не блокировать клиентский путь • Настроить быструю команду на иконку приложения (iOS) • Сделать кнопку более очевидной

• Добавить возможность закрыть уведомление

Проверка гипотезы

Для проверки выбираем A/B-тестирование. Почему?

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

Дизайн A/B теста

• Выбор метрик

• Определение MDE — минимальный детектируемый эффект (какое минимальное изменение метрики должно произойти для стат значимости) • Выбор параметров и расчет длительности теста в калькуляторе

Какие метрики будем смотреть в A/B тесте?

3 типа метрик: • Целевая – конверсия в перевод • Прокси (опережающая) – конверсия в клик на кнопку на модальном окне • Контр (подверженные ухудшению) – % отказов, среднее количество кликов до целевого действия, CSI переводов

В любом аб тесте нужно определить MDE, сделать это можно на основе

• Прошлых A/B тестов • Потенциал сдвига текущего показателя • Иногда: картотека A/B других компаний в открытом доступе