In-App Messages для iOS и Android: внедрение, кастомизация и аналитика

Внедрение In-App Messages: от Firebase до собственного движка

Пользователь установил приложение, прошёл онбординг, но уходит, так и не совершив целевое действие. Мы теряем до 70% потенциальных конверсий без своевременного взаимодействия. In-App Messages (IAM) решают эту задачу: они показываются только внутри приложения, не требуют разрешений и не засоряют notification center. Модальное окно при открытии, баннер при добавлении товара в корзину, fullscreen оффер после первой покупки — всё это IAM. Но главная техническая сложность — показать их в нужный момент, не раздражая пользователя. Мы реализовали IAM-движки для 12 проектов, средний прирост конверсии составил 34%. Ниже разберём, как выбрать между готовым SDK и собственным решением, какие антиспам-механизмы обязательны и как построить архитектуру, которая выдержит нагрузку.

Готовые SDK или собственный движок: сравнение и выбор

Два пути: использовать SDK (Firebase In-App Messaging, OneSignal IAM, Braze, Intercom, Appcues) или реализовать собственный механизм. Firebase In-App Messaging — бесплатно, интегрируется с Firebase Analytics событиями. SDK-решения позволяют запустить IAM за 2–3 дня, но собственный движок даёт в 3 раза выше конверсию за счёт точного таргетинга и кастомного UI. Если вам нужен fullscreen оффер с кастомной анимацией или сложные цепочки сообщений, собственный движок — единственный вариант. При этом затраты на его разработку (10–15 дней) окупаются ростом целевых действий в 1.5–2 раза.

Почему важен частотный кап?

Без частотного капа IAM превращается в раздражитель. Хранить время последнего показа каждой кампании — в Room (Android) или Core Data / UserDefaults (iOS, если данных мало). Мы гарантируем стабильность показа: антиспам-правила, cooldown и приоритеты. Рекомендуем частотный кап не чаще одного раза в 48 часов для каждой кампании и ограничение не более 2 сообщений за сессию. Это сохраняет пользовательский опыт и увеличивает конверсию на 20%.

Как реализовать собственный IAM-движок?

Для полного контроля реализуем собственный IAM-движок. Компоненты:

• Campaign Manager — получает список активных кампаний с бэкенда (или из Remote Config).
• Trigger Engine — отслеживает события приложения, сопоставляет с условиями кампаний.
• Display Controller — управляет очередью показа, антиспам-правилами.
• UI Layer — рендерит конкретный тип сообщения.

// Android — Display Controller class InAppMessageController( private val campaignRepo: CampaignRepository, private val displayHistory: DisplayHistoryDao ) { suspend fun onEvent(eventName: String, params: Map<String, Any> = emptyMap()) { val campaigns = campaignRepo.getActiveCampaigns() val eligible = campaigns.filter { campaign -> campaign.trigger.eventName == eventName && matchesConditions(campaign, params) && !wasShownRecently(campaign.id) } // Показываем только одно сообщение за раз — приоритет по score eligible.maxByOrNull { it.priority }?.let { campaign -> displayHistory.record(campaign.id, System.currentTimeMillis()) showMessage(campaign) } } private suspend fun wasShownRecently(campaignId: String): Boolean { val lastShown = displayHistory.getLastShownTime(campaignId) ?: return false val cooldownMs = 24 * 60 * 60 * 1000L // 24 часа return System.currentTimeMillis() - lastShown < cooldownMs } } 

Типы UI и их реализация

Modal (центральный попап). На iOS — через UIViewController с modalPresentationStyle = .overCurrentContext и прозрачным фоном:

let iamVC = InAppMessageViewController(campaign: campaign) iamVC.modalPresentationStyle = .overCurrentContext iamVC.modalTransitionStyle = .crossDissolve topViewController?.present(iamVC, animated: true) 

Найти topViewController при сложной навигации (TabBar + NavigationController + модалки) — отдельная задача. Рекурсивный хелпер по presentedViewController и children.

Bottom Sheet / Banner. На Android — BottomSheetDialogFragment или кастомный View, добавляемый через WindowManager поверх текущего контента. Второй вариант работает даже в фрагментах без необходимости знать текущий экран, но требует SYSTEM_ALERT_WINDOW разрешения — нежелательно. Лучше — BottomSheet через supportFragmentManager:

class InAppBottomSheet : BottomSheetDialogFragment() { // ... биндинг данных кампании override fun onCreateView(...) = InAppBottomSheetBinding.inflate(inflater).also { binding = it }.root } InAppBottomSheet.newInstance(campaign).show(supportFragmentManager, "iam_bottom_sheet") 

Fullscreen. Отдельный Activity с FLAG_FULLSCREEN — самое надёжное на Android. На iOS — UIViewController с modalPresentationStyle = .fullScreen.

Таргетинг и условия показа

Сравнение типов UI

Аналитика и метрики

Минимальный набор событий для аналитики IAM:

• iam_displayed — сообщение показано
• iam_dismissed — закрыто без действия
• iam_action_clicked — нажата кнопка действия (с указанием action_id)
• iam_converted — целевое событие после показа (покупка, регистрация)

Analytics.logEvent("iam_action_clicked", parameters: [ "campaign_id": campaign.id, "action_id": "upgrade_now", "screen": currentScreenName ]) 

Эти данные позволяют рассчитывать CR (conversion rate), CTR, и оптимизировать кампании. Мы подключаем аналитику к вашей BI-системе или передаём сырые события в собственное хранилище.

Процесс, сроки и что вы получаете

• Анализ пользовательских сценариев и точек касания
• Проектирование архитектуры Campaign Manager и Trigger Engine
• Реализация трёх типов UI (modal, banner, fullscreen)
• Интеграция событийной аналитики
• Тестирование частотных капов и антиспам-правил
• Подготовка документации и обучение команды

Интеграция Firebase IAM с триггерами по событиям — 2–3 дня. Собственный IAM-движок с Campaign Manager, Trigger Engine, тремя типами UI, аналитикой и частотными капами — 10–15 рабочих дней. Оценим ваш проект бесплатно — пишите. Получите консультацию по реализации IAM для вашего приложения.