Интеграция Firebase A/B Testing в мобильное приложение
A/B тест в мобильном приложении — не просто показать двум группам разный экран. Нужно гарантировать стабильное попадание пользователя в одну группу между сессиями, корректно измерить конверсию, не замусорить аналитику событиями из-под нескольких экспериментов одновременно. Firebase A/B Testing решает это поверх Remote Config и Firebase Analytics без отдельной инфраструктуры.
Как работает эксперимент
Firebase A/B Testing — надстройка над Remote Config. Эксперимент создаётся в консоли: задаёте параметр Remote Config, контрольную группу (текущее значение) и варианты (новые значения). Firebase сам распределяет пользователей по группам на сервере, и при fetchAndActivate каждый получает своё значение параметра. На клиенте никаких изменений архитектуры — тот же код, что работает с Remote Config, работает и с A/B тестами.
Целевая метрика эксперимента — любое событие Firebase Analytics: purchase, screen_view, кастомный onboarding_completed. Консоль Firebase сама считает статистическую значимость и показывает байесовскую вероятность того, что вариант лучше контроля.
Типичные грабли при реализации
Несвоевременный activate. Если fetchAndActivate срабатывает уже после того, как пользователь увидел экран с контрольным вариантом, может произойти «перемигивание» — UI перестраивается на новый вариант прямо в сессии. Пользователь видит оба варианта, данные эксперимента загрязняются. Правило: применять конфиг до рендера целевого экрана, или принять политику «активация только при следующем холодном старте» — через fetch() без немедленного activate().
Пересечение экспериментов. Если два A/B теста меняют один и тот же экран — их результаты нельзя интерпретировать раздельно. Firebase позволяет запускать несколько экспериментов параллельно, но ответственность за отсутствие конфликтов — на команде. Нужна таблица активных экспериментов и их параметров.
Минимальный размер выборки. Firebase предупреждает о статистической незначимости, но команды часто останавливают эксперимент раньше, увидев «красивую цифру» на третий день. Для конверсий ниже 5% нужно минимум 500–1000 конверсий на группу. Иначе результат — шум.
Реализация на iOS
// Конфиг уже настроен через RemoteConfig
// В эксперименте параметр: "paywall_position" = "bottom" (контроль) / "center" (вариант)
remoteConfig.fetchAndActivate { [weak self] _, _ in
let position = RemoteConfig.remoteConfig()["paywall_position"].stringValue
DispatchQueue.main.async {
self?.paywallViewModel.position = position == "center" ? .center : .bottom
}
}
Логировать событие-триггер обязательно — Firebase A/B Testing использует его для отсечки «видел эксперимент»:
Analytics.logEvent("experiment_paywall_viewed", parameters: [
"variant": RemoteConfig.remoteConfig()["paywall_position"].stringValue ?? "unknown"
])
На Flutter (через firebase_remote_config)
final remoteConfig = FirebaseRemoteConfig.instance;
await remoteConfig.setConfigSettings(RemoteConfigSettings(
fetchTimeout: const Duration(seconds: 10),
minimumFetchInterval: const Duration(hours: 1),
));
await remoteConfig.fetchAndActivate();
final paywallPosition = remoteConfig.getString('paywall_position');
Что входит в работу
- Настройка Remote Config с параметрами под конкретный эксперимент
- Типизированный доступ к экспериментальным параметрам
- Интеграция с точкой запуска (до рендера целевого экрана)
- Настройка целевых событий в Firebase Analytics для измерения конверсии
- Консультация по дизайну эксперимента: гипотеза, метрика, минимальная выборка
Сроки
От 1 дня (если Remote Config уже подключён) до 3 дней (с нуля, включая аналитику и консультацию по методологии). Стоимость рассчитывается индивидуально.