36. Мобильное приложение OneScore: проверка сложной гипотезы по шагам
Про мобильное приложение, которое позволяет зарабатывать водителю, стоя в пробке, мы писали в самом первом посте.
Напомним, как это работало. Пользователь зарабатывает каждой минуте в пробке, получая условный балл приложения. Баллы можно тратить на предложения партнеров (скидки, купоны). За каждый «погашенный» купон, т.е. за каждого приведенного пользователя, партнер платил нам живые деньги, именно на этом мы и зарабатывали.
Основателей проекта заботила гипотеза о заработке, т.е. сколько денег стоит брать у партнеров за каждого клиента. Стоит ли привязываться к фиксированной стоимости или брать процент от чека. Если процент от чека, как контролировать размер этого чека. Но на самом деле перед проверкой этой гипотезы следует проверить много других, потребительских.
Воронка взаимодействия с приложением для пользователя:
1. Пользователь устанавливает приложение.
2. Пользователь начинает копить баллы.
3. Пользователь продолжает копить баллы.
4. Пользователь тратит накопленные баллы у партнеров.
5. Партнер переводит нам деньги за приведенного пользователя.
Тестирование бизнес-модели нужно начинать с первого, а не с последнего этапа.
Как считать гипотезы протестированными:
1. Стоимость установки приложения (CPI).
2. Конверсия из установившего приложение в первое накопление (в процентах).
3. Конверсия из тех, кто накопил хотя бы один балл, в тех, кто накопил 120 баллов (в процентах). Можно изменить критерий на этом этапе, например, Конверсия в тех, кто накопил баллы за две и более сессии.
4. Конверсия из тех, у кого есть на счету хотя бы 120 баллов (стоимость минимального купона) в тех, кто потратил накопленные баллы хотя бы один раз (в процентах).
5. Конверсия из партнеров, купоны которых были куплены пользователями и погашены, в тех, которые произвели оплату за привлеченного клиента (процент).
Вроде несложно. Но как вы думаете, на каком из этапов были самые плачевные показатели и почему? Ответ пишите в комментариях.
#кейс@custdevlab #гипотезы@custdeavlab #onescore@custdevlab
Про мобильное приложение, которое позволяет зарабатывать водителю, стоя в пробке, мы писали в самом первом посте.
Напомним, как это работало. Пользователь зарабатывает каждой минуте в пробке, получая условный балл приложения. Баллы можно тратить на предложения партнеров (скидки, купоны). За каждый «погашенный» купон, т.е. за каждого приведенного пользователя, партнер платил нам живые деньги, именно на этом мы и зарабатывали.
Основателей проекта заботила гипотеза о заработке, т.е. сколько денег стоит брать у партнеров за каждого клиента. Стоит ли привязываться к фиксированной стоимости или брать процент от чека. Если процент от чека, как контролировать размер этого чека. Но на самом деле перед проверкой этой гипотезы следует проверить много других, потребительских.
Воронка взаимодействия с приложением для пользователя:
1. Пользователь устанавливает приложение.
2. Пользователь начинает копить баллы.
3. Пользователь продолжает копить баллы.
4. Пользователь тратит накопленные баллы у партнеров.
5. Партнер переводит нам деньги за приведенного пользователя.
Тестирование бизнес-модели нужно начинать с первого, а не с последнего этапа.
Как считать гипотезы протестированными:
1. Стоимость установки приложения (CPI).
2. Конверсия из установившего приложение в первое накопление (в процентах).
3. Конверсия из тех, кто накопил хотя бы один балл, в тех, кто накопил 120 баллов (в процентах). Можно изменить критерий на этом этапе, например, Конверсия в тех, кто накопил баллы за две и более сессии.
4. Конверсия из тех, у кого есть на счету хотя бы 120 баллов (стоимость минимального купона) в тех, кто потратил накопленные баллы хотя бы один раз (в процентах).
5. Конверсия из партнеров, купоны которых были куплены пользователями и погашены, в тех, которые произвели оплату за привлеченного клиента (процент).
Вроде несложно. Но как вы думаете, на каком из этапов были самые плачевные показатели и почему? Ответ пишите в комментариях.
#кейс@custdevlab #гипотезы@custdeavlab #onescore@custdevlab