Google Tag Manager Data Layer — documentazione

Installazione

Requisiti e installazione

Magento 2.4.x (Open Source o Adobe Commerce), PHP da 8.1 a 8.5, Hyvä o Luma. Un container di Google Tag Manager, che è gratuito.

composer require codingrow/module-gtmdl
bin/magento module:enable Codingrow_Gtmdl
bin/magento setup:upgrade

In modalità production anche setup:di:compile, setup:static-content:deploy e cache:flush. Le credenziali Composer arrivano per email quando richiedi il modulo gratuito o compri gli eventi di acquisto.

Tutto si configura in Stores → Configuration → Codingrow Extensions → Google Tag Manager Data Layer, e ogni impostazione può essere diversa per store view: basta cambiare lo Scope in alto a sinistra.

Container

Campo	Cosa fa
Enable	Con questo spento il negozio non rende né il container né una riga di data layer.
Container ID	Il tuo container, nella forma `GTM-XXXXXXX`. Scritto in altro modo viene ignorato. Lascialo vuoto per riempire il data layer senza caricare nessun container, che è quello che serve quando il container è già installato da qualcos'altro.
Load the container only after cookie consent	Usa la Cookie Restriction Mode di Magento. Il data layer si riempie comunque, quindi appena arriva il consenso non si perde niente. Col consenso Google attivo, qui sotto, non si applica più.

Come si usa

Google Consent Mode v2. Lo stato iniziale va dichiarato prima che il container parta, quindi può farlo solo chi carica il container. L'interruttore ha tre posizioni.

Dichiara solo lo stato iniziale è quella giusta quando il consenso è già gestito da un'estensione dedicata: il modulo dichiara tutto negato, e la tua estensione manda l'aggiornamento chiamando

window.codingrowGtmdl.consent({
    ad_storage: 'granted',
    ad_user_data: 'granted',
    ad_personalization: 'granted',
    analytics_storage: 'granted'
});

Dichiara lo stato iniziale e aggiornalo lascia che il modulo conceda il consenso dall'avviso sui cookie di Magento. Quella posizione richiede la Cookie Restriction Mode di Magento accesa (Stores → Configuration → General → Web → Default Cookie Settings): con quella spenta nessun cliente può accettare, e il consenso resterebbe negato per sempre. Una riga sotto i campi dice quale delle due sta succedendo davvero, e in quel caso diventa rossa.

Come si verifica che funzioni. Nel pannello di rete del browser, le richieste a google-analytics.com/g/collect portano un parametro gcs: vale G100 col consenso negato e G111 quando è concesso. Se cambia accettando i cookie, il Consent Mode sta lavorando.

Altre due impostazioni: oscura i dati pubblicitari senza consenso (finché il consenso pubblicitario è negato, Google non manda identificativi nelle sue chiamate pubblicitarie) e passa l'identificativo del clic nell'indirizzo (senza cookie, viaggia da una pagina all'altra). Entrambe consigliate.

I quattordici eventi

Un interruttore per evento. I quattro di base sono gratuiti; gli altri dieci richiedono la chiave degli eventi di acquisto.

Evento	Quando	Livello
`view_item`	scheda prodotto	gratuito
`view_cart`	carrello	gratuito
`begin_checkout`	checkout	gratuito
`purchase`	pagina di grazie, dall'ordine vero	gratuito
`view_item_list`	categoria e risultati di ricerca	acquisto
`select_item`	un clic su un prodotto in una lista	acquisto
`add_to_cart`	dalla riga vera del carrello	acquisto
`remove_from_cart`	dalla riga vera del carrello	acquisto
`search`	il termine e quanti risultati ha dato	acquisto
`add_to_wishlist`	il prodotto aggiunto	acquisto
`add_shipping_info`	il metodo di spedizione salvato	acquisto
`add_payment_info`	il metodo di pagamento salvato	acquisto
`login`	accesso del cliente	acquisto
`sign_up`	registrazione del cliente	acquisto

In questo gruppo ci sono altre due impostazioni: conta gli ordini creati in amministrazione (gli ordini inseriti a mano non hanno una visita dietro, e contarli falsa il costo per conversione) e solo questi stati d'ordine, che restringe l'acquisto agli stati che contano davvero come vendita.

Gli eventi di spedizione e pagamento non dipendono dal checkout: nascono da dentro Magento quando il metodo viene salvato, quindi funzionano sul checkout standard, su Hyvä, su Luma e su quelli che rispondono su una rotta propria. Gli altri quattro sono eventi di pagina: il modulo porta un piccolo file di layout per rotta, e l'assistenza può aggiungerne uno per un checkout che vive altrove.

Container da importare

Finché il container non ha un tag che legge il data layer, in Analytics non arriva niente. Riempi l'ID di misurazione GA4 (il G-XXXXXXXXXX che trovi in Analytics, sotto Amministratore → Flussi di dati) e, se vuoi anche la conversione Google Ads, l'ID conversione (le cifre dopo AW-) e l'etichetta della tua azione di conversione d'acquisto. Poi premi Scarica il container.

Il file contiene il tag di configurazione GA4, il tag che inoltra gli eventi ecommerce, il conversion linker, le variabili che servono e — quando i due campi di Google Ads sono compilati — la conversione d'acquisto con il fatturato vero e il numero d'ordine.

In Google Tag Manager: Amministrazione → Importa container, scegli il file, seleziona Merge e Rinomina i tag in conflitto, guarda l'anteprima e pubblica. Niente di quello che hai già viene sovrascritto.

Acquisti persi

Circa un acquisto su cinque non arriva mai ad Analytics: un blocco degli annunci, uno script fallito, un cliente che chiude la pagina troppo presto. Con questo acceso il negozio manda l'acquisto da sé quando il browser non l'ha fatto, portando l'identificativo che quel cliente aveva in quel momento.

Serve l'ID di misurazione GA4 del gruppo qui sopra e una chiave API del Measurement Protocol, che si crea in Analytics sotto Amministratore → Flussi di dati → il tuo flusso → Segreti API del Measurement Protocol. Viene salvata cifrata. L'attesa prima di mandare è il margine che si concede al browser del cliente: un quarto d'ora basta anche a una connessione lenta.

Recupera anche gli acquisti senza identificativo di Analytics copre i clienti che bloccano Analytics dalla prima pagina: non c'è niente da leggere, quindi l'acquisto si può mandare solo come una visita nuova e diretta. Si riprende il fatturato nei rapporti e si perde l'attribuzione di quegli ordini: per questo parte spento.

Sotto i campi un riquadro conta gli ultimi trenta giorni: ordini registrati, quelli confermati dal browser, quelli recuperati dal negozio, quelli ancora in attesa. Un pulsante fa controllare a Google il contenuto di un acquisto di prova senza registrarlo.

Tre cose da sapere. Gli ordini fatti prima di accenderlo non si recuperano: la registrazione comincia da qui. Una chiave API sbagliata non dà errore — Google accetta la chiamata e butta l'evento — quindi il modulo non dichiara mai che un acquisto è arrivato: segna di averlo mandato, e la conferma si legge in Analytics sotto Tempo reale. E chi ha rifiutato i cookie non viene mai recuperato, nemmeno con l'interruttore qui sopra: mandare il suo acquisto dal server aggirerebbe il suo rifiuto.

Cosa finisce dentro gli articoli

Campo	Cosa fa
I prezzi comprendono l'IVA	Deve corrispondere alla base usata dai tuoi rapporti Google.
Il valore dell'acquisto comprende la spedizione	Cambia solo il valore dell'acquisto.
Attributo prodotto usato come item_id	Usa lo stesso identificativo del tuo feed prodotti, altrimenti Google non abbina gli articoli.
Attributo prodotto usato come item_brand	Qualunque attributo del prodotto.
Aggiungi le categorie del prodotto	Mette la categoria dentro ogni articolo.
Numero massimo di articoli in view_item_list	Evita che una categoria lunga mandi un evento enorme.
Manda anche le vecchie chiavi del remarketing	Per i container che leggono ancora le chiavi di una volta.
Indirizzi IP da ignorare	Separati da virgola. Da quegli indirizzi non parte nessun evento: l'ufficio, per esempio.
Dimensioni personalizzate	Coppie di attributo prodotto e nome del parametro GA4. Il parametro viaggia dentro ogni articolo di ogni evento. In GA4 va dichiarato come dimensione personalizzata a livello articolo, altrimenti arriva ma nei rapporti non si vede.
Nome aggiuntivo per l'id univoco dell'evento	Per i container i cui trigger leggono quell'id con un altro nome. Lo stesso valore viaggia sotto entrambi i nomi, così nel giorno del cambio non tocchi niente nel container.

Problemi comuni

Ho messo l'ID del container ma non vedo niente in Google Tag Manager. Controlla che Enable sia Yes nello scope che stai guardando, che l'ID abbia la forma GTM-XXXXXXX, e in modalità production di aver fatto compile, static deploy e svuotamento cache. Nell'anteprima di Google Tag Manager si vedono gli eventi arrivare; se arrivano e i rapporti restano vuoti, il problema è nei tag dentro il container.

Un evento non parte mai. Dieci dei quattordici appartengono agli eventi di acquisto: la chiave va nel gruppo della licenza. Senza, il negozio continua a mandare i quattro di base.

Gli eventi del checkout arrivano tutti insieme sulla pagina di grazie. È normale su un checkout a pagina unica: l'evento viene registrato appena il cliente sceglie, e consegnato al primo caricamento di pagina successivo, che lì è la pagina di grazie. In Analytics restano nella stessa visita e nell'ordine giusto, prima dell'acquisto.

I numeri non tornano con Analytics o Google Ads. Controlla la base IVA, se la spedizione deve far parte del valore dell'acquisto, e che l'attributo usato come item_id sia l'identificativo del tuo feed prodotti.

L'acquisto è arrivato due volte. Non dal modulo: un ricaricamento della pagina di grazie non ripete l'evento. Cerca un secondo tag che manda lo stesso acquisto, per esempio una vecchia conversione di Google Ads ancora configurata in Magento sotto Sales → Google API.