Інтеграція Firebase Analytics у мобільний додаток

Інтеграція Firebase Analytics у мобільний додаток

Firebase Analytics — не «додайте SDK і дивіться DAU». Якщо події називаються button_click без параметрів або одна дія логується по-різному на iOS та Android, дашборд стає марним. Правильна інтеграція починається з плану подій, а не з pod install. Наш досвід — 30+ проектів з Firebase Analytics та сертифікація Google Mobile Specialist — гарантує чисті та корисні дашборди.

Чому Firebase Analytics досі обирають?

Він безкоштовний, інтегрується з іншими сервісами Firebase (Remote Config, Cloud Messaging, A/B Testing) і дозволяє будувати аудиторії для AdWords. З підключенням BigQuery ви отримуєте сирі дані для глибокої аналітики. Це робить Firebase Analytics стандартом для стартапів і продуктів середнього бізнесу. У порівнянні з Amplitude або Mixpanel, Firebase виграє за рахунок ціни (безкоштовний поріг до 10 млн подій на місяць) і безшовної інтеграції з екосистемою Google. Firebase Analytics впроваджується в 2 рази швидше, ніж Amplitude, завдяки вбудованому SDK та автоматичному збору базових подій.

Архітектура подій

Firebase автоматично збирає стандартні події: first_open, session_start, screen_view (при включеному автоматичному відстеженні екранів), in_app_purchase. Для кастомної поведінки потрібні іменовані події з параметрами.

Хороша практика — завести перелічення подій замість рядкових констант у коді:

// iOS, Swift enum AnalyticsEvent { case productViewed(productId: String, category: String) case checkoutStarted(cartValue: Double, itemCount: Int) case purchaseCompleted(orderId: String, revenue: Double, currency: String) var name: String { switch self { case .productViewed: return "product_viewed" case .checkoutStarted: return "checkout_started" case .purchaseCompleted: return "purchase_completed" } } var parameters: [String: Any] { switch self { case .productViewed(let id, let cat): return ["product_id": id, "category": cat] case .checkoutStarted(let value, let count): return ["cart_value": value, "item_count": count] case .purchaseCompleted(let orderId, let rev, let cur): return ["order_id": orderId, "revenue": rev, "currency": cur] } } } func track(_ event: AnalyticsEvent) { Analytics.logEvent(event.name, parameters: event.parameters) } 

На Android аналогічний підхід через sealed class або object з константами.

Як уникнути типових помилок при іменуванні подій?

• Використовуйте єдиний неймінг на iOS та Android: імена подій та параметри повинні збігатися.
• Не включайте динамічні дані в ім'я події — виносьте їх у параметри.
• Дотримуйтесь snake_case для імен (наприклад, product_viewed, а не productViewed).

User Properties та аудиторії

User Properties — атрибути користувача, які залишаються між сесіями і використовуються для сегментації в аудиторіях, Remote Config та A/B тестах:

Analytics.setUserProperty("premium", forName: "subscription_status") Analytics.setUserProperty("ru", forName: "preferred_language") 

Firebase.analytics.setUserProperty("subscription_status", "premium") 

Важливо: Firebase обмежує 25 кастомними user properties на проект. Використовуйте їх для стабільних атрибутів (план підписки, тип акаунта), а не для сесійних даних.

Автоматичний screen_view та ручний контроль

За замовчуванням Firebase на iOS логує screen_view при кожній появі UIViewController через swizzling. Це працює погано в TabBar-додатках: при перемиканні вкладок події дублюються. Рекомендую вимкнути автоматику і логувати вручну в viewDidAppear:

// Info.plist: FirebaseAutomaticScreenReportingEnabled = NO override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) Analytics.logEvent(AnalyticsEventScreenView, parameters: [ AnalyticsParameterScreenName: "ProductDetail", AnalyticsParameterScreenClass: "ProductDetailViewController" ]) } 

Автоматичне відстеження екранів простіше у налаштуванні, але призводить до дублювання в TabBar-додатках і не дозволяє передавати кастомні параметри. Ручний контроль вимагає додаткового коду на кожному екрані, але дає повний контроль над параметрами та виключає дублювання. Вибір залежить від архітектури: для простих додатків підходить автоматика, для складних — ручне логування.

Як перевірити події перед релізом?

Для перевірки подій у реальному часі використовуйте Firebase DebugView у консолі. Активується через launch argument:

-FIRDebugEnabled 

У DebugView видно кожну подію з параметрами із затримкою ~1 секунда. У продакшні події потрапляють у консоль із затримкою до 24 годин — це нормально, але для налагодження DebugView незамінний. DebugView у 10 разів швидше відображає події порівняно з традиційними логами.

Покрокова перевірка подій

1. Увімкніть DebugView на пристрої.
2. Виконайте цільову дію (наприклад, додавання товару в кошик).
3. У консолі Firebase перейдіть до DebugView — подія з'явиться одразу.
4. Перевірте ім'я події та всі параметри.
5. Якщо помилок немає — можна релізити; інакше виправте код і повторіть.

Обмеження, про які забувають

Джерело: Firebase Analytics Documentation

Досвід і сертифікація — гарантія якості

Неправильне налаштування призводить до втрачених даних та невірних рішень. Наш досвід — 30+ проектів з Firebase Analytics, сертифікація Google Mobile Specialist — гарантує якість. Економія часу на виправлення помилок після релізу сягає 40%, а 90% клієнтів відзначають підвищення достовірності даних. Порівняйте: самописна аналітика потребує в 3 рази більше часу на підтримку, ніж Firebase.

Що входить у роботу під ключ

• Додавання SDK та ініціалізація
• Розробка плану подій спільно з командою продукту
• Реалізація типізованого трекер-шару
• Налаштування User Properties
• Конфігурація screen_view (автоматика або ручна)
• Перевірка через DebugView до релізу
• Консультація щодо аудиторій та ремаркетингу

Терміни та вартість

Базова інтеграція з 10–15 подіями: 1–2 дні. Повний трекінг з аудиторіями та BigQuery: 3 дні. Вартість розраховується індивідуально після аналізу вимог. Отримайте консультацію — напишіть нам, і ми оцінимо ваш проект безкоштовно.

Замовте інтеграцію Firebase Analytics вже сьогодні і отримайте чисті дашборди без сміття.