Monitoraggio reinventato

Vediamo tutti l'evoluzione nelle aree tecnologiche (IA, piattaforme senza codice ecc.). È tempo di evolvere gli eventi che monitoriamo.

Dopo il mio post Iniziare con il perché volevo darti una nuova prospettiva sull'invio di eventi che ti aiuterà a capirne di più.

In qualità di product manager, abbiamo bisogno di iniziare a considerare gli eventi come azioni e capire perché gli utenti hanno compiuto quell'azione e dare un contesto a ciascun evento piuttosto che inviare semplicemente eventi di vanità che mi consentono di vedere solo un numero.

Lavorare con i clienti mi permette di vedere la differenza che fa una volta che inizi a porre quelle domande più complesse. All'improvviso puoi scoprire il vero motivo per cui gli utenti fanno o non fanno ciò che vuoi che facciano nel tuo prodotto.

Facciamo un esempio per Uber. Invece di tenere traccia degli scorrimenti e degli zoom della mappa (metrica di vanità), posso inviare un evento "ritiro selezionato" con una proprietà del metodo select e inviare come elenco ciò che hanno utilizzato per raggiungere il punto di ritiro. Hanno cercato e poi ingrandito, fatto scorrere e poi toccato? Se lo aggiungo improvvisamente sotto il mio evento principale, posso creare guasti che mi consentono di attingere davvero alle azioni dell'utente.

Ora possiamo vedere la media in base al conteggio dello zoom e al conteggio degli scorrimenti della mappa e comprendere la distribuzione degli utenti e il modo in cui influisce sul tempo di ordinazione.

Solo un consiglio che è super cruciale. Provalo prima di rivolgerti agli sviluppatori, assicurati che i dati siano utilizzabili

Per fare ciò, di solito creo un progetto di test e utilizzo l'API di importazione per inviare un singolo evento e vedere che posso interrogare come mi aspettavo.

Puoi persino utilizzare il "costruttore" per farlo facilmente all'interno dell'interfaccia utente della documentazione

https://developer.mixpanel.com/reference/import-events