Come monitorare la qualità dei dati: una guida dettagliata

Prevenire un errore nella raccolta dei dati è più facile che affrontarne le conseguenze. La sagacia delle tue decisioni aziendali dipende dalla qualità dei tuoi dati. In questo articolo ti spieghiamo come controllare la qualità dei dati in tutte le fasi della raccolta, dalla dichiarazione di lavoro ai report completati.

Sfortunatamente, molte aziende che spendono risorse sostanziali per archiviare ed elaborare i dati prendono ancora decisioni importanti basate sull'intuizione e sulle proprie aspettative anziché sui dati.

Perché succede? La sfiducia nei confronti dei dati è esacerbata da situazioni in cui i dati forniscono una risposta in contrasto con le aspettative del decisore. Inoltre, se qualcuno ha riscontrato errori nei dati o nei rapporti in passato, è incline a favorire l'intuizione. Questo è comprensibile, in quanto una decisione presa sulla base di dati errati potrebbe respingerti piuttosto che spostarti in avanti.

Immagina di avere un progetto multivaluta. Il tuo analista ha impostato Google Analytics in una valuta e l'operatore di marketing responsabile della pubblicità contestuale ha impostato l'importazione dei costi in Google Analytics in un'altra valuta. Di conseguenza, hai un ritorno sulla spesa pubblicitaria (ROAS) irrealistico nei rapporti delle tue campagne pubblicitarie. Se non noti questo errore in tempo, puoi disabilitare le campagne redditizie o aumentare il budget per quelle in perdita.

Inoltre, gli sviluppatori sono generalmente molto impegnati e l'implementazione dell'analisi web è un compito secondario per loro. Durante l'implementazione di nuove funzionalità, ad esempio un nuovo design per un'unità con accessori, gli sviluppatori potrebbero dimenticarsi di controllare che i dati vengano raccolti in Google Analytics. Di conseguenza, quando arriva il momento di valutare l'efficacia del nuovo design, si scopre che la raccolta dei dati è stata interrotta due settimane fa. Sorpresa.

Immagina di aver commesso un errore durante la fase di specifica. Se lo trovi e lo correggi immediatamente, la correzione sarà relativamente economica. Se l'errore viene rivelato dopo l'implementazione, durante la creazione di report o anche durante la presa di decisioni, il costo per risolverlo sarà molto elevato.

La raccolta dei dati consiste in genere in cinque passaggi chiave:

1. Formulare una sfida aziendale. Supponiamo di dover valutare l'efficienza di un algoritmo per selezionare le merci in un blocco di consigli.
2. L'analista o il responsabile della raccolta dei dati progetta un sistema di metriche da tracciare sul sito.
3. La persona configura Google Analytics e Google Tag Manager.
4. Quello invia i termini di riferimento per l'implementazione degli sviluppatori.
5. Dopo che lo sviluppatore ha implementato le metriche e impostato la raccolta dei dati, l'analista lavora con i report.

In quasi tutte queste fasi, è molto importante controllare i tuoi dati. È necessario testare la documentazione tecnica, le impostazioni di Google Analytics e Google Tag Manager e, naturalmente, la qualità dei dati raccolti sul tuo sito o nella tua applicazione mobile.

Prima di passare a ogni passaggio, diamo un'occhiata ad alcuni requisiti per il test dei dati:

• Non puoi testare senza strumenti. Come minimo, dovrai lavorare con la console per sviluppatori in un browser.
• Non ci sono risultati attesi in astratto. Devi sapere esattamente con cosa dovresti finire. Abbiamo sempre un certo insieme di parametri che dobbiamo raccogliere per qualsiasi interazione dell'utente con un sito. E sappiamo i valori che questi parametri dovrebbero assumere.
• È necessaria una conoscenza speciale. Come minimo, devi avere familiarità con la documentazione per gli strumenti di analisi web che utilizzi, la pratica e l'esperienza dei partecipanti al mercato.

Come accennato, è molto più semplice correggere un errore se lo si rileva nelle specifiche. Pertanto, il controllo della documentazione inizia molto prima della raccolta dei dati. Scopriamo perché abbiamo bisogno di controllare la tua documentazione.

Scopi della documentazione di prova:

• Correggi gli errori con poco sforzo. Un errore nella documentazione è solo un errore nel testo scritto, quindi tutto ciò che devi fare è apportare una rapida modifica.
• Prevenire la necessità di modifiche in futuro che potrebbero influire sull'architettura del sito/dell'applicazione.
• Proteggere la reputazione dell'analista. Uno strumento con errori di elaborazione potrebbe mettere in discussione la competenza di chi lo ha redatto.

Errori più comuni nelle specifiche:

1. Errori di battitura. Uno sviluppatore può copiare il nome dei parametri senza leggerli. Non si tratta di errori grammaticali o di ortografia, ma piuttosto di nomi errati di parametri o valori che questi parametri contengono.
2. Ignorare i campi durante il monitoraggio degli eventi. Ad esempio, un messaggio di errore può essere ignorato se un modulo non è stato inviato correttamente.
3. Nomi di campo non validi e mancata corrispondenza con lo schema di e-commerce avanzato. L'implementazione dell'e-commerce avanzato con una variabile dataLayer richiede una documentazione chiara. Pertanto, è meglio controllare tutti i campi due volte durante la stesura delle specifiche.
4. Non hai il supporto valutario per un sito multivaluta. Questo problema è rilevante per tutti i rapporti relativi alle entrate.
5. I limiti di hit non vengono presi in considerazione. Ad esempio, supponiamo che in una pagina del catalogo possano esserci fino a 30 prodotti diversi. Se trasferiamo le informazioni sulle visualizzazioni contemporaneamente per tutti i prodotti, è probabile che l'hit in Google Analytics non venga trasferito.

Il passaggio successivo dopo aver verificato la documentazione tecnica consiste nel controllare le impostazioni di Google Analytics e Google Tag Manager.

Perché testare le impostazioni di Google Analytics e Google Tag Manager?

• Assicurarsi che i parametri siano elaborati correttamente dai sistemi di raccolta dati. Google Analytics e Google Tag Manager possono essere configurati in parallelo con l'implementazione delle metriche sul tuo sito. E fino a quando l'analista non avrà terminato, i dati non verranno visualizzati in Google Analytics.
• Semplifica il test delle metriche incorporate nel sito. Dovrai concentrarti solo su una parte del lavoro dello sviluppatore. Nella fase finale di X, dovrai cercare la causa dell'errore direttamente sul sito, non nelle impostazioni della piattaforma.
• Basso costo di riparazione in quanto non è necessario coinvolgere gli sviluppatori.

Errori più comuni in Google Analytics:

1. Non è stata creata una variabile personalizzata. Ciò è particolarmente rilevante per gli account Google Analytics 360, che possono avere fino a 200 metriche e 200 parametri. In tal caso, è molto facile perderne uno.
2. L'ambito di accesso specificato non è valido. Non sarai in grado di rilevare questo errore durante la fase di revisione di dataLayer o rivedendo l'hit che stai inviando, ma quando crei il rapporto, vedrai che i dati non sembrano come previsto.
3. Ottieni un duplicato di un parametro esistente. Questo errore non influisce sui dati inviati, ma potrebbe causare problemi durante il controllo e la creazione di report.

Errori più comuni in Google Tag Manager:

1. Non sono stati aggiunti parametri, come il tag Universal Analytics o la variabile Impostazioni di Google Analytics.
2. L'indice nel tag non corrisponde al parametro in Google Analytics, creando il rischio che i valori vengano passati ai parametri sbagliati. Ad esempio, supponiamo di aver specificato l'indice del parametro del numero di utenti in GTM per il parametro di valutazione dell'articolo. È probabile che questo errore venga rilevato immediatamente durante la creazione di rapporti, ma non sarai più in grado di influenzare i dati raccolti.
3. Nome variabile specificato in dataLayer non valido. Quando crei un dataLayer, assicurati di specificare con quale nome verrà trovata la variabile nell'array dataLayer. Se si digita o si scrive un altro valore, questa variabile non verrà mai letta dal dataLayer.
4. Il monitoraggio e-commerce avanzato non è abilitato.
5. Il trigger di avvio non è configurato correttamente. Ad esempio, l'espressione regolare per l'attivazione di X è scritta in modo errato o è presente un errore nel nome dell'evento.

L'ultima fase del test è il test direttamente sul sito. Questa fase richiede maggiori conoscenze tecniche perché dovrai guardare il codice, controllare come è installato il container e leggere i log. Quindi è necessario essere esperti e utilizzare gli strumenti giusti.

Perché testare le metriche incorporate?

• Verificare che quanto implementato sia conforme alle specifiche e registrare eventuali errori.
• Verificare se i valori da inviare sono adeguati. Verificare che i parametri trasmettano i valori da trasmettere. Ad esempio, la categoria di merci non trasmette invece il suo nome.
• Fornire feedback agli sviluppatori sulla qualità dell'implementazione. Sulla base di questo feedback, gli sviluppatori possono apportare modifiche al sito.

Gli errori più comuni:

1. Non tutti gli scenari sono coperti. Ad esempio, supponiamo che un articolo possa essere aggiunto al carrello nella pagina del prodotto, del catalogo, della promozione o della pagina principale, ovvero ovunque sia presente un collegamento all'articolo. Con così tanti punti di ingresso, puoi perderti qualcosa.
2. L'attività non è implementata in tutte le pagine. Cioè, per alcune pagine o alcune partizioni/directory, i dati non vengono affatto raccolti o vengono raccolti solo parzialmente. Per prevenire tali situazioni, possiamo stilare una checklist. In alcuni casi, possiamo avere fino a 100 controlli per una funzione.
3. Non tutti i parametri sono implementati; ovvero, il dataLayer è implementato solo parzialmente.
4. Lo schema dataLayer per l'e-commerce avanzato è interrotto. Ciò è particolarmente vero per eventi come l'aggiunta di articoli al carrello, lo spostamento tra le fasi di pagamento e il clic sugli articoli. Uno degli errori più comuni nell'implementazione dell'e-commerce avanzato è la mancanza di parentesi quadre nell'array Prodotti .
5. Il dataLayer usa una stringa vuota invece di null o undefined per azzerare il parametro. In questo caso, i rapporti di Google Analytics contengono righe vuote. Se usi null o undefined, questa opzione non sarà nemmeno inclusa nell'hit che stai inviando.

Strumenti che utilizziamo per testare i dati:

• Estensione per Chrome del debugger di Google Analytics
• GTM Debugger, che puoi utilizzare per abilitare la modalità di anteprima in Google Tag Manager
• Il comando dataLayer nella console per sviluppatori
• La scheda Rete nella console per sviluppatori
• Estensione Google Tag Assistant per Chrome

Diamo un'occhiata più da vicino a questi strumenti.

Per iniziare, devi installare questa estensione nel tuo browser e abilitarla. Quindi apri l'ID pagina e vai alla scheda Console. Le informazioni visualizzate sono fornite dall'estensione.

Questa schermata mostra i parametri che vengono trasmessi con gli hit e i valori che vengono trasmessi per quei parametri:

C'è anche un blocco e-commerce esteso. Puoi trovarlo nella console come ec :

Inoltre, qui vengono visualizzati messaggi di errore, ad esempio per il superamento del limite di dimensione del colpo.

Se hai bisogno di controllare la composizione del dataLayer, il modo più semplice per farlo è digitare il comando dataLayer nella console:

Ecco tutti i parametri che vengono trasmessi. Puoi studiarli in dettaglio e verificarli. Ogni azione sul sito si riflette nel dataLayer. Diciamo che hai sette oggetti. Se si fa clic su un campo vuoto e si richiama nuovamente il comando dataLayer , nella console dovrebbe apparire un ottavo oggetto.

Per accedere a Google Tag Manager Debugger, apri il tuo account Google Tag Manager e fai clic sul pulsante Anteprima :

Quindi apri il tuo sito e aggiorna la pagina. Nel riquadro inferiore dovrebbe apparire un pannello che mostra tutti i tag in esecuzione su quella pagina.

Gli eventi aggiunti al dataLayer vengono visualizzati a sinistra. Cliccando su di essi è possibile verificare la composizione in tempo reale del dataLayer.

Caratteristiche del test del browser mobile:

• Su smartphone e tablet, i siti possono essere avviati in modalità adattiva oppure può esserci una versione mobile separata del sito. Se esegui la versione mobile di un sito sul desktop, sarà diversa dalla stessa versione sul telefono.
• In generale, le estensioni non possono essere installate nei browser mobili.
• Per compensare ciò, devi abilitare la modalità Debug nel tag Universal Analytics o nel codice di monitoraggio di Google Analytics sul sito.

Caratteristiche del test delle applicazioni mobili:

• L'utilizzo del codice dell'applicazione richiede maggiori conoscenze tecniche.
• Avrai bisogno di un server proxy locale per intercettare gli hit. Per tenere traccia del numero di richieste inviate da un dispositivo, puoi filtrare le richieste in base al nome dell'applicazione o dell'host a cui vengono inviate.
• Tutti i risultati vengono raccolti nel formato Protocollo di misurazione e richiedono un'elaborazione aggiuntiva. Una volta che gli hit sono stati raccolti e filtrati, devono essere copiati e analizzati nei parametri. Puoi utilizzare qualsiasi strumento conveniente per farlo: Hit Builder, formule in Fogli Google o un'app JavaScript o Python. Tutto dipende da cosa è più conveniente per te. Inoltre, avrai bisogno della conoscenza dei parametri del protocollo di misurazione per identificare gli errori negli hit inviati.

1. Collega il tuo dispositivo mobile al tuo laptop tramite USB.
2. Apri Google Chrome sul tuo dispositivo.
3. Nella Console per gli sviluppatori di Chrome, apri il rapporto Dispositivi remoti:

1. Conferma la connessione al tuo dispositivo facendo clic su OK nella finestra di dialogo. Quindi seleziona la scheda che desideri ispezionare e fai clic su Ispeziona .
2. Ora puoi lavorare con la console per sviluppatori in modalità standard, come nel browser. Avrai tutte le schede familiari: Console, Rete e altre.

1. Per lavorare con un'applicazione mobile, devi installare ed eseguire un server proxy. Consigliamo Carlo.
2. Una volta installato il server proxy, controlla a quale indirizzo IP si connette l'applicazione:

3. Quindi prendi il tuo dispositivo e configura la connessione Wi-Fi tramite il server proxy utilizzando la porta 8888. Questa è la porta utilizzata da Charles per impostazione predefinita.

4. Dopodiché, è il momento di raccogliere colpi. Tieni presente che nelle applicazioni, gli hit non vengono inviati alla raccolta ma al batch. Batch è una richiesta impacchettata che ti aiuta a inviare più richieste. Innanzitutto, consente di risparmiare risorse dell'applicazione. In secondo luogo, in caso di problemi di rete, le richieste verranno archiviate nell'applicazione e verrà inviato un pool comune non appena viene ristabilita la connessione di rete.

5. Infine, i dati raccolti devono essere analizzati (smontati) in parametri, verificati in ordine e confrontati con le specifiche.

Questo passaggio è il più semplice e veloce. Allo stesso tempo, assicura che i dati raccolti in Google Analytics abbiano un senso. Nei tuoi report puoi controllare centinaia di scenari diversi e guardare gli indicatori a seconda del dispositivo, del browser, ecc. Se trovi delle anomalie nei dati, puoi riprodurre lo script su un dispositivo specifico e in un browser specifico.

Puoi anche utilizzare i report di Google Analytics per verificare la completezza dei dati trasferiti al dataLayer. Cioè, a seconda di ciascuno degli scenari, la variabile viene riempita, se sono presenti tutti i parametri, se i parametri assumono i valori corretti, ecc.

Vogliamo condividere i rapporti più utili (a nostro avviso). Puoi usarli come checklist per la raccolta dei dati:

• Rapporti sull'e-commerce:
  • Prestazioni del prodotto
  • Prestazioni elenco prodotti
  • Promozione interna
• Comportamento — Eventi — Eventi principali
• Acquisizione — Campagne — Analisi dei costi
• Rapporti personalizzati: ad esempio, uno che mostra gli ordini duplicati

Vediamo come appaiono questi rapporti nell'interfaccia e a quali di questi rapporti devi prestare attenzione per primo.

La scheda più preziosa in questo rapporto è il comportamento di acquisto. Analizza la completezza della raccolta dei dati in ogni fase dell'e-commerce avanzato. Cioè, possiamo vedere se Google Analytics trasferisce le visualizzazioni dell'elenco dei prodotti, i clic, le visualizzazioni dei dettagli del prodotto, l'aggiunta/cancellazione di prodotti al/dal carrello e gli acquisti stessi.

A cosa dovremmo prestare attenzione qui? Innanzitutto, è molto strano se hai zero valori in una qualsiasi delle colonne. In secondo luogo, se in una fase hai più valori rispetto alla fase precedente, è probabile che tu abbia problemi a raccogliere i dati. Ad esempio, supponiamo che il numero di acquisti unici di un articolo sia maggiore del numero di checkout. È strano e vale la pena prestare attenzione.

Puoi anche passare da un altro parametro in questo rapporto, che dovrebbe essere inviato anche all'e-commerce avanzato. Ad esempio, se selezioni Categoria articolo come opzione principale, potresti vedere che ci sono vendite per determinate categorie di articoli ma non ci sono visualizzazioni per questi articoli, nessuna aggiunta al carrello, ecc.

Prima di tutto, è necessario esaminare tutti i parametri che vengono trasmessi a Google Analytics e vedere quali valori assume ciascun parametro. Di solito è subito chiaro se va tutto bene. Analisi più dettagliate per ciascuno degli eventi possono essere eseguite in report personalizzati.

Un altro report standard che può essere utile per controllare l'importazione dei dati di spesa in Google Analytics è l'analisi dei costi.

Vediamo spesso rapporti in cui ci sono spese per qualche fonte o campagna pubblicitaria ma non ci sono sessioni. Ciò può essere causato da problemi o errori nei tag UTM. In alternativa, i filtri di Google Analytics possono escludere sessioni da una determinata fonte. Questi rapporti devono essere controllati di volta in volta.

Vorremmo evidenziare il report personalizzato che consente di tenere traccia delle transazioni duplicate. È molto semplice da configurare: il parametro deve essere un ID transazione e la dimensione chiave deve essere transazioni.

Tieni presente che quando nel rapporto sono presenti più transazioni, ciò significa che le informazioni sullo stesso ordine sono state inviate più di una volta.

Se trovi un problema simile, leggi queste istruzioni dettagliate su come risolverlo.

Google Analytics ha un ottimo strumento di avvisi personalizzati che ti consente di tenere traccia di modifiche importanti senza visualizzare i rapporti. Ad esempio, se smetti di raccogliere informazioni sulle sessioni di Google Analytics, puoi ricevere una notifica via email.

Ti consigliamo di impostare le notifiche per almeno queste quattro metriche:

• Numero di sessioni
• Frequenza di rimbalzo
• Reddito
• Numero di transazioni

Nella nostra esperienza, questo è il compito più difficile e dispendioso in termini di tempo: la linea ristretta in cui gli errori sono i più comuni.

Per evitare problemi con l'implementazione di dataLayer, i controlli devono essere eseguiti almeno una volta alla settimana. In generale, la frequenza dovrebbe dipendere dalla frequenza con cui implementi le modifiche sul sito. Idealmente, è necessario testare il dataLayer dopo ogni modifica significativa. L'operazione manuale richiede molto tempo, quindi abbiamo deciso di automatizzare il processo.

Per automatizzare i test, abbiamo creato una soluzione basata su cloud che ci consente di:

• Verifica se la variabile dataLayer sul sito corrisponde al valore di riferimento
• Verifica la disponibilità e la funzionalità del codice di Google Tag Manager
• Verifica che i dati vengano inviati a Google Analytics e OWOX BI
• Raccogli i rapporti sugli errori in Google BigQuery

Vantaggi dell'automazione dei test:

• Aumenta significativamente la velocità di test. Secondo la nostra esperienza, puoi testare migliaia di pagine in poche ore.
• Ottieni risultati più accurati, poiché il fattore umano è escluso.
• Riduci il costo dei test, poiché hai bisogno di meno specialisti.
• Aumenta la frequenza dei test, poiché puoi eseguire test dopo ogni modifica al sito.

Uno schema semplificato dell'algoritmo che utilizziamo:

Quando accedi alla nostra app, devi specificare le pagine che desideri verificare. Puoi farlo caricando un file CSV, specificando un collegamento alla mappa del sito o semplicemente specificando l'URL del sito, nel qual caso l'applicazione troverà la mappa del sito stessa.

Quindi è importante specificare lo schema dataLayer per ogni scenario da testare: pagine, eventi, script (una sequenza di azioni, ad esempio per il checkout). Quindi puoi utilizzare le espressioni regolari per specificare che i tipi di pagina corrispondono all'URL.

Dopo aver ricevuto tutte queste informazioni, la nostra applicazione esegue tutte le pagine e gli eventi come programmato, controlla ogni script e carica i risultati dei test su Google BigQuery. Sulla base di questi dati, impostiamo e-mail e notifiche Slack.

PS Se hai bisogno di un audit completo del sito web, puoi richiedere servizi di consulenza a OWOX BI. Iscriviti per una demo e discuteremo delle possibilità.