Настройка A/B тестирования в мобильном приложении

Настройка A/B тестирования в мобильном приложении

A/B тест — это контролируемый эксперимент, в котором один сегмент пользователей видит вариант A, другой — вариант B, и мы измеряем, какой вариант даёт лучший результат по целевой метрике. На практике большинство A/B тестов в мобильных приложениях либо настроены некорректно (нет статистической значимости, эксперимент остановили слишком рано), либо не запускаются вовсе — потому что нет инфраструктуры.

Выбор инструмента

Для большинства мобильных проектов Firebase A/B Testing — разумный старт. Интеграция через Remote Config, нет дополнительных SDK.

Firebase A/B Testing: настройка

Firebase A/B Testing строится поверх Remote Config. Сначала определяем параметр:

// Получаем значение из Remote Config
let remoteConfig = RemoteConfig.remoteConfig()
remoteConfig.configSettings = RemoteConfigSettings()
remoteConfig.configSettings.minimumFetchInterval = 0  // в debug

remoteConfig.fetchAndActivate { status, error in
    let ctaText = remoteConfig.configValue(forKey: "checkout_cta_text").stringValue
    self.checkoutButton.setTitle(ctaText, for: .normal)
}

В Firebase Console → A/B Testing создаём эксперимент:

1. Выбираем checkout_cta_text как Target Parameter
2. Control: "Оформить заказ"
3. Variant A: "Купить сейчас"
4. Целевая метрика: purchase (конверсионное событие)
5. Процент участников: 50%
6. Минимальный размер выборки: Firebase рассчитывает автоматически

Критические ошибки в A/B тестах

Остановка теста при первых значимых результатах — самая частая ошибка. Если смотреть на p-value каждый день и остановить тест когда p < 0.05 впервые — вероятность ложноположительного результата значительно выше заявленных 5%. Тест нужно остановить, когда достигнут заранее определённый размер выборки.

Один тест — одна метрика. Нельзя оптимизировать одновременно conversion rate и session length одним тестом. Если обе метрики растут — хорошо, но таргетная должна быть одна.

Novelty effect. Новый дизайн дает всплеск кликов на первой неделе просто потому что он новый. Для поведенческих тестов минимальный срок — 2 недели. Для retention-тестов — 4 недели.

Statsig для сложных экспериментов

Когда нужна более гибкая сегментация (тестируем только на пользователях из Москвы, у которых > 3 сессий):

// iOS Statsig SDK
import StatsigSDK

Statsig.initialize(sdkKey: "client-xxx") {
    let experiment = Statsig.getExperiment("checkout_flow_v2")
    let variant = experiment.getValue(forKey: "flow_type", defaultValue: "standard")

    if variant == "simplified" {
        self.showSimplifiedCheckout()
    } else {
        self.showStandardCheckout()
    }
}

// Android
val experiment = Statsig.getExperiment("checkout_flow_v2")
val flowType = experiment.getString("flow_type", "standard")

Statsig поддерживает Stratified Sampling — равномерное распределение пользователей по стратам (платформа, страна, план подписки). Без стратификации случайное распределение может создать когорты с разным составом, что искажает результаты.

Логирование экспозиции

Для корректного анализа важно логировать факт показа варианта — не только конверсию:

Analytics.logEvent("experiment_exposure", parameters: [
    "experiment_id": "checkout_cta_v2",
    "variant": variantName,
    "user_id": userId
])

Это позволяет анализировать конверсию только среди пользователей, которые реально видели эксперимент, а не всех участников.

Что входит в работу

• Выбор инструмента под задачи и стек (Firebase / Statsig / Amplitude Experiment)
• Интеграция SDK и настройка Remote Config / Feature Flags
• Реализация слоя A/B в коде с корректной обработкой вариантов
• Настройка целевых метрик и конверсионных событий
• Конфигурация размера выборки и длительности теста
• Логирование экспозиции для анализа

Сроки

Один A/B тест на Firebase Remote Config: 1–2 дня. Инфраструктура для регулярного A/B тестирования (Statsig/Growthbook): 3–5 дней. Стоимость рассчитывается индивидуально.