Event Tracking in mobiele apps: wat het is, soorten gebeurtenissen en hoe in te stellen

Wat is Event Tracking?

Event Tracking — is het proces van het verzamelen, opslaan en analyseren van discrete gebruikersacties in de app. Elke gebeurtenis bestaat uit een naam (event_name) en een set parameters (event_params). Een purchase-gebeurtenis heeft bijvoorbeeld de parameters price, currency, product_id, quantity.

In tegenstelling tot Screen View, dat het openen van een scherm registreert, beschrijft Event Tracking wat de gebruiker precies op dat scherm doet: op de knop “Koop” klikken, de winkelwagen openen, een promotiecode toepassen. Zonder gebeurtenissen is het onmogelijk om de motivatie en context van gebruikersacties te begrijpen.

Structuur van een gebeurtenis

Elke Analytics Event bevat verplichte en optionele velden. Verplicht: event_name, event_timestamp, user_id (of device_id). Optioneel: parameters, contextbeschrijving.

De parameter revenue is bijzonder belangrijk — deze wordt doorgegeven aan MMP-platforms voor automatische berekening van ROAS en LTV.

Soorten gebeurtenissen in mobiele analyse

Gebeurtenissen worden geclassificeerd op basis van oorsprong en doel. De indeling helpt bij het organiseren van de gegevensstructuur en het toewijzen van toegangsrechten voor verschillende teams.

Automatische gebeurtenissen (SDK)

SDK van analyseplatforms verzamelen automatisch basisgebeurtenissen: app_install, app_remove, session_start, screen_view. Firebase Analytics genereert ongeveer 20 automatische gebeurtenissen zonder een enkele regel code. Deze gebeurtenissen dekken basismetrieken, maar geven geen inzicht in de bedrijfslogica.

Aangepaste gebeurtenissen (Custom Events)

Aangepaste gebeurtenissen — datgene wat Event Tracking waardevol maakt. Ze beschrijven bedrijfsacties: add_to_cart, start_subscription, level_complete, share_content, search_performed. Aangepaste gebeurtenissen vereisen expliciete verzending vanuit de app-code.

// Een aangepaste gebeurtenis naar Firebase sturen
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)

In het voorbeeld bevat de gebeurtenis subscribe_premium vier contextparameters. De parameter source maakt het mogelijk te begrijpen vanaf welk scherm de gebruiker het abonnement heeft afgesloten — onboarding, instellingen of paywall.

User Properties en Super Properties

Naast gebeurtenissen omvat Event Tracking User Properties — attributen die aan de gebruiker zijn gekoppeld: abonnementsniveau, land, app-versie. User Property wordt eenmaal verzonden en toegepast op alle volgende gebeurtenissen van de sessie. Dit maakt segmentatie van analyse mogelijk zonder parameters aan elke gebeurtenis toe te voegen.

Super Properties (Amplitude) of Global Properties (Mixpanel) — attributen die aan de sessie zijn gekoppeld, niet aan de gebruiker. Ze worden gebruikt voor A/B-testen: variant_id wordt als Super Property toegevoegd aan alle gebeurtenissen in de sessie, en de analist ziet tot welke groep de gebruiker behoort.

Revenue-gebeurtenissen

Revenue-gebeurtenissen — een aparte klasse voor het registreren van transacties. Ze bevatten het bedrag, de valuta en het type aankoop (abonnement, eenmalige aankoop, herstel). MMP-platforms (AppsFlyer, Adjust) hebben revenue-gebeurtenissen nodig voor de berekening van ROAS.

Volgens gegevens van Branch (2024) ontvangen apps die revenue-gebeurtenissen correct doorgeven aan MMP 25% nauwkeurigere attributiegegevens en kunnen ze campagnes optimaliseren op basis van LTV in plaats van CPI.

Hoe stel ik Event Tracking in?

Het instellen van Event Tracking verloopt in drie fasen: het plannen van het gebeurtenisschema, SDK-integratie en gegevensvalidatie.

Fase 1: Ontwerp van het gebeurtenisschema

Maak een Event Taxonomy — een document waarin elke gebeurtenis wordt beschreven: naam, parameters, verzendtrigger, eigenaar. Voorbeeld voor e-commerce: order_completed → parameters: order_id, total_price, items_count, payment_method, shipping_city.

• Elke gebeurtenis beantwoordt de vraag: wat heeft de gebruiker gedaan?
• Elke parameter beantwoordt de vraag: in welke context?
• Vermijd gebeurtenissen zonder parameters — ze zijn nutteloos voor analyse

Fase 2: SDK-integratie

Sluit Analytics SDK aan op het project. Firebase Analytics, Amplitude, Mixpanel — elke SDK vereist initialisatie in Application.onCreate(). Voorbeeld voor 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,
      },
    );
  }
}

De klasse AnalyticsService centraliseert het verzenden van alle gebeurtenissen. Elke methode komt overeen met een bedrijfsactie. Dit vereenvoudigt het zoeken naar verzending — als een gebeurtenis niet binnenkomt, zoek je op methodenaam in de code. Bij het schalen van het project kan het aantal methoden groeien tot 50–100, maar de structuur blijft leesbaar door groepering op functionaliteit.

Fase 3: Validatie via DebugView

Firebase DebugView maakt het mogelijk gebeurtenissen in realtime te bekijken op het apparaat van de ontwikkelaar. Schakel de modus in: adb shell setprop debug.firebase.analytics.app your.package. Alle gebeurtenissen verschijnen in de Firebase-console met een vertraging van minder dan 5 seconden.

Na het inschakelen van DebugView opent u de app en voert u een testscenario uit — registratie, aankoop, catalogus bekijken. Controleer in de console: zijn alle gebeurtenissen verzonden, zijn de parameters correct, is er geen duplicatie. Amplitude biedt een vergelijkbaar hulpmiddel — Amplitude Debugger voor iOS en Android.

Automatische validatie via CI/CD — het volgende kwaliteitsniveau. Voeg een script toe aan de pipeline dat controleert of elke gebeurtenis uit het schema ten minste één keer is verzonden tijdens de testrun. Dit voorkomt het uitrollen van versies met ontbrekende gebeurtenissen en bespaart tijd voor QA-ingenieurs.

Beste praktijken voor naamgeving van gebeurtenissen

Naamgeving van gebeurtenissen — het meest onderschatte aspect van Event Tracking. Een onjuiste naam maakt analyse nutteloos wanneer er meer dan 50 gebeurtenissen in het project zijn.

Standaard Object + Action

Gebruik het patroon object_action (kleine letters, snake_case): product_added, cart_opened, payment_failed, subscription_cancelled. Object — entiteit, actie — werkwoord in verleden tijd. Het leest als een zin: “product toegevoegd”, “winkelwagen geopend”.

• product_viewed, niet “tap_on_product_card” (gebeurtenis — resultaat, niet actie)
• order_completed, niet “successful_payment_transaction” (kort en duidelijk)
• level_started, niet “begin_level_with_parameters” (zonder overbodige woorden)

Verboden patronen

GEBRUIK NIET spaties (“Add to Cart”), CamelCase (“AddToCart”), punt (“add.to.cart”), koppelteken (“add-to-cart”). De meeste SDK raden snake_case aan. GEBRUIK GEEN namen van UI-elementen (“btn_submit_clicked”) — de gebeurtenis moet zakelijk zijn, niet technisch.

Voeg voor prefix de naam van de functionaliteit of het scherm toe: onboarding_step_completed, checkout_payment_selected. Dit maakt het mogelijk gebeurtenissen te filteren op functionaliteit in rapporten.

Soorten parameters van gebeurtenissen

Parameters worden onderverdeeld in drie typen: string (waarde), number (getal voor aggregatie), boolean (vlag). String-parameters bevatten categorische gegevens: land, verkeersbron, productnaam. Number-parameters dienen voor metrieken: prijs, hoeveelheid, duur. Boolean-parameters markeren de status: is_trial, is_promo_applied.

Vermijd het doorgeven van objecten of arrays in één parameter — analyseplatforms kunnen deze niet verwerken. Geef in plaats van een JSON-string in één veld meerdere platte parameters door. Bijvoorbeeld, geef in plaats van items_count_total afzonderlijk items_count en total_price door.

Platforms voor Event Tracking

De keuze van het platform voor Event Tracking hangt af van de schaal van het project en het team. Laten we drie varianten van verschillend niveau bekijken.

Firebase Analytics (gratis, tot 500 gebeurtenissen)

Firebase — de standaardkeuze voor startups. Gratis limiet — 500 verschillende event_name, onbeperkt aantal parameters. Integratie met BigQuery voor aangepaste analyse. Nadelen: beperkte segmentatie, geen automatische koppeling van gebeurtenissen in sessies.

Amplitude (Pro vanaf 1.000 USD/maand)

Amplitude — platform voor productanalyse. Ondersteunt Behavioural Cohorts, Funnel Analysis, Pathfinder. Maakt het mogelijk virtuele gebeurtenissen te creëren uit combinaties van echte. Integreert met meer dan 50 tools via Segment.

Segment (vanaf 120 USD/maand)

Segment — middleware voor het beheren van gebeurtenissen. U stuurt gebeurtenissen naar Segment en het distribueert ze naar meer dan 300 tools. Nuttig in enterprise, waar tegelijkertijd Firebase, Amplitude, Mixpanel, Braze en Salesforce worden gebruikt.

PostHog (open-source alternatief)

PostHog — open-source platform voor productanalyse met eigen Event Tracking. Ondersteunt automatische gebeurteniscaptatie, sessieregistratie en feature flags. Wordt op uw eigen server geïmplementeerd, wat cruciaal is voor projecten met GDPR of vertrouwelijke gegevens. Biedt een Python-compatibele API voor ETL-pijplijnen.

Voor Flutter-projecten wordt flutterfire_analytics + Amplitude via de plugin amplitude_flutter aanbevolen. Voor React Native — react-native-firebase + mixpanel-react-native.