Event Tracking nelle app mobili: cos'è, tipi di eventi e come configurarlo

Cos'è l'Event Tracking?

L'Event Tracking è il processo di raccolta, archiviazione e analisi delle azioni discrete degli utenti in un'app. Ogni evento è composto da un nome (event_name) e da un insieme di parametri (event_params). Ad esempio, l'evento purchase ha i parametri price, currency, product_id, quantity.

A differenza del Screen View, che registra l'apertura di una schermata, l'Event Tracking descrive cosa l'utente fa esattamente su quella schermata: ha premuto il pulsante "Acquista", ha aperto il carrello, ha applicato un codice promozionale. Senza eventi, è impossibile comprendere la motivazione e il contesto delle azioni dell'utente.

Struttura di un evento

Ogni Analytics Event contiene campi obbligatori e facoltativi. Obbligatori: event_name, event_timestamp, user_id (o device_id). Facoltativi: parametri, descrizione del contesto.

Il parametro revenue è particolarmente importante — viene trasmesso alle piattaforme MMP per il calcolo automatico di ROAS e LTV.

Tipi di eventi nell'analisi mobile

Gli eventi sono classificati per origine e scopo. Questa suddivisione aiuta a organizzare la struttura dei dati e a impostare i diritti di accesso per diversi team.

Eventi automatici (SDK)

Gli SDK delle piattaforme analitiche raccolgono automaticamente eventi di base: app_install, app_remove, session_start, screen_view. Firebase Analytics genera circa 20 eventi automatici senza una singola riga di codice. Questi eventi coprono le metriche di base ma non forniscono comprensione della logica di business.

Eventi personalizzati (Custom Events)

Gli eventi personalizzati sono ciò che rende prezioso l'Event Tracking. Descrivono azioni di business: add_to_cart, start_subscription, level_complete, share_content, search_performed. Gli eventi personalizzati richiedono un invio esplicito dal codice dell'app.

// Invio di un evento personalizzato a 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)

Nell'esempio, l'evento subscribe_premium contiene quattro parametri di contesto. Il parametro source permette di capire da quale schermata l'utente ha attivato l'abbonamento — onboarding, impostazioni o paywall.

User Properties e Super Properties

Oltre agli eventi, l'Event Tracking include le User Properties — attributi legati all'utente: livello di abbonamento, paese, versione dell'app. Una User Property viene inviata una volta e si applica a tutti gli eventi successivi della sessione. Ciò consente di segmentare l'analisi senza aggiungere parametri a ogni evento.

Le Super Properties (Amplitude) o Global Properties (Mixpanel) sono attributi legati alla sessione, non all'utente. Utilizzate per i test A/B: variant_id viene aggiunto come Super Property a tutti gli eventi della sessione, consentendo all'analista di vedere a quale gruppo appartiene l'utente.

Eventi di revenue

Gli eventi di revenue sono una classe separata per la registrazione delle transazioni. Contengono importo, valuta e tipo di acquisto (abbonamento, acquisto singolo, ripristino). Le piattaforme MMP (AppsFlyer, Adjust) richiedono eventi di revenue per il calcolo del ROAS.

Secondo Branch (2024), le app che trasmettono correttamente gli eventi di revenue alle MMP ottengono dati di attribuzione più precisi del 25% e possono ottimizzare le campagne basandosi sul LTV anziché sul CPI.

Come configurare l'Event Tracking?

La configurazione dell'Event Tracking avviene in tre fasi: pianificazione dello schema eventi, integrazione dell'SDK, validazione dei dati.

Fase 1: Progettazione dello schema eventi

Create una Event Taxonomy — un documento che descrive ogni evento: nome, parametri, trigger di invio, responsabile. Esempio per e-commerce: order_completed → parametri: order_id, total_price, items_count, payment_method, shipping_city.

• Ogni evento risponde alla domanda: cosa ha fatto l'utente?
• Ogni parametro risponde alla domanda: in quale contesto?
• Evitate eventi senza parametri — sono inutili per l'analisi

Fase 2: Integrazione dell'SDK

Integrate l'SDK di analisi nel progetto. Firebase Analytics, Amplitude, Mixpanel — ogni SDK richiede l'inizializzazione in Application.onCreate(). Esempio per 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,
      },
    );
  }
}

La classe AnalyticsService centralizza l'invio di tutti gli eventi. Ogni metodo corrisponde a un'azione di business. Ciò semplifica la ricerca — se un evento non arriva, si cerca per nome del metodo nel codice. Con la scalabilità del progetto, il numero di metodi può arrivare a 50–100, ma la struttura rimane leggibile grazie al raggruppamento per funzionalità.

Fase 3: Validazione con DebugView

Firebase DebugView permette di vedere gli eventi in tempo reale sul dispositivo dello sviluppatore. Attivate la modalità: adb shell setprop debug.firebase.analytics.app your.package. Tutti gli eventi appaiono nella console Firebase con meno di 5 secondi di latenza.

Dopo aver attivato DebugView, aprite l'app ed eseguite uno scenario di test — registrazione, acquisto, navigazione catalogo. Verificate nella console: tutti gli eventi sono stati inviati, i parametri sono corretti, non ci sono duplicati. Amplitude offre uno strumento simile — Amplitude Debugger per iOS e Android.

La validazione automatica tramite CI/CD è il livello di qualità successivo. Aggiungete uno script alla pipeline che verifica che ogni evento dello schema sia stato inviato almeno una volta durante l'esecuzione del test. Ciò impedisce il rilascio di versioni con eventi mancanti e fa risparmiare tempo agli ingegneri QA.

Best practice per la denominazione degli eventi

La denominazione degli eventi è l'aspetto più sottovalutato dell'Event Tracking. Un nome sbagliato rende l'analisi inutile quando il progetto supera i 50 eventi.

Standard Object + Action

Usate il pattern object_action (minuscolo, snake_case): product_added, cart_opened, payment_failed, subscription_cancelled. L'oggetto è l'entità, l'azione è il verbo al passato. Si legge come una frase: "prodotto aggiunto", "carrello aperto".

• product_viewed, non "tap_on_product_card" (l'evento è il risultato, non l'azione)
• order_completed, non "successful_payment_transaction" (corto e chiaro)
• level_started, non "begin_level_with_parameters" (senza parole superflue)

Pattern vietati

NON usare spazi ("Add to Cart"), CamelCase ("AddToCart"), punti ("add.to.cart"), trattini ("add-to-cart"). La maggior parte degli SDK raccomanda snake_case. NON usare nomi di elementi UI ("btn_submit_clicked") — l'evento deve essere di business, non tecnico.

Aggiungete un prefisso con il nome della funzionalità o della schermata: onboarding_step_completed, checkout_payment_selected. Ciò consente di filtrare gli eventi per funzionalità nei report.

Tipi di parametri degli eventi

I parametri si dividono in tre tipi: string (valore), number (numero per aggregazione), boolean (flag). I parametri string contengono dati categorici: paese, fonte di traffico, nome prodotto. I parametri number servono come metriche: prezzo, quantità, durata. I parametri boolean indicano uno stato: is_trial, is_promo_applied.

Evitate di passare oggetti o array in un singolo parametro — le piattaforme analitiche non sanno analizzarli. Invece di una stringa JSON in un campo, passate più parametri piatti. Ad esempio, invece di items_count_total, passate items_count e total_price separatamente.

Piattaforme di Event Tracking

La scelta della piattaforma di Event Tracking dipende dalla scala del progetto e dal team. Consideriamo tre opzioni di diverso livello.

Firebase Analytics (gratuito, fino a 500 eventi)

Firebase è la scelta standard per le startup. Il limite gratuito è di 500 event_name diversi, numero illimitato di parametri. Integrazione con BigQuery per analisi personalizzate. Svantaggi: segmentazione limitata, nessun collegamento automatico degli eventi in sessione.

Amplitude (Pro da $1.000/mese)

Amplitude è una piattaforma di analisi di prodotto. Supporta Behavioural Cohorts, Funnel Analysis, Pathfinder. Permette di creare eventi virtuali da combinazioni di eventi reali. Si integra con oltre 50 strumenti tramite Segment.

Segment (da $120/mese)

Segment è un middleware per la gestione degli eventi. Inviate eventi a Segment, che li distribuisce a oltre 300 strumenti. Utile in ambienti enterprise dove Firebase, Amplitude, Mixpanel, Braze e Salesforce sono utilizzati simultaneamente.

PostHog (alternativa open-source)

PostHog è una piattaforma di analisi di prodotto open-source con il proprio Event Tracking. Supporta la cattura automatica degli eventi, la registrazione delle sessioni e i feature flags. Si distribuisce su un server proprio, il che è fondamentale per progetti soggetti a GDPR o con dati sensibili. Fornisce un'API compatibile con Python per pipeline ETL.

Per progetti Flutter, si consiglia flutterfire_analytics + Amplitude tramite il plugin amplitude_flutter. Per React Native — react-native-firebase + mixpanel-react-native.