Bayesian Price Optimization в мобильных F2P играх

В мобильных F2P-играх ценовые решения часто основаны на интуиции или "общепринятых на рынке ценах". Стартовый пак за $0.99, mid-tier за $4.99, whale bundle за $99.99 — этот ценовой ladder повторяется в большинстве игр. Однако каждая игра имеет уникальную структуру когорт, географический микс и восприятие ценности. Bayesian price optimization позволяет моделировать эти различия через posterior probability distribution и находить оптимальную ценовую точку для каждого сегмента. Вместо классического A/B-теста, создав систему непрерывного обучения, вы можете улучшить IAP conversion rate на 15-40%.

Почему Bayesian подход лучше, чем A/B-тест

Классический A/B-тест работает с фиксированной гипотезой: сравнивает две цены (например, $4.99 vs $5.99), ждёт достижения 95% confidence и выбирает победителя. У этого подхода два недостатка: во-первых, во время теста трафик делится пополам, и плохо работающий вариант продолжает показываться пользователям (opportunity cost). Во-вторых, после завершения теста вы получаете только решение "A или B" — никакой информации о промежуточных значениях или сегмент-специфичных различиях.

Bayesian optimization начинает с prior distribution (например, "цена может быть в диапазоне $3-$7 с равномерным распределением"), добавляет каждый conversion в posterior и непрерывно обновляет probability distribution. Благодаря алгоритмам вроде Thompson Sampling трафик динамически перемещается в сторону выигрывающего варианта — общий доход максимизируется на протяжении всего теста. Например, при 10-дневном тесте Bayesian подход генерирует на 8-12% больше revenue, потому что худшим ценовым точкам отправляется минимум трафика.

Более того, Bayesian модель не просто говорит "эта цена победила", но предоставляет confidence interval типа "вероятность оптимальности этой цены — 87%". Эта информация ускоряет итерацию: даже с 60% confidence вы можете запустить цену в продакшене и начать новый тест, потому что posterior distribution уже содержит достаточно информации.

Сегмент-ориентированная конструкция prior для IAP price ladder тестов

В F2P-играх все пользователи — не одно и то же. Правильная идентификация ваших сегментов spender укрепляет prior Bayesian модели. Типичная сегментация: minnows (lifetime spend <$10), dolphins ($10-$100), whales (>$100). Каждый сегмент имеет разную ценовую эластичность — minnows конвертируют даже на $0.99 пак, а whales покупают $99.99 бандл без взгляда на цену.

Конструирование prior distribution по сегментам требует исторических данных. Например, если в minnow сегменте средний IAP conversion rate между $0.99 и $1.99 составляет 3.2%, используйте как prior mean $1.49 и sigma $0.50 (при предположении нормального распределения). Для whale сегмента, где conversion rate в диапазоне $49.99-$149.99 остаётся почти плоским, более подходит uniform prior — то есть модель отражает гипотезу "whales нечувствительны к цене".

Преимущество сегмент-ориентированного prior в том, что он предотвращает кросс-сегментное смешивание. Классический A/B-тест объединяет всех пользователей в один пул, и высокая конверсия whales на дешёвом варианте может маскировать оптимальную цену для minnows. Bayesian модель обновляет posterior отдельно для каждого сегмента, так что результат показывает segment-optimal цены: $1.49 для minnows, $79.99 для whales.

Гео-специфическая калибровка prior

В Tier-1 географии (US, UK, JP) и развивающихся рынках (BR, TR, IN) покупательная способность кардинально различается. В США пак за $4.99 воспринимается как "дешёвый", тогда как та же цена в Турции (примерно ₺150) относится к середине-верхнему диапазону. Нормализуйте prior distribution по географиям, используя локальные ARPU данные. Например, если среднее дневное IAP в США составляет $0.42, а в Турции $0.18, масштабируйте prior mean по этому коэффициенту (0.18/0.42 = 43%). Таким образом, модель тестирует одинаковый relative price ladder в каждой географии, встраивая различие абсолютных значений в prior.

Оценка posterior и реализация Thompson Sampling

Движок runtime'а Bayesian модели — это оценка posterior. При каждом IAP impression (показе предложения) вы извлекаете sample из текущего posterior distribution (например, при Beta distribution это np.random.beta(alpha, beta)). Цена, соответствующая этому sample'у, показывается пользователю. Если пользователь совершает покупку, alpha += 1; если пропускает, beta += 1 — posterior обновляется.

Thompson Sampling использует этот механизм для распределения трафика. Для каждого варианта извлекается ожидаемый reward из posterior, выбирается вариант с наибольшим reward. В первые несколько дней все варианты получают равный трафик (exploration), затем трафик смещается в сторону выигрывающего варианта (exploitation). Баланс обеспечивается не epsilon, а variance posterior — вариант с низкой variance (высокая confidence) получает больше трафика.

Для практической реализации используйте Python scipy.stats.beta или pymc3. Простой код:

import numpy as np
from scipy.stats import beta

# Prior: alpha=1, beta=1 (uniform)
alpha_a, beta_a = 1, 1  # Вариант A ($4.99)
alpha_b, beta_b = 1, 1  # Вариант B ($5.99)

def select_variant():
    sample_a = np.random.beta(alpha_a, beta_a)
    sample_b = np.random.beta(alpha_b, beta_b)
    return "A" if sample_a > sample_b else "B"

def update_posterior(variant, converted):
    global alpha_a, beta_a, alpha_b, beta_b
    if variant == "A":
        if converted:
            alpha_a += 1
        else:
            beta_a += 1
    else:
        if converted:
            alpha_b += 1
        else:
            beta_b += 1

Этот простой loop после 10.000 impression сходится к posterior mean с погрешностью ~2% от реального conversion rate (при условии корректности Beta prior). В production вы можете ежедневно обновлять posterior параметры через BigQuery + Airflow и запускать новые когорты с актуальным распределением.

Multi-armed bandit vs полная Bayesian модель

В литературе по Bayesian price optimization выделяются два основных подхода: multi-armed bandit (MAB) и полная Bayesian регрессия. Подход MAB — это описанный выше Thompson Sampling: discrete ценовые варианты (например, 5 ценовых точек) определяются как "руки", posterior ведётся отдельно для каждой. Преимущества: простая реализация, лёгкий runtime, real-time принятие решений.

Полная Bayesian регрессия моделирует цену как непрерывную переменную, связывая вероятность конверсии с ценой через логистическую регрессию или Gaussian process. Этот подход гибче — например, может обучиться нелинейным зависимостям вроде "по мере роста цены conversion rate падает экспоненциально". Недостаток: требует BigQuery + Python stack для обучения, не позволяет принимать решения в real-time (только batch prediction).

В F2P-играх MAB обычно достаточно, так как price ladder уже является discrete ($0.99, $2.99, $4.99, $9.99). Полная Bayesian модель становится необходима при dynamic pricing (разные цены для разных пользователей) — но большинство app store policies это запрещают (ценовая дискриминация). Компромиссный вариант: MAB по сегментам, полная Bayesian регрессия внутри каждого сегмента. Так вы находите оптимальный диапазон $79.99-$149.99 для whale сегмента как непрерывную функцию.

Uplift revenue и влияние на LTV когорты

Реальный ROI Bayesian price optimization проявляется в cohort LTV. На первой неделе теста conversion rate растёт на 8%, но D30 LTV этих пользователей оказывается на 15-20% выше. Почему? Потому что оптимальная ценовая точка точно совпадает с восприятием ценности пользователем — ни слишком низко (падение perceived value), ни слишком высоко (friction). После первой IAP такие пользователи с большей вероятностью покупают второй пак.

Пример: в mid-core RPG вместо стартового пака за $4.99 Bayesian модель рекомендовала $3.49 (minnow сегмент, US гео). На первой неделе conversion rate вырос с 22% до 28% (+27% relative). D7 retention остался на уровне 42%, однако D30 ARPU поднялся с $2.18 до $2.51 (+15%). Почему? Цена $3.49 снизила порог "я готов инвестировать в эту игру", вторая покупка требовала меньше friction. Общее cohort LTV увеличилось с $8.90 до $10.20 (+15%).

Для измерения этого эффекта необходим cohort анализ. В BigQuery отслеживайте колонки user_id, install_date, first_iap_price, d7_revenue, d30_revenue. Флагируйте вариант Bayesian теста через experiment_group, сравнивайте LTV кривые с контрольной группой. На первой неделе significance тест рано срабатывает, на D30 confidence растёт.

Распространённые ошибки и trade-off'ы

Миф "Bayesian price optimization сразу победит" широко распространён. На самом деле posterior convergence требует минимум 5.000-10.000 impression (на сегмент). На низкотрафиковых играх (DAU <50k) тестирование может растянуться на 4-6 недель. За этот период data pipeline (impression logging, conversion tracking, posterior update) должен работать стабильно — одна ошибка испортит весь posterior.

Второй trade-off — гранулярность сегментации. Если вы создаёте слишком тонкий сегмент (например, "LTV $5-10, US, Android, whale"), в каждом сегменте будет недостаточно sample size, posterior останется с высокой variance. Практическое правило: на сегмент должно быть минимум 200 IAP impression в день. Если меньше — объедините сегменты (например, US+UK+CA становятся единым "Tier-1 EN").

Третий момент — психологический эффект смены ценового ladder'а. Если пользователь вчера видел $4.99, а сегодня видит $3.99, возникает восприятие "скидки" и conversion скачет — но это неустойчиво. Во время Bayesian теста держите диапазон цен узким (максимум ±20%), избегайте радикальных изменений (типа $4.99 → $1.99).

Масштабирование и автоматизация после теста

Bayesian price optimization — это не одноразовый тест, а система непрерывного обучения. После завершения теста вы запускаете выигрывающую цену в production, но сохраняете posterior distribution и используете её как prior для новых когорт. Например, в Q4 (holiday season) ARPU растёт на 30% — anterior posterior из прошлого квартала становится новым prior, модель быстро переходит к новому оптимуму (warm start вместо cold start).

Автоматизацию можно построить на Airflow + BigQuery + Firebase Remote Config. Ежедневный Airflow DAG читает posterior параметры из BigQuery, пишет новые ценовые варианты в Firebase Remote Config. Client SDK fetch'ит Remote Config, показывает IAP предложение. Event конверсии логируется в BigQuery, posterior обновляется — цикл закрывается. Первоначальная настройка занимает 2-3 недели, потом система работает на autopilot.

Финальный шаг: если вы хотите масштабировать Bayesian модель на несколько игр, создайте централизованный "pricing service". Каждая игра отправляет метаданные (жанр, гео микс, ARPU), сервис по профилю игры предлагает prior distribution. Новые игры избегают cold start, применяя transfer learning из posterior аналогичных игр. Сервис Roibase по App Store Optimization объединяет этот тип cross-app pipeline обучения с ASO creative тестами — такой же Bayesian framework применя