In-app purchases ломают LTV не ценой, а архитектурой выбора

In-app purchases ломают LTV не ценой, а архитектурой выбора

В IAP почти всегда выигрывает не самый дорогой пакет, а тот, который быстро отвечает на вопрос: «зачем платить именно сейчас?». Если внутри экрана все равно, что купить, конверсия уходит в сравнение цен и откладывание решения.

Рабочая схема:
— один «якорный» пакет для большинства;
— один premium-офер для high-intent;
— один маленький входной чек для первого платежа.
Так вы снижаете порог входа и одновременно оставляете апсейл. Главное — не делать 5–7 равных SKU: они размывают выбор и убивают скорость решения.

Для IAP лучше всего считать не только purchase rate, но и долю first purchase в первые 24–72 часа. Если первый чек не случился рано, дальше платят только самые мотивированные пользователи. Еще один важный срез — attach rate по сценарию: один и тот же набор покупок может работать в onboarding, в прогрессе и в моменте фрустрации совсем по-разному.

Типовая ошибка — продавать «монеты/кристаллы/пакеты» без привязки к действию в продукте. Пользователь не покупает валюту ради валюты; он покупает ускорение, доступ, снятие ограничения или статус. Чем короче связка между болью и оффером, тем выше ARPPU.

Финал простой: сначала проектируйте не каталог IAP, а путь к первой покупке. Потом уже тестируйте цену, бандлы и порядок SKU.