La differenza tra un team che si fida dei propri dati e uno che ne è sospettoso raramente sta nello strumento. Dipende dal modo in cui è stato implementato il tracciamento, con metodo o in fretta.
Implementare il tracciamento degli eventi sembra semplice: installa una libreria, attiva alcuni eventi, il gioco è fatto. Questo è il modo in cui vengono creati la maggior parte dei sistemi di analisi che nessuno può utilizzare in seguito. Eventi duplicati, nomi incoerenti, dati che non corrispondono e il sospetto cronico che il numero sia sbagliato.
Questo testo tratta il tracciamento per quello che è: un progetto di ingegneria e governance, con passaggi che contano e in un ordine che conta. La tesi è che implementarlo bene significa meno scrivere codice di tracciamento e più la disciplina prima e dopo.
Passo 1: il piano di misurazione viene prima del codice
L’errore fondamentale di quasi tutti i cattivi tracciamenti inizia con l’implementazione. Prima di una singola riga di codice, serve un piano di misurazione, un documento che colleghi ogni evento a una domanda aziendale.
Questo piano elenca cosa verrà monitorato, perché, quale decisione informa ciascun evento e quali proprietà comporta ciascuno. Sembra burocratico; è il contrario. È lui che evita di tenere il conto dell'inutile e di dimenticare l'essenziale.
Senza un piano, ogni sviluppatore si strumenta come meglio crede e ti ritrovi con un miscuglio di eventi che nessuno ha progettato insieme. Con un piano, il tracciamento ha un disegno e un disegno è ciò che rende i dati interpretabili in seguito.
Passo 2: standardizzare la nomenclatura e la struttura
Dopo aver definito cosa monitorare, il prossimo passo essenziale è decidere come nominare e strutturare il tutto, in modo coerente, prima di implementarlo.
Stabilisci una convenzione: come vengono denominati gli eventi, come vengono chiamate le proprietà, quale formato seguono i valori. Decidi se "acquisto completato dall'utente" è un evento con proprietà o più eventi distinti. Queste scelte, prese sulla carta, evitano la frammentazione che distrugge l'analisi.
Il motivo per farlo prima della codifica è semplice: correggere la nomenclatura in un secondo momento richiede la modifica dei dati storici e i dati storici non possono essere rinominati senza perdita. Ciò che standardizzi fin dall'inizio ti fa risparmiare mesi di rilavorazione. Ciò che lasci per dopo diventa un debito che potrebbe non essere mai saldato.
Passaggio 3: distribuzione con convalida, non al buio
Con un piano e uno standard pronti, l'implementazione è quasi meccanica, ma esiste un requisito: convalidare ogni evento man mano che arriva.
Il passaggio essenziale in questo caso è non fidarsi del fatto che l'evento si sia attivato solo perché il codice è stato scritto. Controlla che ogni evento arrivi con le giuste proprietà, al momento giusto, senza duplicazioni. I dati di tracciamento hanno una caratteristica insidiosa: gli errori sono silenziosi. Un evento che si attiva due volte o non si attiva affatto non genera un errore visibile; corrompe solo l'analisi in anticipo.
I team maturi trattano il monitoraggio come trattano qualsiasi codice critico: con la verifica. Un evento mal implementato che passa inosservato contaminerà le decisioni per mesi e nessuno lo saprà.
Step 4: stabilisci successivamente chi si prenderà cura dei dati
Il monitoraggio non è un progetto che finisce. I prodotti cambiano, le schermate vengono ridisegnate, i flussi vengono riscritti e ogni modifica può interrompere silenziosamente un evento.
Il passaggio che quasi tutti saltano è la definizione della governance continua: chi è responsabile di mantenere in esecuzione il monitoraggio, chi approva i nuovi eventi, chi esamina quando cambia una schermata. Senza un proprietario, il sistema di analisi si deteriora da solo. In sei mesi, metà degli eventi non significano più ciò che hanno detto di aver fatto.
Questa governance non deve necessariamente essere ingombrante. Ha bisogno di esistere. Un responsabile chiaro e un semplice rituale di revisione evitano già l’entropia che trasforma i dati attendibili in dati sospetti.
Passaggio 5: tratta la privacy come un requisito, non come una patch
L’implementazione del monitoraggio in Brasile richiede di trattare la LGPD come parte del progetto, dal piano di misurazione, e non come un aggiustamento dell’ultimo minuto.
Ciò significa decidere, evento per evento, quale sia la base giuridica per rilevare tale comportamento, per quanto tempo i dati vengono conservati e come verranno trattati qualora il titolare ne richieda la cancellazione. Significa anche non acquisire, all'interno delle proprietà dell'evento, dati sensibili che non dovrebbero essere presenti, un errore comune quando si registrano contenuti digitati o identificatori che non necessitavano di essere raccolti.
La privacy integrata nel piano è economica. La privacy patchata dopo un incidente è costosa e tardiva. Questo passaggio non è separato dagli altri; passa attraverso tutti.
Passaggio 6: documenta il significato, non solo il nome
C'è un passaggio che separa una traccia che sopravvive al turnover del personale da una che muore quando una persona chiave se ne va: documentare il significato di ogni evento, nel linguaggio umano.
Il nome dell'evento non è autoesplicativo. "Ordine confermato" può significare cose diverse per i diversi team, il momento del pagamento approvato, l'emissione della fattura, il momento della spedizione. Senza una definizione scritta, ognuno la interpreta a modo suo e le analisi basate su interpretazioni divergenti producono conclusioni che non concordano.
In azienda questa documentazione, spesso chiamata dizionario degli eventi, è ciò che permette a chi arriva dopo di capire cosa sta guardando. È anche ciò che evita la classica situazione in cui due aree riportano numeri diversi per lo "stesso" parametro e trascorrono giorni interi scoprendo che stavano misurando cose diverse. Documentare il significato costa poco al momento della creazione e ha un valore inestimabile sei mesi dopo.
Errori visualizzati quando si saltano i passaggi
Vale la pena nominare ciò che va storto, perché i sintomi sono riconoscibili. Quando si salta il piano di misurazione ci sono eventi che nessuno utilizza e mancano eventi che farebbero la differenza. Quando si salta la standardizzazione, l’analisi diventa archeologia. Quando la convalida viene saltata, le decisioni si basano su dati corrotti senza che nessuno se ne accorga. Quando la governance viene saltata, il sistema marcisce. Quando la privacy viene ignorata, il rischio legale si accumula.
Questi passaggi si rafforzano a vicenda. Un piano ben progettato facilita la standardizzazione, che a sua volta facilita la convalida, che supporta la governance, che incorpora già la privacy. Implementare il monitoraggio nell'ordine corretto non richiede più lavoro, ma meno rielaborazioni.
Alla fine, la qualità del tuo monitoraggio determina la qualità di ogni decisione che prenderai sulla base dei dati. Vale la pena farlo fin dal primo evento, perché sistemarlo in seguito è costoso e talvolta impossibile.
C’è un costo nascosto nel monitoraggio mal implementato di cui raramente si tiene conto: l’erosione della fiducia. Quando i conti non tornano nemmeno una volta, la squadra inizia a diffidare di tutti. Da quel momento in poi, le decisioni vengono prese ancora una volta in base all’istinto e l’intero investimento nell’analisi viene perso, non perché i dati siano spariti, ma perché nessuno ci crede più. Ricostruire quella fiducia è più difficile che costruire il monitoraggio la prima volta. Pertanto, ciascuno di questi passaggi è, in sostanza, un investimento in credibilità, e la credibilità dei dati è la risorsa più difficile da recuperare una volta persa.
Se il tuo team intende implementare o ripetere il monitoraggio e vuole evitare errori che minano la fiducia nei dati, vale la pena parlarne prima di iniziare a strumentare. Sul blog sono presenti altri testi su dati, metriche e governance che completano questi passaggi.