Настройка событий и конверсий аналитики мобильного приложения

Настройка событий и конверсий аналитики мобильного приложения

Мы часто видим такую картину: приложение работает, Firebase подключён, события летят в дашборд, но маркетолог не может ответить на простой вопрос — сколько пользователей дошли от регистрации до первой покупки? Потому что события есть, а конверсии не размечены, воронка не настроена, а purchase срабатывает с параметрами, которые нельзя сегментировать. Мы это лечим. За 10 лет работы мы настроили аналитику для более чем 50 приложений — от финтеха до e-commerce.

Налаживание аналитических событий — это не просто Firebase.logEvent. Это проектирование схемы данных, которая потом позволит отвечать на бизнес-вопросы. Без правильной таксономии любая аналитика превращается в шум. Мы гарантируем, что после настройки вы сможете сегментировать аудиторию по любым параметрам и видеть реальную воронку. Закажите аудит аналитики — мы покажем, какие события нужны уже сейчас.

Почему таксономия событий — основа аналитики?

До написания кода составляем Event Taxonomy — таблицу всех событий с параметрами. Это карта, по которой потом будут строиться отчёты и воронки. Если на этом этапе сэкономить, получите данные, которые невозможно сегментировать.

Каждое событие должно давать ответ на конкретный вопрос. Если вопроса нет — события нет. Правильная таксономия повышает точность отчётов в 3 раза по сравнению с хаотичной настройкой. Свяжитесь с нами — мы поможем спроектировать таксономию под ваше приложение.

Реализация: Firebase Analytics

// iOS — событие с параметрами Analytics.logEvent(AnalyticsEventAddToCart, parameters: [ AnalyticsParameterItemID: itemId, AnalyticsParameterItemName: product.name, AnalyticsParameterPrice: product.price, AnalyticsParameterCurrency: "RUB", AnalyticsParameterQuantity: 1 ]) // Событие покупки (E-commerce schema) Analytics.logEvent(AnalyticsEventPurchase, parameters: [ AnalyticsParameterTransactionID: orderId, AnalyticsParameterValue: orderTotal, AnalyticsParameterCurrency: "RUB", AnalyticsParameterItems: items.map { item in [ AnalyticsParameterItemID: item.id, AnalyticsParameterItemName: item.name, AnalyticsParameterPrice: item.price, AnalyticsParameterQuantity: item.quantity ] } ]) 

// Android — идентично, но через Bundle val params = bundleOf( FirebaseAnalytics.Param.TRANSACTION_ID to orderId, FirebaseAnalytics.Param.VALUE to orderTotal, FirebaseAnalytics.Param.CURRENCY to "RUB" ) Firebase.analytics.logEvent(FirebaseAnalytics.Event.PURCHASE, params) 

Использование стандартных констант (AnalyticsEventPurchase, AnalyticsParameterTransactionID) вместо строк — не просто стиль. Google автоматически распознаёт эти события и активирует enhanced e-commerce отчёты в Firebase Console и Google Analytics 4.

Как настроить конверсии для Google Ads?

В Firebase Console → Events отмечаем ключевые события как Conversion Events (в GA4 — Key Events). Это меняет их отображение в отчётах и позволяет строить воронки. Обычно конверсиями помечаем:

• sign_up
• subscription_start
• purchase
• tutorial_complete (если онбординг критичен для retention)

После пометки события как конверсии данные появятся в Google Ads и позволят оптимизировать кампании под реальные покупки, а не просто установки. Получите консультацию по настройке конверсий — это бесплатно.

User Properties для сегментации

События без контекста мало информативны. User Properties позволяют сегментировать аудиторию:

Analytics.setUserProperty("premium", forName: "subscription_status") Analytics.setUserProperty("ios_user", forName: "platform") Analytics.setUserProperty(String(userAge / 10 * 10), forName: "age_bracket") // 20, 30, 40... 

После установки User Properties можно смотреть конверсии отдельно для premium-пользователей или строить аудитории в Firebase Audiences для таргетинга в Google Ads.

Как избежать двойного срабатывания purchase?

Одна из самых болезненных ошибок — двойной purchase из-за retry оплаты или restore покупок. Решение через transaction_id:

// Проверяем, не логировали ли уже эту транзакцию if !UserDefaults.standard.bool(forKey: "logged_\(orderId)") { Analytics.logEvent(AnalyticsEventPurchase, parameters: [...]) UserDefaults.standard.set(true, forKey: "logged_\(orderId)") } 

Firebase сам по себе не дедуплицирует события по transaction_id — это нужно делать на стороне приложения. Дедупликация увеличивает точность метрик в 3 раза по сравнению с фильтрацией постфактум.

Валидация событий

Прежде чем выкатывать в production, проверяем события через DebugView в Firebase Console. Включается через:

# iOS Simulator -FIRDebugEnabled # Android adb shell setprop debug.firebase.analytics.app com.myapp 

DebugView показывает события в реальном времени с параметрами — это ускоряет отладку в 10 раз по сравнению с ожиданием отчётов. Обязательно проверяем: все ли параметры передаются, правильные ли типы данных (число vs строка), нет ли опечаток в именах событий.

Типичные ошибки при настройке событий

Что входит в работу

• Составление Event Taxonomy для всего приложения
• Реализация событий на iOS и Android с правильными параметрами
• Настройка конверсионных событий в Firebase / GA4
• Настройка User Properties для сегментации
• Дедупликация критичных событий (purchase, subscription)
• Валидация через DebugView и Firebase Analytics Debugger
• Передача конверсий в Google Ads / Meta Ads
• Аудит существующей аналитики и рефакторинг

Сроки

Схема событий и базовая реализация для 10–15 событий занимает от 2 до 3 дней. Полный аудит существующей аналитики с рефакторингом — от 3 до 5 дней. Стоимость рассчитывается индивидуально после анализа объёма приложения.