Реализация A/B-тестирования сценариев бота в мобильном приложении

Реализация 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 недель.