Event Tracking i mobilapplikationer: vad det är, typer av händelser och hur man konfigurerar

Vad är Event Tracking?

Event Tracking — är processen att samla in, lagra och analysera diskreta användarhandlingar i applikationen. Varje händelse består av ett namn (event_name) och en uppsättning parametrar (event_params). Till exempel har händelsen purchase parametrarna price, currency, product_id, quantity.

Till skillnad från Screen View, som registrerar att en skärm öppnas, beskriver Event Tracking exakt vad användaren gör på den skärmen: tryckte på knappen “Köp”, öppnade varukorgen, använde en kampanjkod. Utan händelser är det omöjligt att förstå användarens motivation och kontexten för deras handlingar.

Struktur för en händelse

Varje Analytics Event innehåller obligatoriska och valfria fält. Obligatoriska: event_name, event_timestamp, user_id (eller device_id). Valfria: parametrar, kontextbeskrivning.

Parametern revenue är särskilt viktig — den skickas till MMP-plattformar för automatisk beräkning av ROAS och LTV.

Typer av händelser i mobil analys

Händelser klassificeras efter ursprung och ändamål. Uppdelningen hjälper till att organisera datastrukturen och tilldela åtkomsträttigheter för olika team.

Automatiska händelser (SDK)

SDK från analysplattformar samlar automatiskt in grundläggande händelser: app_install, app_remove, session_start, screen_view. Firebase Analytics genererar cirka 20 automatiska händelser utan en enda rad kod. Dessa händelser täcker grundläggande mätvärden men ger ingen insikt i affärslogiken.

Anpassade händelser (Custom Events)

Anpassade händelser — det som gör Event Tracking värdefullt. De beskriver affärshandlingar: add_to_cart, start_subscription, level_complete, share_content, search_performed. Anpassade händelser kräver explicit sändning från applikationskoden.

// Skicka en anpassad händelse till 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)

I exemplet innehåller händelsen subscribe_premium fyra kontextparametrar. Parametern source gör det möjligt att förstå från vilken skärm använden gjorde prenumerationen — onboarding, inställningar eller paywall.

User Properties och Super Properties

Förutom händelser inkluderar Event Tracking User Properties — attribut kopplade till användaren: prenumerationsnivå, land, applikationsversion. User Property skickas en gång och tillämpas på alla efterföljande händelser i sessionen. Detta möjliggör segmentering av analys utan att lägga till parametrar till varje händelse.

Super Properties (Amplitude) eller Global Properties (Mixpanel) — attribut kopplade till sessionen, inte till användaren. Används för A/B-tester: variant_id som Super Property läggs till alla händelser i sessionen, och analytikern ser vilken grupp användaren tillhör.

Revenue-händelser

Revenue-händelser — en separat klass för registrering av transaktioner. De innehåller belopp, valuta och typ av köp (prenumeration, engångsköp, återställning). MMP-plattformar (AppsFlyer, Adjust) kräver revenue-händelser för beräkning av ROAS.

Enligt data från Branch (2024) får applikationer som korrekt skickar revenue-händelser till MMP 25% mer exakta attribueringsdata och kan optimera kampanjer baserat på LTV, inte CPI.

Hur konfigurerar man Event Tracking?

Konfiguration av Event Tracking sker i tre steg: planering av händelseschema, SDK-integration, datavalidering.

Steg 1: Design av händelseschema

Skapa en Event Taxonomy — ett dokument där varje händelse beskrivs: namn, parametrar, sändningsutlösare, ägare. Exempel för e-handel: order_completed → parametrar: order_id, total_price, items_count, payment_method, shipping_city.

• Varje händelse svarar på frågan: vad gjorde användaren?
• Varje parameter svarar på frågan: i vilket sammanhang?
• Undvik händelser utan parametrar — de är värdelösa för analys

Steg 2: SDK-integration

Anslut Analytics SDK till projektet. Firebase Analytics, Amplitude, Mixpanel — varje SDK kräver initiering i Application.onCreate(). Exempel för 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,
      },
    );
  }
}

Klassen AnalyticsService centraliserar sändningen av alla händelser. Varje metod motsvarar en affärshandling. Detta förenklar att hitta sändningen — om en händelse inte kommer in, söker du efter metodnamnet i koden. Vid skalning av projektet kan antalet metoder växa till 50–100, men strukturen förblir läsbar tack vare gruppering efter funktion.

Steg 3: Validering via DebugView

Firebase DebugView gör det möjligt att se händelser i realtid på utvecklarens enhet. Aktivera läget: adb shell setprop debug.firebase.analytics.app your.package. Alla händelser visas i Firebase-konsolen med en fördröjning på mindre än 5 sekunder.

Efter att ha aktiverat DebugView, öppna applikationen och utför ett testscenario — registrering, köp, bläddring i katalogen. I konsolen kontrollera: har alla händelser skickats, är parametrarna korrekta, finns det någon duplicering. Amplitude erbjuder ett liknande verktyg — Amplitude Debugger för iOS och Android.

Automatisk validering via CI/CD — nästa kvalitetsnivå. Lägg till ett skript i pipeline som kontrollerar att varje händelse från schemat har skickats minst en gång under testkörningen. Detta förhindrar utrullning av versioner med saknade händelser och sparar tid för QA-ingenjörer.

Bästa praxis för namngivning av händelser

Namngivning av händelser — den mest underskattade aspekten av Event Tracking. Ett felaktigt namn gör analysen oanvändbar när det finns mer än 50 händelser i projektet.

Standard Object + Action

Använd mönstret object_action (gemener, snake_case): product_added, cart_opened, payment_failed, subscription_cancelled. Objekt — entitet, handling — verb i dåtid. Det läses som en mening: “produkt tillagd”, “varukorg öppnad”.

• product_viewed, inte “tap_on_product_card” (händelse — resultat, inte handling)
• order_completed, inte “successful_payment_transaction” (kort och tydligt)
• level_started, inte “begin_level_with_parameters” (utan onödiga ord)

Förbjudna mönster

ANVÄND INTE mellanslag (“Add to Cart”), CamelCase (“AddToCart”), punkt (“add.to.cart”), bindestreck (“add-to-cart”). De flesta SDK rekommenderar snake_case. ANVÄND INTE namn på UI-element (“btn_submit_clicked”) — händelsen bör vara affärsmässig, inte teknisk.

För prefix lägg till funktions- eller skärmnamnet: onboarding_step_completed, checkout_payment_selected. Detta möjliggör filtrering av händelser efter funktionalitet i rapporter.

Typer av händelseparametrar

Parametrar delas in i tre typer: string (värde), number (tal för aggregering), boolean (flagga). String-parametrar innehåller kategoriska data: land, trafikkälla, produktnamn. Number-parametrar används för mätvärden: pris, kvantitet, varaktighet. Boolean-parametrar markerar status: is_trial, is_promo_applied.

Undvik att skicka objekt eller arrayer i en parameter — analysplattformar kan inte tolka dem. Istället för en JSON-sträng i ett fält, skicka flera plana parametrar. Till exempel, istället för items_count_total, skicka separat items_count och total_price.

Plattformar för Event Tracking

Valet av plattform för Event Tracking beror på projektets skala och team. Låt oss överväga tre varianter på olika nivåer.

Firebase Analytics (gratis, upp till 500 händelser)

Firebase — standardvalet för startups. Gratis gräns — 500 olika event_name, obegränsat antal parametrar. Integration med BigQuery för anpassad analys. Nackdelar: begränsad segmentering, ingen automatisk koppling av händelser i sessioner.

Amplitude (Pro från 1 000 USD/mån)

Amplitude — plattform för produktanalys. Stöder Behavioural Cohorts, Funnel Analysis, Pathfinder. Möjliggör skapande av virtuella händelser från kombinationer av verkliga. Integreras med 50+ verktyg via Segment.

Segment (från 120 USD/mån)

Segment — middleware för hantering av händelser. Du skickar händelser till Segment och det distribuerar dem till 300+ verktyg. Användbart i enterprise där Firebase, Amplitude, Mixpanel, Braze och Salesforce används samtidigt.

PostHog (open-source-alternativ)

PostHog — open-source-plattform för produktanalys med eget Event Tracking. Stöder automatisk händelsefångst, sessionsinspelning och feature flags. Implementeras på egen server, vilket är avgörande för projekt med GDPR eller konfidentiell data. Erbjuder Python-kompatibelt API för ETL-pipelines.

För Flutter-projekt rekommenderas flutterfire_analytics + Amplitude via pluginamplitude_flutter. För React Native — react-native-firebase + mixpanel-react-native.