Інтеграція 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 днів (з нуля, включаючи аналітику та консультацію з методології). Вартість розраховується індивідуально.