Data layer: il contratto tra sito, analytics, advertising e sistemi di business

20 Settembre 2026 · Dati e misurazione

Il data layer è il modo concordato con cui il sito comunica che cosa è successo agli strumenti che misurano visite e richieste. Per il titolare, la domanda da fare al fornitore è molto concreta. Quando un cliente invia un modulo, possiamo sapere che la richiesta è stata ricevuta, a quale offerta si riferisce e che seguito ha avuto in azienda?

Questo collegamento va progettato. Il sito conosce l’esito del modulo; il programma di analisi raccoglie i segnali previsti; il CRM, cioè il sistema dove i commerciali seguono i contatti, contiene l’esito della trattativa. Il data layer aiuta questi strumenti a usare gli stessi significati. Da solo non li collega e non porta nuovi clienti. Il referente della misurazione è la persona, interna o esterna, che segue i rapporti di Google Analytics 4 (GA4) e delle campagne.

La richiesta che vuoi contare

Un produttore di serramenti riceve dal sito richieste di preventivo con le misure delle finestre. Prima di chiedere una modifica tecnica, il titolare deve decidere quale risultato vuole leggere nel rapporto. Può interessargli il preventivo per la sostituzione dei serramenti, distinto dal download di una brochure. Sono azioni diverse e devono poter essere riconosciute anche quando partono dalla stessa pagina.

Il cliente indica le misure, compila il modulo e preme il pulsante. Se manca un campo obbligatorio, il sito gli chiede di completarlo e non salva la richiesta. Chi conta il clic come richiesta ricevuta aggiunge al rapporto un contatto che il commerciale non ha ricevuto.

La conferma deve quindi arrivare dal sistema che accetta la richiesta. Il fornitore deve spiegare che cosa significa “accettata” nel tuo sito. Potrebbe essere il salvataggio nel sistema del sito, seguito da un invio al CRM che avviene dopo. I due momenti devono essere riconoscibili, soprattutto quando il secondo passaggio può fallire.

Quando serve un accordo dedicato sui dati

Questo lavoro è utile quando più piattaforme leggono gli stessi eventi, il sito ha moduli o cataloghi articolati e occorre collegare le richieste alle campagne e al CRM. Un altro segnale è dover riparare la misurazione dopo modifiche grafiche o traduzioni.

Google Tag Manager non sostituisce lo sviluppatore che conosce l’esito del modulo. La richiesta di preventivo deve mantenere un significato proprio, senza essere forzata nello schema di un acquisto online. Il titolare sceglie i campi che servono a capire le richieste.

Che cosa chiedere prima del preventivo tecnico

Porta al confronto con chi sviluppa il sito un modulo che usi davvero. Il responsabile commerciale spiega quali richieste l’azienda può seguire. Chi cura le campagne indica quale azione deve essere misurata. Lo sviluppatore mostra da dove arriva la conferma del salvataggio. Riserva 30 minuti prima del preventivo con il titolare, il commerciale e il fornitore. Il risultato è un accordo sul modulo da seguire e su che cosa conta come richiesta ricevuta.

Questo documento, che sviluppatore e referente della misurazione condividono, è il “contratto” del data layer. Chiedi che resti accessibile all’azienda. Per il modulo scelto, il fornitore deve consegnare una descrizione del momento in cui arriva la conferma. Deve indicare quali dati accompagnano la richiesta e quali valori possono assumere. Per ogni dato necessario va scritto come si comporta il sistema quando manca, compreso l’eventuale avviso. Il documento deve riportare anche il riferimento che permette di ritrovare la richiesta nel CRM. Sviluppo e misurazione devono condividere i nomi, i tipi di dato, le condizioni e le responsabilità, così un cambio di fornitore non obbliga a ricostruire tutto dalle schermate.

Un distributore di componenti deve tenere distinte la “richiesta di ricambio” e la “domanda di compatibilità”. Il documento precisa che cosa comprende ciascuna e come viene riconosciuta.

Le informazioni da distinguere nel documento

Una scheda prodotto, un catalogo e un modulo devono essere riconoscibili con un riferimento stabile. Un costruttore di confezionatrici può così distinguere una richiesta sulla macchina da una sui ricambi. Per un’area riservata possono servire riferimenti dell’azienda registrata o dell’ordine; vanno scelti solo quelli necessari e ammessi per la destinazione.

Lo stato dice che cosa è disponibile in quel momento, per esempio il catalogo visualizzato o la scelta sul consenso. Un nome come “interazione” lascia incerto che cosa sia accaduto. Il documento deve spiegare anche il formato dei valori, quali campi sono facoltativi e da quale versione sono disponibili.

Per un campo facoltativo assente, lo sviluppatore deve scegliere un comportamento riconoscibile e provarlo. Può omettere il campo o usare un valore vuoto concordato; il sistema che legge il messaggio deve interpretarlo nello stesso modo. Il collaudo controlla che un’informazione della richiesta precedente non venga attribuita alla successiva.

Dal sito alle statistiche e alle campagne

Un evento è un messaggio che descrive un fatto, come la ricezione del modulo. I parametri sono le informazioni che lo accompagnano, per esempio quale modulo è stato usato. Google Tag Manager, spesso abbreviato in GTM, gestisce i tag, piccoli codici che inviano dati alle destinazioni previste. Può leggere il data layer e attivare un tag quando riconosce un evento.

Google documenta questo funzionamento e raccomanda di mantenere coerenti i nomi delle variabili. Lo sviluppatore prepara il messaggio. Il referente della misurazione decide come leggerlo e dove inviarlo.

Per Google Analytics 4 esistono eventi raccomandati, tra cui generate_lead per l’invio di un modulo o di una richiesta. La scelta del nome sul sito e la corrispondenza con la destinazione spettano a chi configura il sistema. Il titolare deve poter leggere in italiano che cosa viene contato, senza dover interpretare nomi di codice.

Un evento ricevuto deve poi diventare un risultato leggibile nel rapporto. Chiedi al fornitore di mostrare dove compare la richiesta e di controllare che in Google Analytics 4, o GA4, sia configurata come “evento chiave”, cioè un’azione importante per l’azienda. L’eventuale conversione usata dalle campagne va verificata separatamente, nella configurazione e nei rapporti della pubblicità.

La richiesta di catalogo senza dati del cliente

Un visitatore chiede il catalogo. Il messaggio del sito può indicare quale modulo è stato usato, il tipo di documento e l’esito della richiesta. Un evento di avvio aiuta a capire dove si interrompe la compilazione; l’esito distingue la conferma dall’errore, con una categoria che non copia ciò che il visitatore ha scritto.

Il fornitore riporta nel documento la corrispondenza fra i nomi usati dal sito e i campi della piattaforma destinataria. Con una nuova piattaforma, il fornitore aggiorna la corrispondenza senza alterare il significato della richiesta.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'catalog_request_confirmed',
  form_id: 'catalogo',
  resource_type: 'catalog',
  result: 'success'
});

Il collegamento con il CRM ha un lavoro proprio

Un produttore di cavi elettrici riceve una richiesta di fornitura per un cablaggio. Il sito la salva e le assegna un codice interno. Il commerciale la apre nel CRM, approfondisce il materiale richiesto e decide se preparare l’offerta. L’evento del sito racconta l’inizio; le informazioni successive nascono nel lavoro commerciale.

Per collegare i passaggi, il fornitore deve spiegare dove viene generato il codice e come lo stesso riferimento arriva nel CRM. Il trasferimento della richiesta al gestionale va curato nel collegamento applicativo tra i sistemi, con i permessi previsti.

Un codice interno, da solo, non attribuisce una vendita a una campagna. Servono i riferimenti ammessi per riconoscere il percorso, una configurazione coerente e regole di trattamento dei dati adeguate. Alcuni percorsi resteranno incompleti. Il commerciale può inoltre ricevere una telefonata o una richiesta diretta dopo che il cliente ha visitato più volte il sito.

Google offre il Measurement Protocol, un sistema per inviare a Google Analytics eventi da altri sistemi, comprese interazioni avvenute fuori dal sito. La documentazione lo presenta come un’integrazione della raccolta ordinaria. Non basta attivarlo per ritrovare automaticamente in un rapporto tutte le trattative del CRM.

Prima di finanziare questo collegamento, il titolare e il responsabile commerciale devono accordarsi su che cosa significa richiesta pertinente. Per il produttore di cavi può contare che il materiale isolante e l’impiego siano compatibili con l’offerta. Il CRM deve contenere quell’esito in modo utilizzabile; una nota libera scritta ogni volta diversamente rende più difficile il confronto.

I dati del cliente seguono un percorso distinto

Il nome, l’email e le misure inviate servono a rispondere alla richiesta. Non per questo devono arrivare al programma che misura le visite. Google Analytics vieta l’invio di dati che Google possa riconoscere come informazioni personali, per esempio gli indirizzi email e i numeri di telefono personali. Il divieto riguarda anche informazioni finite per errore nell’indirizzo della pagina.

Chi sviluppa il modulo deve controllare la pagina di conferma e i messaggi d’errore. Un indirizzo web che contiene l’email del cliente può trasferirla alla misurazione anche quando i parametri dell’evento sono stati preparati correttamente. Il testo libero del modulo può contenere nomi e dettagli riservati della commessa.

Il codice interno della richiesta non va considerato anonimo solo perché manca il nome. Se permette di risalire a una persona attraverso altri archivi, chi lo usa deve valutarne il trattamento con chi segue la privacy. La scelta dei dati e delle destinazioni va condivisa con chi segue la privacy aziendale.

Consent Mode è il meccanismo con cui i tag Google adattano il comportamento alle scelte di consenso comunicate dal sito. Non raccoglie da solo quelle scelte. Il fornitore deve collegarlo alla soluzione usata per il consenso e provare i comportamenti previsti, prima della pubblicazione e dopo una modifica del banner.

Il data layer può essere letto dagli script presenti nella pagina. Un dato utile al CRM non è per questo adatto a tutti i codici di misurazione. I responsabili devono concordare gli accessi e le destinazioni.

Il collaudo deve arrivare fino alla destinazione

Prima del rilascio, chiedi allo sviluppatore, al referente della misurazione e al responsabile CRM una dimostrazione sul modulo scelto e un verbale delle prove. Lo sviluppatore esegue una richiesta valida. Il referente della misurazione mostra il segnale ricevuto dalla destinazione; il responsabile commerciale controlla il contatto nel CRM.

La stessa dimostrazione deve comprendere un invio rifiutato. Poi vanno provati il doppio clic e il ricaricamento della conferma. Il risultato atteso dipende da come il sito riconosce una richiesta unica. Il verbale indica quale componente gestisce il nuovo tentativo dopo un errore di rete e come riconosce la richiesta già registrata.

Le prove devono coprire il consenso dato, quello negato e la scelta modificata durante la visita. Per ciascuna situazione il verbale affianca il comportamento atteso dalla configurazione concordata e quello osservato. Il referente della misurazione controlla quali segnali partono e che cosa riceve ogni destinazione. Il consenso negato non blocca sempre ogni invio. Nella modalità avanzata di Consent Mode, i tag Google possono trasmettere misure senza cookie; il risultato atteso va definito sulla modalità effettivamente adottata.

Va provato anche il caso in cui il sito salva la richiesta e il CRM non la riceve. Lo sviluppatore mostra come il sistema riconosce l’invio rimasto in sospeso e avvisa il responsabile CRM. Quest’ultimo segue il recupero con il fornitore, usando il riferimento della richiesta per evitare di creare un secondo contatto per lo stesso invio. La prova termina quando la richiesta è recuperata e il conteggio non è stato duplicato.

I casi limite da far provare

Nel documento del modulo servono esempi validi e non validi: una richiesta con i valori concordati e una che li viola. Il collaudo deve riconoscere la differenza.

• Il visitatore cambia pagina prima della risposta. Lo sviluppatore mostra come viene riconosciuto l’esito e se la richiesta è stata salvata.
• Il sito aggiorna i contenuti senza ricaricare la pagina. Il segnale concordato deve seguire l’effettiva disponibilità dei dati, non la sola comparsa della schermata.
• Un componente esterno restituisce un valore inatteso. Il fornitore mostra come viene trattato senza inserirlo liberamente nel rapporto.

Le prove verificano gli stessi difetti previsti dagli avvisi, il formato dei dati e l’ordine rispetto alla conferma dell’applicazione. Si eseguono nell’ambiente di prova e si ripetono sul sito rilasciato con dati controllati, evitando contatti fittizi assegnati ai venditori.

Tag Assistant, lo strumento di anteprima di Google Tag Manager, permette di controllare l’attivazione dei tag e le condizioni che l’hanno causata. È una parte del collaudo. La ricezione nel sistema destinatario e il collegamento al CRM vanno controllati nei rispettivi strumenti.

Quando cambia il sito

Un nuovo modulo può chiedere un’informazione in più o distinguere una famiglia di prodotti. Il fornitore deve prima capire chi usa già quei valori.

La matrice mostra le modifiche da discutere con chi riceve i dati prima di pubblicarle.

Il registro delle modifiche deve dire che cosa cambia e da quando. Il referente della misurazione coordina i test automatici con chi aggiorna il sito. Prima del rilascio, concorda che le prove riconoscano gli stessi difetti previsti dagli avvisi. Lo sviluppatore prepara invii con questi difetti e prova anche una richiesta confermata per cui manca l’evento atteso, mostrando al referente della misurazione che gli avvisi funzionano.

Chiedi di concordare prima del rilascio il trattamento dei dati storici. Se a metà periodo cambi la definizione di richiesta ricevuta, le campagne sembrano andare meglio o peggio. Chi legge il rapporto deve sapere da quale giorno il conteggio ha un significato diverso.

Un modulo che misura l’invio leggendo la scritta del pulsante può smettere di contare dopo una revisione del testo, anche se il modulo continua a funzionare. Chi misura leggendo testi, classi CSS o posizioni del bottone dipende dal disegno della pagina: l’articolo sul confronto fra le due strade spiega quando può bastare. Il fornitore include questa prova nel rilascio.

Passare a una nuova versione

Una modifica può essere compatibile, da chiarire oppure incompatibile con chi legge i dati. Se rinomini un valore ammesso, un filtro può smettere di funzionare anche se il nome dell’evento non cambia. Anche il passaggio da un codice numerico a un testo o un segnale anticipato rispetto alla conferma può cambiare il risultato del rapporto.

Per una modifica incompatibile, il referente della misurazione concorda con lo sviluppatore un passaggio controllato. Possono aggiornare insieme i sistemi destinatari oppure mantenere temporaneamente la vecchia e la nuova rappresentazione, facendo leggere a ogni destinazione quella corretta. Devono fissare quando smettere di usare la precedente e provare che la stessa richiesta non venga contata due volte.

Gli avvisi dopo la pubblicazione

Il giorno della consegna non esaurisce il controllo. Un rapporto può continuare ad aprirsi anche quando manca un’informazione. Il controllo automatico deve segnalare al referente della misurazione quando manca un evento atteso, tenendo conto delle scelte di consenso e della configurazione adottata. Deve avvisare anche sui campi necessari assenti, sui valori non ammessi e sulle richieste duplicate. Il referente della misurazione li esamina dopo ogni rilascio e nei tempi di presa in carico pattuiti con il fornitore; un mancato passaggio al CRM va segnalato anche al responsabile del CRM. Per cercare la causa serve la data dell’ultima modifica al sito.

Un calo delle richieste misurate può dipendere dal mercato, da un modulo guasto o dalla raccolta interrotta. Il confronto parte dalle richieste salvate dal sito nello stesso periodo. Non è detto che coincidano con quelle osservate dalle piattaforme, per le scelte di consenso e i limiti della raccolta. Il referente della misurazione deve spiegare gli scostamenti rilevanti prima di proporre cambiamenti al budget. Dedica 15 minuti nella prima settimana con il referente della misurazione al confronto tra richieste salvate e dati osservati. L’esito deve indicare quali differenze sono spiegate e quali passano al fornitore per l’approfondimento.

Che cosa misurare nella manutenzione

Il referente della misurazione conta gli avvisi per tipo di difetto e li collega alla versione rilasciata. Un aumento dei conteggi può dipendere da invii ripetuti o navigazioni ripercorse; va confrontato con le azioni effettive.

Nel controllo rientrano anche le modifiche che hanno interrotto la raccolta, i dati ancora letti dalla grafica della pagina e i tag che usano campi non più previsti. Per un’anomalia si annotano l’ora di comparsa e quella di rilevazione. Il titolare può così capire quanto passa prima che qualcuno si accorga del problema, oltre al numero di incidenti.

La consulenza web analytics aiuta a tenere collegati questi controlli al lavoro commerciale. Serve soprattutto quando il sito, le campagne e il CRM hanno fornitori diversi. Alla riunione sui risultati devono poter partecipare persone che sanno spiegare dove nasce una differenza nei conteggi e chi può correggerla.

Domande frequenti

Serve un data layer dedicato per usare GTM?

Non per ogni azione. GTM può usare configurazioni già disponibili; un accordo dedicato è utile per richieste con esiti e informazioni che più sistemi devono interpretare allo stesso modo.

Chi deve aggiornare il documento?

Il referente della misurazione lo aggiorna con lo sviluppatore prima del rilascio. Il commerciale approva il significato delle richieste; chi segue la privacy valuta dati e destinazioni.

Può contenere dati dell’utente?

Vanno scelti soltanto quelli necessari e ammessi per l’uso previsto. Per Google Analytics restano esclusi i dati personali riconoscibili vietati dal servizio, anche quando il modulo li usa per rispondere al cliente.

Come mantenere confrontabili le richieste in più lingue?

Con riferimenti e valori stabili per il modulo e l’offerta e un campo separato per la lingua. I testi tradotti cambiano per il visitatore; chi legge i dati continua a riconoscere le stesse categorie.

Con richieste riconoscibili lungo il percorso, puoi valutare quali iniziative accompagnano contatti che i commerciali riescono a seguire. Il tempo della riunione torna alle offerte e alle opportunità aperte, con meno discussioni su moduli che sembrano arrivati soltanto nei rapporti. KLC può coordinare questo lavoro se non hai un referente che segua la richiesta dal modulo ai rapporti e al CRM.

Fonti e riferimenti

• Google Tag Platform, The data layer. Lettura di eventi e variabili da parte di GTM; coerenza dei nomi.
• Google Analytics, Recommended events. Eventi raccomandati e generate_lead.
• Google Analytics, Measurement Protocol. Invio di eventi da altri sistemi a integrazione della raccolta ordinaria.
• Google Analytics, Best practices to avoid sending PII. Divieto di inviare informazioni personali riconoscibili e controllo degli URL.
• Google Tag Platform, Set up consent mode. Gestione e aggiornamento degli stati di consenso.
• Google Tag Manager, Preview and debug containers. Anteprima con Tag Assistant e controllo di attivazione dei tag.
• Google Analytics, Mark events as key events. Configurazione degli eventi chiave e lettura nei rapporti.
• Google Analytics, Conversions vs. key events. Distinzione tra eventi chiave e conversioni per le campagne.
• Google Tag Platform, Consent mode overview. Modalità base e avanzata; misure senza cookie con consenso negato nella modalità avanzata.

Approfondisci il servizio: Analytics e conversioni.