Quali sono i componenti dei dati degli eventi?

Pubblicato: 2022-05-12

Questa è la quarta parte della serie in cinque parti sui dati dei clienti. Ecco le parti uno, due e tre.

I dati del cliente comprendono i dati dell'evento e i dati dell'entità: lo sai già se hai superato la prima parte (Che cosa sono i dati del cliente?).

In questa guida imparerai i componenti dei dati degli eventi, la convenzione di denominazione preferita per definire gli eventi, le categorie di dati di entità e i due tipi principali di entità.

Dati dell'evento

Dato che probabilmente hai acquistato roba online, iniziamo con un esempio di e-commerce.

Quando interagisci con un'app di e-commerce (web o mobile), in genere acquisti un prodotto aggiungendolo al carrello, procedendo alla cassa e completando il pagamento: questi sono eventi che esegui quando esegui il processo di acquisto di un articolo su l'applicazione.

Il percorso dell'acquirente, tuttavia, non è così semplice e ci sono molti altri eventi che possono aver luogo come:

  • Viene visualizzato un prodotto
  • Il carrello viene visualizzato
  • Un prodotto viene rimosso dal carrello
  • Viene applicato un coupon
  • Viene scelto un indirizzo
  • Viene scelto un metodo di pagamento
  • Un ordine è completato

E così via.

Vengono immediatamente in mente eventi comuni come Aggiungi al carrello, Procedi alla cassa ed Esegui pagamento , ma per comprendere il comportamento degli utenti, è necessario tenere traccia anche di altri eventi come quelli sopra menzionati.

La decisione di quali eventi tenere traccia e la denominazione degli eventi utilizzando una convenzione di denominazione appropriata sono i primi due passaggi nel processo di raccolta dei dati degli eventi.

Quali sono i prossimi due passaggi?

Felice che tu l'abbia chiesto!

Ogni evento è accompagnato da proprietà dell'evento (o attributi dell'evento ) che forniscono più contesto su un evento. Decidere quali proprietà associare a un evento e nominare tali proprietà sono i due passaggi successivi nel processo di raccolta dei dati dell'evento.

Cosa c'è in un nome?

Quando si tratta di dati, tutto.

Una corretta convenzione di denominazione o tassonomia è ciò che distingue i dati buoni da quelli non validi e consente alle parti interessate di capire cosa stanno guardando. Il mancato mantenimento di una tassonomia standardizzata, d'altra parte, è una delle principali cause di distorsione o rigonfiamento dei set di dati a causa della ridondanza.

Inoltre, quando si lavora con i dati dei clienti, non mantenere il maiuscolo uniforme durante la denominazione di eventi e proprietà degli eventi è uno dei più grandi errori che si possono fare, uno che può avere ramificazioni a lungo termine. Una buona convenzione di denominazione dovrebbe sempre essere accompagnata da rigide linee guida sull'involucro.

Ecco perché:

Aggiungi al carrello, aggiunto_al_carrello, prodotto aggiunto, aggiungi al carrello, aggiunto al carrello, prodotto aggiunto sono modi diversi per definire lo stesso evento.

Sebbene nessuno di questi sia di per sé sbagliato e non ci siano regole fisse quando si tratta di nominare eventi e proprietà, ci sono le migliori pratiche che dovresti considerare di seguire.

La convenzione di denominazione dell'oggetto-azione è praticamente diventata lo standard del settore e, per una buona ragione, descrive chiaramente l'azione che ha già avuto luogo. Prodotto aggiunto significa sicuramente che un oggetto (prodotto) è seguito da un'azione (aggiunta).

Ulteriori informazioni sull'impostazione di una tassonomia coerente per i tuoi eventi .

Componenti dei dati dell'evento

Esistono due componenti chiave di un evento: un'entità (una o più) e le proprietà dell'evento.

L'associazione di dati di entità come user_id a un evento fornisce informazioni sull'utente che ha eseguito l'evento.

In assenza di un identificatore univoco come user_id , i dati dell'evento rimarranno anonimi e non ci sarà modo di sapere chi ha eseguito tale evento. Allo stesso modo, nel contesto di B2B SaaS, in cui un utente può potenzialmente far parte di più organizzazioni , Organization_id deve essere associato agli eventi per sapere dove si svolgono gli eventi.

Oltre alle entità, ci sono altre informazioni che possono essere raccolte a scopo di analisi e segmentazione quando si verificano eventi.

Tornando all'esempio dell'e-commerce, quando un prodotto viene acquistato, oltre a sapere chi ha effettuato l'acquisto, devi almeno sapere anche quale prodotto è stato acquistato a quale prezzo e quando .

Queste informazioni aggiuntive vengono raccolte sotto forma di proprietà dell'evento .

Nella prima parte di questa serie, è stato menzionato che i dati degli eventi comprendono tre elementi chiave:

  • L'azione o l'evento che ha avuto luogo
  • Il timestamp o la data e l'ora precise in cui si è verificato l'evento
  • Lo stato o tutte le altre proprietà associate all'evento (note come proprietà dell'evento)

Diamo un'occhiata all'evento Product Added (il nome in Proper Case secondo il framework dell'azione oggetto per l'evento Add to Cart ) e supponiamo che sia stato eseguito da un utente il 1 gennaio 2020 alle 10:00 UTC. I dati raccolti al momento dell'evento sono i seguenti:

  • L'azione: Prodotto aggiunto
  • Il timestamp: 1577872800 (timestamp Unix per il ABZ 7.99 ( Lo stato: 0123 ABZ 7,99 ( Come in questo esempio, le proprietà associate all'evento Product Added sono user_id, product_id, price e quantity , ognuna delle quali fornisce ulteriori informazioni sull'evento. Il timestamp è associato all'evento per sapere quando si è verificato.

    È anche utile specificare un nome per il timestamp che è essenzialmente una proprietà dell'evento. Non è obbligatorio farlo in quanto la pratica standard consiste nell'associare il timestamp come timestamp a ogni evento quando si inviano dati a strumenti di terze parti; tuttavia, specificare un nome distinto per la proprietà che archivia il timestamp può essere utile a lungo termine quando è necessario lavorare con i dati di eventi storici.

    La tassonomia consigliata per i timestamp è il nome dell'evento seguito da "at": product_added_at per l'evento Product Added.

    Potresti aver già notato che snake_case viene utilizzato per definire le proprietà degli eventi, il che rende facile distinguere i nomi degli eventi dalle proprietà degli eventi. Detto questo, tieni presente che qui non ci sono regole predefinite e dovresti scegliere ciò che funziona meglio per te e il tuo team.

    Ecco uno sguardo finale alle proprietà associate all'evento Product Added e ai tipi di dati di ciascuna di queste proprietà:

    Esempio di dati evento 1

    La specifica del tipo di dati per ciascuna proprietà garantisce la coerenza dei dati e semplifica il processo di strumentazione.

    Nota a margine: è bene tenere presente che Ora dovrebbe essere chiaro che la raccolta dei dati sugli eventi comprende i seguenti passaggi:

    • Decidere quali eventi monitorare
    • Denominare quegli eventi usando una convenzione di denominazione adeguata
    • Decidere quali proprietà associare a ciascun evento
    • Assegnare un nome a queste proprietà utilizzando una convenzione di denominazione appropriata

    La prossima (e ultima) parte di questa serie copre il processo di decisione di quali eventi monitorare e quali dati raccogliere.

    Tuttavia, dovresti avere una buona idea di cosa aspettarti quando guardi i dati degli eventi (se in un piano di monitoraggio prima della strumentazione o all'interno di una destinazione dati come lo strumento di analisi del prodotto).

    Alcuni eventi comuni e le loro proprietà

    Prima di andare avanti, dai un'occhiata ad alcuni eventi e proprietà comuni che vengono monitorati dalla maggior parte dei prodotti tecnologici.

    Esempio di dati evento 2

    Tipi di entità

    È tempo di dare un'occhiata in profondità alle diverse entità e alle loro proprietà. Se non l'hai già fatto, consulta questa guida per capire in che modo i dati dell'entità sono correlati ai dati degli eventi.

    Nella prima parte di questa serie, è stato menzionato che i dati condivisi dagli utenti rientrano nei dati dell'entità. Sebbene ciò sia vero, non tutti i dati di entità sono condivisi dagli utenti stessi: è possibile generare anche dati di entità.

    I dati dell'entità comprendono le proprietà associate all'entità: se l'entità è Utente , tutte le informazioni su un utente vengono raccolte sotto forma di proprietà dell'utente.

    User_id viene generato per ogni utente per impostazione predefinita al fine di identificare gli utenti (e funge da identificatore per gli eventi).

    Detto questo, per il momento, dimentica gli eventi e pensa alle diverse informazioni che riguardano esclusivamente gli utenti e ti raccontano le loro caratteristiche.

    Tipi di dati di entità

    I dati dell'entità possono essere classificati nei seguenti bucket (menzionati anche nella parte 3 di questa serie):

    • Informazioni di identificazione personale come Dati demografici come Persona come Preferenze come Dati specifici del prodotto come I dati in ciascun bucket rientrano nelle proprietà dell'utente. In altre parole, le proprietà degli utenti memorizzano vari dettagli e caratteristiche degli utenti, consentendoti di identificarli e saperne di più su di loro.

      Sebbene la maggior parte delle informazioni provenga direttamente dall'utente, determinate proprietà dell'utente vengono generate automaticamente nel tempo come risultato dell'utilizzo del prodotto.

      Ma i dati degli eventi non vengono generati anche a causa dell'utilizzo del prodotto?

      Di sicuro lo è: le proprietà dell'utente sono dettagli aggiuntivi relativi a un evento raccolto quando si verifica l'evento. Diamo un'occhiata all'evento Signed Up e alle sue proprietà:

      Esempio di dati evento 3

      Come puoi vedere, tutte le proprietà associate a questo evento forniscono dettagli sugli utenti: dettagli che sono condivisi dagli utenti stessi ( nome, cognome, e-mail, telefono, paese ) o dettagli che vengono generati automaticamente ( sign_up_at, user_id ).

      È utile tenere presente quanto segue:

      • Alcuni eventi come Signed Up o La maggior parte delle proprietà degli utenti che escludono timestamp e identificatori sono soggette a modifiche. Un utente può modificare il proprio nome, e-mail, telefono, posizione, settore, ruolo lavorativo, ecc. Ma l'ora della registrazione (signed_up_at) o l'identificatore univoco (user_id) non possono essere modificati dall'utente.

      Proprietà utente e proprietà dell'organizzazione

      Con le app consumer, il tempo trascorso, i prodotti acquistati, i brani riprodotti o i video guardati sono proprietà associate all'utente memorizzate come proprietà dell'utente, i cui valori vengono costantemente aggiornati con un aumento dell'utilizzo.

      Nel contesto di B2B SaaS, Utente e Organizzazione sono le entità principali e gli eventi raccolti sono legati a un utente o un'organizzazione (o entrambi).

      Potrebbero esserci altre entità di gruppo come team o progetti a cui sono collegati determinati dati, come nel caso della maggior parte degli strumenti di produttività: il processo di raccolta dei dati dell'organizzazione è applicabile anche in questi casi.

      Diamo un'occhiata ad alcune proprietà utente comuni rilevanti per i prodotti SaaS B2B:

      Esempio di dati evento 5

      Quando un utente fa parte di un'organizzazione , molte informazioni importanti sono legate all'organizzazione e non all'utente.

      Alcune proprietà dell'organizzazione comuni (denominate anche proprietà di gruppo ) sono le seguenti:

      Esempio di dati evento 5

      È importante tenere presente che l' organization_id funge anche da identificatore e dovrebbe essere associato agli eventi per sapere in quale organizzazione ha avuto luogo un determinato evento.

      Tenere presenti le seguenti affermazioni può aiutare a distinguere tra proprietà utente e proprietà dell'organizzazione:

      • Ogni informazione che aiuta a definire le coorti di utenti, da dove provengono, chi sono, qual è il loro obiettivo o cosa fanno all'interno di un prodotto, viene archiviata come proprietà dell'utente .
      • Ogni informazione che aiuta a segmentare account o organizzazioni , il tipo di account, le entrate che genera, i prodotti o le funzionalità che utilizza, le risorse che consuma o il numero di utenti che ne fanno parte, viene archiviata come proprietà dell'organizzazione ( o proprietà di gruppo).

      Una volta che puoi distinguere tra quanto sopra, diventa facile inserire nuove entità (come team o progetti) nel mix.

      Prossimi passi

      Ora dovresti avere una chiara comprensione di come definire gli eventi e le loro proprietà associate, nonché specificare le proprietà di ciascuna entità (utente e organizzazione).

      Per iniziare a definire eventi e organizzare i tuoi dati oggi stesso, inizia con un account Amplitude gratuito.

      Guida all'ottimizzazione digitale