Quali errori nella configurazione degli eventi fanno perdere ai team giorni di risoluzione problemi? Eventi duplicati che contano due volte la stessa azione. Eventi configurati per le pagine sbagliate. Parametri che catturano i valori sbagliati. Nomi incoerenti che creano confusione. Eventi che si attivano al momento sbagliato o per niente. Questi errori sono comuni perché la configurazione degli eventi è complessa. Ma sono anche evitabili. Capire cosa va storto ti aiuta a evitarlo.
Questo articolo tratta gli errori più comuni e come prevenirli.
Eventi duplicati
L'errore più comune è creare lo stesso evento due volte con nomi diversi. Uno sviluppatore crea "purchase". Un altro crea "purchase_conversion". Ora tracci la stessa azione due volte. I report mostrano due eventi. I team discutono su quale sia giusto.
Previeni i duplicati controllando il registro degli eventi prima di creare. Questo evento esiste già? Se sì, usa quello esistente. Se no, crealo con la convenzione di denominazione concordata.
Se scopri dei duplicati, elimina subito uno dei due. I duplicati attivi inquinano i tuoi dati.
Eventi configurati per le pagine sbagliate
Imposti un evento di invio modulo. Lo testi sul modulo di contatto. Funziona. Lo pubblichi. Ma si attiva su ogni pagina, non solo su quelle di contatto. La configurazione dell'evento è troppo ampia.
Previeni l'errore testando su più pagine. Testa la pagina in cui l'evento deve attivarsi. Testa le pagine in cui non deve. Verifica che si attivi solo dove previsto.
Documenta dove deve attivarsi ogni evento. Se più avanti noti che si attiva altrove, hai scoperto un errore di configurazione.
Parametri che catturano valori sbagliati
Un evento di acquisto ha un parametro che dovrebbe catturare l'importo dell'acquisto. Ma cattura il prezzo del prodotto. Simili ma non uguali. I dati sono sbagliati.
Previeni l'errore testando i parametri con valori noti. Fai un acquisto da $50. Verifica che il parametro mostri $50. Non $45. Non $55. Esattamente $50.
Documenta da dove ogni parametro prende i suoi dati. "L'importo dell'acquisto viene dal campo purchase_amount del data layer." Una documentazione chiara evita gli scambi.
Nomi degli eventi incoerenti
Un evento è "purchase". Un altro è "Purchase". Un altro è "purchase_event". Lo stesso evento ha tre nomi. I report mostrano tre eventi separati. Ne nasce confusione.
Previeni l'errore usando convenzioni di denominazione coerenti. Tutto minuscolo. Niente spazi. Trattini bassi tra le parole. Un solo standard. Applicalo a ogni evento.
Documenta il tuo standard di denominazione. Condividilo con chiunque crei eventi. Fai della coerenza la regola.
Eventi che non si attivano
Configuri un evento. Lo pubblichi. Non succede niente. Nessun evento nei report. L'evento non si attiva affatto.
Tra i motivi comuni ci sono una configurazione sbagliata del trigger (l'evento dovrebbe attivarsi quando qualcuno clicca un pulsante specifico, ma il trigger cerca l'elemento sbagliato), una configurazione sbagliata della pagina (l'evento dovrebbe attivarsi su una pagina specifica, ma il percorso della pagina è cambiato) o problemi di tempistica (l'evento si attiva prima che il data layer sia popolato).
Previeni l'errore testando a fondo prima della pubblicazione. Verifica la configurazione del trigger. Verifica il percorso della pagina. Verifica la tempistica. Testa in staging. Non pubblicare eventi non testati.
Eventi che si attivano troppo
Configuri un evento che si attiva quando qualcuno clicca un pulsante. Ma si attiva venti volte per clic. L'attivazione duplicata distorce i tuoi dati.
Tra i motivi comuni ci sono più listener per lo stesso evento (il tag manager e il tuo sito attivano entrambi lo stesso evento) o l'event bubbling (un clic su un elemento figlio attiva anche l'evento del genitore).
Previeni l'errore capendo il tuo trigger. Testa con cura. Cerca i duplicati. Monitora la frequenza di attivazione degli eventi. Se è insolitamente alta, indaga.
Valori dei parametri mancanti o sbagliati
Un evento di acquisto dovrebbe catturare l'importo dell'acquisto. Ma il parametro è vuoto. Oppure cattura il valore sbagliato. La qualità dei dati ne soffre.
Tra i motivi comuni ci sono un data layer non popolato (l'evento si attiva prima che il data layer abbia le informazioni), un errore di mappatura dei parametri (il parametro cerca il campo sbagliato del data layer) o valori fissi nel codice (un parametro ha un valore scritto a mano invece di prendere dati dinamici).
Previeni l'errore verificando che il data layer sia popolato prima che gli eventi si attivino. Testa i parametri con dati reali. Verifica che la mappatura sia corretta. Usa dati dinamici, non valori scritti a mano.
Non testare in produzione
Hai testato a fondo in staging. Gli eventi funzionano perfettamente. Pubblichi in produzione. Gli utenti segnalano subito che gli eventi non funzionano. Lo staging è diverso dalla produzione in modi che non ti aspettavi.
Previeni l'errore testando in produzione con una piccola percentuale di traffico. Parti dal 10%. Controlla gli errori. Se tutto funziona, sali al 50%. Poi al 100%. Un test di produzione su piccola scala scopre i problemi legati all'ambiente.
Non monitorare gli eventi dopo la pubblicazione
Pubblichi gli eventi. Passi al progetto successivo. Tre settimane dopo, qualcuno nota che un evento ha smesso di attivarsi. Hai perso tre settimane di dati.
Previeni l'errore monitorando gli eventi di continuo. Imposta degli avvisi. Se un evento non si attiva per un'ora, avvisa qualcuno. Controlla ogni settimana la frequenza di attivazione degli eventi. Individua i cambiamenti inattesi. Scopri i problemi in anticipo.
Domande frequenti
Come scopriamo gli eventi duplicati?
Documenta tutti gli eventi in un registro degli eventi. Prima di creare un evento, controlla il registro. Se esiste qualcosa di simile, riutilizzalo. Controlli periodici dell'elenco degli eventi scoprono i duplicati sfuggiti. Con il creatore di siti di WEMASY puoi impostarlo direttamente sul tuo sito.
Un evento si attiva ma la qualità dei dati è scarsa. Come facciamo il debug?
Controlla ogni componente. L'evento si attiva? Usa i report in tempo reale. Il trigger è corretto? Usa gli strumenti per sviluppatori. I parametri vengono catturati? Controlla i loro valori. Isola il componente sbagliato. Risolvilo. Testa di nuovo.
Abbiamo un evento rotto in produzione. Dovremmo eliminarlo o disattivarlo?
Disattivalo, non eliminarlo. Disattivare conserva i dati storici. Eliminare rimuove del tutto l'evento. Potresti voler analizzare i dati precedenti alla rottura. Conserva i dati. Disattiva l'evento solo da ora in poi.
Come evitiamo gli errori di configurazione?
Usa una configurazione standard degli eventi. Crea un modello. Ogni evento usa la stessa struttura. La standardizzazione riduce le variazioni. Meno variazioni significano meno errori.
Qual è il peggior errore nella configurazione degli eventi?
Pubblicare in produzione eventi non testati. Gli eventi non testati si rompono in silenzio. Non te ne accorgi per giorni. Nel frattempo hai perso dati. Testa sempre prima della produzione.
Come rimediamo agli errori di configurazione degli eventi?
Rispondendo in fretta. Quando noti un errore, correggilo subito. Disattiva l'evento rotto. Correggi la configurazione. Testa. Ripubblica. Più rapida è la risposta, meno dati sbagliati raccogli.