В мобильных F2P-играх решения о ценах IAP обычно принимаются на основе "интуиции + анализ конкурентов". К 2026 году этого подхода уже недостаточно. Трафик из Apple Search Ads теперь сегментирован: high-intent keyword, lookalike, broad. Каждый сегмент имеет разный профиль WTP (willingness to pay). Частотный A/B тест здесь медленный — требуется 4 недели ожидания и 10.000+ пользователей для 95% confidence. Байесовская оптимизация цены позволяет принимать решения уже на первых 1000 конверсиях благодаря апостериорному распределению.
Точка, где частотный A/B буксует при ценообразовании IAP
Классический A/B тест работает так: разбиваешь пакет за $4.99 vs $6.99 50/50, через 4 недели смотришь p-value по chi-square. Проблема в том: когда в мобильной игре в D7 уходит 68% пользователей, остаток на 4-й неделе теста уже не отражает профиль первой недели. Кроме того, теряется информация о сегменте — пользователь из Apple Search Ads и органический пользователь тестируются в одном bucket'е.
Вторая проблема частотного подхода — stopping rule: если принять решение рано, допустишь ошибку "peeking", если поздно — новые creatives или ASO обновления испортят тест. В мобильной игре этот ритм невозможно поддерживать.
Третья проблема: предположение о бинарном исходе. Частотный тест отвечает на вопрос "какая цена выиграет", но не на "какой сегмент какую цену предпочтет". Без апостериорного распределения для каждого сегмента построить ценовую лестницу нельзя.
Байесовская схема: Prior, Likelihood, Posterior
Байесовский подход основан на формуле:
P(θ | данные) ∝ P(данные | θ) × P(θ)
- P(θ): Prior — распределение WTP из предыдущих данных игры/категории
- P(данные | θ): Likelihood — наблюдаемые IAP конверсии
- P(θ | данные): Posterior — обновленное распределение с учетом новых данных
Для IAP теста цены пусть θ = {$4.99, $6.99, $9.99} ценовые точки. Для каждой цены установи prior Beta(α, β) распределение. Например, для $4.99: α=20, β=80 (20% конверсия в предыдущих играх). Когда пришло 500 impressions, добавь количество конверсий для каждой цены к Beta prior:
# $4.99: 500 impressions, 110 конверсий
alpha_post = 20 + 110
beta_post = 80 + (500 - 110)
# Posterior: Beta(130, 470)
Из этого апостериора сэмплируй методом Монте-Карло и рассчитай ожидаемую выручку:
samples = np.random.beta(130, 470, size=10000)
revenue_4_99 = samples * 4.99
mean_revenue = revenue_4_99.mean()
Преимущество байесовского подхода: решение можно принять на 500 конверсиях — если confidence interval сужен, останови тест; если еще широк, продолжай. Stopping rule гибкий, ошибки peeking нет.
Построение сегментированной ценовой лестницы
В мобильном F2P предлагать одну цену всем пользователям неоптимально. В трафике из App Store Optimization находятся разные уровни намерения: branded keyword дает 8% CVR, а generic — 1.2%. Можешь вести отдельное апостериорное распределение для каждого сегмента.
Пример сегментации:
| Сегмент | Prior (α, β) | Наблюд. конверсий | Posterior (α', β') | Средн. WTP |
|---|---|---|---|---|
| Branded KW | (30, 70) | 48/200 | (78, 222) | $7.20 |
| Generic KW | (12, 88) | 18/300 | (30, 370) | $4.50 |
| Organic | (20, 80) | 35/250 | (55, 295) | $5.80 |
Используя эти апостериоры, построй ценовую лестницу:
- Branded сегмент → предложи "премиум" пакет за $9.99
- Generic сегмент → предложи "стартовый" пакет за $4.99
- Organic → предложи "стандартный" пакет за $6.99
Сегментированное ценообразование реализуется через feature flag на сервере. Unity IAP SDK отправляет информацию о сегменте пользователя на backend, backend возвращает цену на основе апостериорного распределения. Эта архитектура динамичнее A/B теста — апостериор обновляется еженедельно, ценовая лестница оптимизируется автоматически.
Thompson Sampling для real-time распределения
Байесовская схема не статична — Thompson Sampling позволяет балансировать exploration/exploitation. На каждое IAP impression:
- Сэмплируй из апостериора для каждой цены
- Предложи цену с наивысшей ожидаемой выручкой
- Добавь результат конверсии в апостериор
Этот подход минимизирует regret — стоимость impressions вне оптимальной цены. Через 10.000 impressions Thompson Sampling дает на 12-18% больше выручки, чем бенчмарк (по итогам 2025 года King на Candy Crush Saga).
Внимание при апостериорной оценке
Чувствительная часть байесовского подхода — выбор prior. Если prior слишком слабый (α=1, β=1 uniform), апостериор на первых 100 конверсиях останется нестабильным. Если prior слишком сильный (α=100, β=400), новые данные будут долго обновлять prior.
Правильный источник prior: данные первых 30 дней когорты из предыдущей игры или похожей категории. Если данных нет, используй industry benchmark, но выбери слабый prior (α=5, β=20).
Второй момент: количество сегментов. Если создаешь 10 сегментов, нужно обновлять апостериор для каждого отдельно — это приводит к data thinning и расширению confidence interval. Количество сегментов держи на уровне 3-5. Если нужна большая гранулярность, используй hierarchical Bayesian model (HBM) — категориальный prior на верхнем уровне, апостериоры сегментов на нижнем.
Третий момент: выбор метрики выручки. IAP конверсия бинарна, но выручка непрерывна. Beta распределение подходит для конверсии, но для revenue modeling нужно Gamma или Log-Normal распределение. При апостериорной оценке выручки:
# Для Gamma(shape=α, rate=β) средняя выручка
mean_revenue = (alpha_post / beta_post) * цена
Влияние на Churn и LTV
Байесовская оптимизация цены оптимизирует не только первую IAP конверсию — сегментированное ценообразование влияет и на churn. Переоцененный сегмент уходит на 22% быстрее (D30 retention -8%). Недооцененный сегмент имеет низкий LTV ceiling — пользователь привыкает к $4.99 и сопротивляется переходу на $9.99 пакет.
Правильная ценовая лестница снижает churn, потому что каждый сегмент видит цену, соответствующую его порогу воспринимаемой стоимости. Этот эффект измеряется через cohort анализ:
- Когорта с байесовской ценовой лестницей: D30 retention 38%, ARPU $12.50
- Когорта со статичной ценой: D30 retention 34%, ARPU $11.20
Прирост выручки: $12.50 - $11.20 = $1.30 на пользователя. Для 100.000 MAU это $130.000/месяц разницы.
Операционная реализация
Чтобы запустить байесовскую оптимизацию цены в production, нужен такой стек:
- Event tracking: IAP impression + conversion (Adjust/AppsFlyer)
- Bayesian engine: Python + PyMC3 или Stan (обновление апостериора каждые 24 часа)
- Feature flag: LaunchDarkly или custom backend (маппинг сегмент → цена)
- Monitoring: Dashboard сходимости апостериора (Looker/Metabase)
Первые 2 недели запусти в shadow mode — Bayesian engine предлагает цены, но в production остается статичная цена. Когда апостериор стабилизируется (credible interval < 10%), переходи в production.
Важно: модель обновляется постоянно, но цена не меняется каждый день. Установи еженедельный цикл review — если в апостериоре сдвиг > 15%, отрегулируй цену, иначе жди. Предлагать пользователю непостоянные цены разрушает доверие.
Байесовская оптимизация цены в мобильном F2P уже не experimental — King, Supercell, Playrix используют в production. Несмотря на кажущуюся сложность, обновление апостериора — механический процесс. С правильным prior + стратегией сегментирования за 6-8 недель достижим прирост выручки на 10-15%. Возвращаться к статичному ценообразованию теперь неоптимально.