Il container, il data layer e le vendite che Analytics perdeva

Quattordici eventi, e da dove nasce ognuno

Ogni evento è costruito dal server su quello che il negozio ha davvero: prezzi con o senza IVA come scegli tu, l'attributo che usi come codice prodotto, le categorie del prodotto. Niente viene letto dalla pagina, quindi un cambio di tema non può romperlo.

Il container, già pronto

Un data layer che nessuno legge sembra un modulo rotto: finché il container non ha un tag che lo legge, in Analytics non arriva niente. Per questo un pulsante in configurazione scarica un file da importare in Google Tag Manager, con il tag di configurazione GA4, il tag che inoltra gli eventi ecommerce, la conversione di acquisto di Google Ads con il fatturato vero e il numero d'ordine, il conversion linker e le variabili che servono. Lo importi scegliendo Merge, guardi l'anteprima, pubblichi. L'alternativa è costruire a mano una trentina di oggetti.

Gli acquisti che Analytics non ha mai visto

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. Sono vendite che hai fatto e non vedi, e Google ottimizza le campagne senza di esse. Con gli eventi di acquisto il negozio manda l'acquisto da sé quando il browser non l'ha fatto, portando l'identificativo che quel cliente aveva in quel momento: così la vendita si attacca alla visita e l'annuncio che l'ha portata prende il merito. Un riquadro in configurazione te li conta: ordini, quelli confermati dal browser, quelli recuperati dal negozio. E chi ha rifiutato di essere misurato non viene mai recuperato.

Su un negozio che gestiamo noi: 27 ordini veri in trenta giorni, 21 acquisti in Analytics. Sei vendite invisibili alle campagne che le avevano pagate.

Consent Mode v2, al posto giusto

In Europa uno stato del consenso dichiarato è ciò che permette a Google di modellare le conversioni che non ha osservato: senza, quei dati sono semplicemente persi. Il modulo dichiara tutto negato prima che il container parta — cosa che può fare solo chi carica il container — e da lì scegli tu: o concede il consenso dall'avviso sui cookie di Magento, o aspetta che la tua estensione di consenso chiami una funzione pubblica. Una riga in configurazione dice quale delle due sta succedendo davvero, e diventa rossa quando la configurazione non può funzionare.

Cosa ottieni

• Hyvä e Luma, il checkout standard e quelli su rotta propria: gli eventi di spedizione e pagamento nascono da dentro Magento, non dai bottoni.
• Un interruttore per evento, per store view: mandi quello che vuoi misurare e nient'altro.
• Prezzi con o senza IVA, spedizione dentro o fuori dal valore dell'acquisto, l'attributo che usi come codice prodotto e come marca.
• Dimensioni personalizzate: un attributo del prodotto diventa un parametro dentro ogni articolo di ogni evento.
• Indirizzi IP che non vuoi misurare, ordini inseriti a mano lasciati fuori, e solo gli stati d'ordine che contano davvero come vendita.
• Se stai sostituendo un'altra estensione: i nomi degli eventi sono quelli documentati da GA4, e l'id univoco dell'evento può viaggiare anche sotto il nome che il tuo container si aspetta già, così nel giorno del cambio non tocchi niente lì dentro.

Amministrazione nella tua lingua

Ogni campo e ogni spiegazione della configurazione è tradotto, comprese quelle che dicono cosa non fare:

La lingua della store view viene rilevata automaticamente; l'inglese è la lingua di riserva.

Requisiti

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. Per il recupero degli acquisti persi, una chiave API del Measurement Protocol della tua proprietà GA4.

Documentazione

Installazione, ogni campo spiegato, come importare il container e come verificare che un evento arrivi davvero in Analytics.

→ Leggi la documentazione completa

Changelog

Cosa cambia, versione per versione.