Реалізація A/B-тестування сценаріїв бота у мобільному додатку
Продакт хоче перевірити: який варіант приветствієння бота краще конвертує у покупку — «Привіт, чим я можу допомогти?» або «Покажу товари по вашому запиту відразу». A/B-тест на рівні UI — зрозуміла задача. Але бот — це не просто текст: це граф діалогу, набір intent'ів, логіка escalation на оператора. A/B-тест сценаріїв бота вимагає окремої інфраструктури.
Що тестуємо у боті
Сценарії бота відрізняються від UI-елементів: варіант — це не колір кнопки, а цілий граф діалогу. Користувач може пройти 7 кроків у варіанті A й 3 кроки у варіанті B до одного результату. Метрика — не клік, а завершення цільової дії (покупка, заявка, вирішене питання). Це ускладнює вимірю й вимагає event-трекингу на кожному кроці діалогу.
Типові гіпотези для A/B на боті:
- Різні приветствія й tone of voice
- Quick replies vs введення тексту на першому кроці
- Момент пропозиції escalation до оператора (відразу vs після 2 неуспішних intent)
- Різні формулювання CTA всередину діалогу
Технічна реалізація
Firebase Remote Config — стандартний вибір для мобільних A/B-тестів. Параметри конфігурації бота (ID сценарію, версія prompt'а, поріг escalation) читаються на старті додатку:
let remoteConfig = RemoteConfig.remoteConfig()
remoteConfig.fetch(withExpirationDuration: 3600) { [weak self] status, error in
guard status == .success else { return }
remoteConfig.activate { _, _ in
let botVariant = remoteConfig["bot_scenario_variant"].stringValue ?? "control"
self?.chatViewModel.loadScenario(variant: botVariant)
}
}
Firebase автоматично розбиває аудиторію на групи, можна настроїти умови (країна, версія додатку, властивості користувача). Вбудована аналітика через Firebase Analytics — события конверсії помічаються стандартним logEvent.
Growthbook / Statsig — альтернативи з більш потужною статистичною моделлю. Growthbook open-source, можна деплоїти self-hosted. Statsig має гарний SDK для iOS/Android з низькою latency (feature flags кешуються локально).
Серверний A/B vs клієнтський. Якщо бот реалізований через серверний діалоговий рух (Rasa, Dialogflow CX, кастомний), краще управляти варіантом на сервері — клієнт передає userId + sessionId, сервер вибирає сценарій по експериментальній групі й повертає ответи потрібного варіанту. Це запобігає cheating й спрощує аналітику.
Event-трекинг діалогу
Без детального трекингу кожного кроку неможливо зрозуміти, де користувач ушов з воронки. Мінімальний набір подій:
-
bot_session_start— {variant, userId, sessionId} -
bot_message_sent— {variant, stepId, messageType} -
bot_message_received— {variant, stepId, intentId, confidence} -
bot_intent_failed— {variant, stepId, userInput} — коли NLU не розпізнав intent -
bot_escalated— {variant, stepId, reason} -
bot_goal_completed— {variant, goalType} — конверсійна подія
Всі события з variant й sessionId — це дає змогу відновити повний шлях користувача в будь-якому варіанті.
Статистична значимість
Основна помилка при A/B-тестах — зупиняти тест при перших обнадійливих числах. Потрібен мінімальний обсяг виборки, розраховуємий заздалегідь (power analysis): при бажаному ефекті 5%, базовій конверсії 15% й потужності тесту 80% — потрібно мінімум ~2800 користувачів у кожній групі. Firebase A/B Testing рахує це автоматично.
Орієнтири по строкам
Реалізація A/B-тестування двох варіантів сценарію з Firebase Remote Config й event-трекингом — 3–5 днів. Якщо потрібна інтеграція з серверним діалоговим рухом й більш складна логіка розбивки аудиторії — до 2 тижнів.