Event Tracking в мобилните приложения: какво е, типове събития и как да настроим

Какво е Event Tracking?

Event Tracking — е процес на събиране, съхранение и анализ на дискретни действия на потребителя в приложението. Всяко събитие се състои от име (event_name) и набор от параметри (event_params). Например събитието purchase има параметри price, currency, product_id, quantity.

За разлика от Screen View, който отчита отварянето на екран, Event Tracking описва какво точно прави потребителят на този екран: натисна бутона „Купи", отвори количката, приложи промо код. Без събития е невъзможно да се разбере мотивацията и контекста на действията на потребителя.

Структура на събитие

Всяко Analytics Event съдържа задължителни и незадължителни полета. Задължителни: event_name, event_timestamp, user_id (или device_id). Незадължителни: параметри, описание на контекст.

Параметърът revenue е особено важен — предава се на MMP платформи за автоматично изчисляване на ROAS и LTV.

Типове събития в мобилната аналитика

Събитията се класифицират по произход и предназначение. Разделението помага за организиране на структурата от данни и задаване на права за достъп за различни екипи.

Автоматични събития (SDK)

SDK на аналитичните платформи автоматично събират базови събития: app_install, app_remove, session_start, screen_view. Firebase Analytics генерира около 20 автоматични събития без нито един ред код. Тези събития покриват основните метрики, но не дават разбиране на бизнес логиката.

Персонализирани събития (Custom Events)

Персонализираните събития — това, което прави Event Tracking ценен. Те описват бизнес действия: add_to_cart, start_subscription, level_complete, share_content, search_performed. Персонализираните събития изискват изрично изпращане от кода на приложението.

// Изпращане на персонализирано събитие към Firebase
val bundle = Bundle().apply {
    putString(AnalyticsParam.ITEM_ID, "prod_789")
    putString(AnalyticsParam.ITEM_NAME, "Premium Subscription")
    putString(AnalyticsParam.CURRENCY, "USD")
    putDouble(AnalyticsParam.PRICE, 29.99)
    putString(AnalyticsParam.SOURCE, "onboarding_screen")
}
FirebaseAnalytics.getInstance(this)
    .logEvent("subscribe_premium", bundle)

В примера събитието subscribe_premium съдържа четири контекстни параметъра. Параметърът source позволява да разберем от кой екран потребителят е направил абонамента — onboarding, настройки или paywall.

User Properties и Super Properties

Освен събития, Event Tracking включва User Properties — атрибути, прикрепени към потребителя: ниво на абонамент, държава, версия на приложението. User Property се изпраща веднъж и се прилага към всички последващи събития на сесията. Това позволява сегментиране на аналитиката без добавяне на параметри към всяко събитие.

Super Properties (Amplitude) или Global Properties (Mixpanel) — атрибути, прикрепени към сесията, а не към потребителя. Използват се за A/B тестове: variant_id като Super Property се добавя към всички събития в сесията и анализаторът вижда към коя група принадлежи потребителят.

Приходни събития

Приходните събития — отделен клас за записване на транзакции. Те съдържат сума, валута и тип покупка (абонамент, еднократна покупка, възстановяване). MMP платформите (AppsFlyer, Adjust) изискват приходни събития за изчисляване на ROAS.

Според данни на Branch (2024), приложенията, които правилно предават приходни събития на MMP, получават 25% по-точни данни за атрибуция и могат да оптимизират кампании на база LTV, а не CPI.

Как да настроим Event Tracking?

Настройката на Event Tracking преминава през три етапа: планиране на схема от събития, интеграция на SDK, валидация на данни.

Етап 1: Проектиране на схема от събития

Създайте Event Taxonomy — документ, в който е описано всяко събитие: име, параметри, тригер за изпращане, собственик. Пример за електронна търговия: order_completed → параметри: order_id, total_price, items_count, payment_method, shipping_city.

• Всяко събитие отговаря на въпроса: какво направи потребителят?
• Всеки параметър отговаря на въпроса: в какъв контекст?
• Избягвайте събития без параметри — те са безполезни за анализ

Етап 2: Интеграция на SDK

Свържете Analytics SDK към проекта. Firebase Analytics, Amplitude, Mixpanel — всяко SDK изисква инициализация в Application.onCreate(). Пример за Flutter:

import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsService {
  final _analytics = FirebaseAnalytics.instance();

  Future<void> logPurchase({
    required String productId,
    required double price,
    required String currency,
  }) async {
    await _analytics.logEvent(
      name: 'purchase_completed',
      parameters: {
        'product_id': productId,
        'price': price,
        'currency': currency,
        'timestamp': DateTime.now().millisecondsSinceEpoch,
      },
    );
  }
}

Класът AnalyticsService централизира изпращането на всички събития. Всеки метод съответства на бизнес действие. Това опростява намирането на изпращане — ако събитие не пристига, търсите по име на метода в кода. При мащабиране на проекта броят на методите може да нарасне до 50–100, но структурата остава четима благодарение на групирането по функционалност.

Етап 3: Валидация чрез DebugView

Firebase DebugView позволява да виждате събития в реално време на устройството на разработчика. Включете режима: adb shell setprop debug.firebase.analytics.app your.package. Всички събития ще се появят в конзолата на Firebase със закъснение под 5 секунди.

След включване на DebugView отворете приложението и изпълнете тестов сценарий — регистрация, покупка, преглед на каталог. В конзолата проверете: всички събития изпратени ли са, параметрите правилни ли са, няма ли дублиране. Amplitude предлага подобен инструмент — Amplitude Debugger за iOS и Android.

Автоматична валидация чрез CI/CD — следващото ниво на качество. Добавете скрипт към pipeline, който проверява дали всяко събитие от схемата е изпратено поне веднъж по време на тестовото изпълнение. Това предотвратява пускането на версии с липсващи събития и спестява време на QA инженерите.

Най-добри практики за именуване на събития

Именуването на събития — най-подценяваният аспект на Event Tracking. Неправилното име прави аналитиката безполезна, когато в проекта има повече от 50 събития.

Стандарт Object + Action

Използвайте модела object_action (малки букви, snake_case): product_added, cart_opened, payment_failed, subscription_cancelled. Обект — единица, действие — глагол в минало време. Чете се като изречение: „продукт добавен", „количка отворена".

• product_viewed, не „tap_on_product_card" (събитие — резултат, не действие)
• order_completed, не „successful_payment_transaction" (кратко и ясно)
• level_started, не „begin_level_with_parameters" (без излишни думи)

Забранени модели

НЕ използвайте интервали („Add to Cart"), CamelCase („AddToCart"), точка („add.to.cart"), тире („add-to-cart"). Повечето SDK препоръчват snake_case. НЕ използвайте имена на UI елементи („btn_submit_clicked") — събитието трябва да е бизнес, не техническо.

За префикс добавете име на функционалност или екран: onboarding_step_completed, checkout_payment_selected. Това позволява филтриране на събития по функционалност в отчетите.

Типове параметри на събитие

Параметрите се делят на три типа: string (стойност), number (число за агрегация), boolean (флаг). String параметрите съдържат категорийни данни: държава, източник на трафик, име на продукт. Number параметрите служат за метрики: цена, количество, продължителност. Boolean параметрите отбелязват състояние: is_trial, is_promo_applied.

Избягвайте предаването на обекти или масиви в един параметър — аналитичните платформи не могат да ги обработят. Вместо JSON низ в едно поле, предайте няколко плоски параметъра. Например вместо items_count_total предайте отделно items_count и total_price.

Платформи за Event Tracking

Изборът на платформа за Event Tracking зависи от мащаба на проекта и екипа. Нека разгледаме три варианта на различни нива.

Firebase Analytics (безплатно, до 500 събития)

Firebase — стандартен избор за стартъпи. Безплатен лимит — 500 различни event_name, неограничен брой параметри. Интеграция с BigQuery за персонализирана аналитика. Недостатъци: ограничена сегментация, липса на автоматично свързване на събития в сесии.

Amplitude (Pro от 1 000 USD/мес.)

Amplitude — платформа за продуктова аналитика. Поддържа Behavioural Cohorts, Funnel Analysis, Pathfinder. Позволява създаване на виртуални събития от комбинация на реални. Интегрира се с 50+ инструмента чрез Segment.

Segment (от 120 USD/мес.)

Segment — middleware за управление на събития. Изпращате събития на Segment, а той ги разпределя към 300+ инструмента. Полезен в enterprise, където едновременно се използват Firebase, Amplitude, Mixpanel, Braze и Salesforce.

PostHog (open-source алтернатива)

PostHog — open-source платформа за продуктова аналитика със собствен Event Tracking. Поддържа автоматично улавяне на събития, запис на сесии и feature flags. Разгръща се на собствен сървър, което е критично за проекти с GDPR или поверителни данни. Предлага API, съвместим с Python, за ETL тръбопроводи.

За Flutter проекти се препоръчва flutterfire_analytics + Amplitude чрез плъгина amplitude_flutter. За React Native — react-native-firebase + mixpanel-react-native.