Google Tag Manager per PrestaShop: configurare il tracciamento senza toccare il codice
Copre PrestaShop 1.7, 8 e 9; GA4 è l'unica versione di Google Analytics (Universal Analytics è terminato a luglio 2023) e Consent Mode v2 è richiesto per le funzionalità Google Ads nel SEE.
Ecco la promessa del titolo, e il punto critico sotto la superficie. Google Tag Manager permette davvero di aggiungere, modificare e rimuovere script di tracciamento da un'interfaccia web senza dover più toccare il codice del negozio, una volta installato. Ma inserire GTM dentro un negozio PrestaShop, e fare in modo che veda davvero cosa fanno gli acquirenti, è la parte di cui nessuno ti avverte. PrestaShop non consegna a GTM un flusso pulito e già pronto di eventi e-commerce. Di base, un contenitore GTM vuoto non fa nulla da solo. Un tag GA4 dentro GTM può tracciare le visualizzazioni di pagina, ma i report e-commerce richiedono eventi espliciti inviati al dataLayer; altrimenti ti ritrovi con statistiche che mostrano il traffico ma non una singola aggiunta al carrello, passaggio del pagamento o valore d'acquisto. Questa guida serve a colmare proprio quel divario su PrestaShop: come installare il contenitore nel modo corretto, perché il dataLayer è la parte decisiva e come farlo su 1.7, 8 e 9 senza creare un fork del tema.
Se stai ancora decidendo quali tag debbano stare nel tuo contenitore, quella è un'altra domanda: parti da cosa tracciare e cosa ignorare, poi torna qui per la parte tecnica.
Che cos'è davvero GTM, e che cosa volutamente non è
Google Tag Manager è un unico script contenitore che installi una volta sola. Dopo, ogni altro script di tracciamento, GA4, conversioni Google Ads, Meta Pixel, un tag Pinterest, il caricatore di un widget chat, vive dentro GTM e si gestisce da tagmanager.google.com, non dal tema. Il vantaggio è concreto: la prossima volta che il marketing ti chiede di "aggiungere solo il nuovo pixel", lo fai in due minuti da un form web, lo provi in anteprima e pubblichi, invece di aprire un client FTP, modificare un .tpl, svuotare la cache e sperare che il prossimo aggiornamento del tema non lo cancelli.
Che cosa GTM non è: non è uno strumento di analisi. Da solo non raccoglie nulla e non produce report. È un sistema di smistamento: ascolta gli eventi e attiva i tag giusti con i dati giusti. Questa distinzione conta su PrestaShop perché gli eventi che GTM distribuisce devono arrivare da qualche parte, e PrestaShop non li genera per te. Tieni a mente questo punto; è il nodo centrale di tutto l'articolo.
Perché far passare tutto da GTM in un negozio PrestaShop
Uno script invece di cinque che si rompono a ogni aggiornamento del tema
Un tipico negozio PrestaShop accumula tracciamenti nel modo più disordinato: GA4 incollato in header.tpl, un Meta Pixel inserito tramite un modulo gratuito, il codice di conversione Google Ads modificato a mano in order-confirmation.tpl e un frammento di remarketing aggiunto da qualcuno e poi dimenticato. Ognuno di questi è un punto di rottura separato, e ogni aggiornamento del tema o ricostruzione del tema figlio è un'occasione per perderne uno in silenzio. Con GTM, il negozio porta un solo contenitore; tutto il resto si sposta nel pannello di gestione. Quindi? Smetti di scoprire tre settimane dopo che il tracciamento delle conversioni si è spento in seguito a una modifica del template: ora c'è uno script da proteggere invece di cinque.
Cronologia delle versioni e ripristino immediato
GTM crea una versione a ogni pubblicazione. Pubblichi una modifica, vedi i numeri diventare strani e torni alla versione precedente con un clic. Incollare codici nei file del tema non ti dà nulla di simile: il tuo unico "ripristino" è ricordarti esattamente cosa hai cancellato e dove.
Modalità Anteprima prima che qualcosa vada online
L'Anteprima di GTM (Tag Assistant) si collega alla vetrina reale e ti mostra, tag per tag, cosa si è attivato su ogni pagina e quali dati portava, visibile solo a te, invisibile agli acquirenti. Su PrestaShop è qui che intercetti il classico errore: apri una pagina prodotto in Anteprima e il tag GA4 view_item semplicemente non si attiva, perché l'evento dataLayer che sta aspettando non è mai stato emesso. Meglio scoprirlo in Anteprima che dopo un mese di report funnel vuoti.
Caricamento condizionale e differito
I tag possono essere impostati per attivarsi solo dove servono: il tag di conversione Google Ads solo sulla pagina di conferma ordine, un caricatore di heatmap solo sulle pagine categoria e prodotto, nulla di pesante nella pagina iniziale. Così gli script marketing restano fuori dalle pagine dove aggiungerebbero solo peso. Il caricamento è asincrono dopo il contenuto, quindi il punteggio PageSpeed non subisce l'impatto che causerebbe una pila di script sincroni nell'head.
Installare il contenitore GTM su PrestaShop
Hai due strade oneste, e quella giusta dipende dal fatto che tu voglia o meno tornare a toccare un file del tema.
| Metodo di installazione | Cosa modifichi | Sopravvive agli aggiornamenti del tema? | Ideale quando… |
|---|---|---|---|
| Modifica del template del tema | head.tpl + checkout.tpl/layout | Solo se modifichi un tema figlio; una modifica al tema padre viene sovrascritta | Ti senti a tuo agio con i template e usi un tema personalizzato stabile. |
| Modulo GTM/dataLayer | Nulla, solo back office | Sì, si aggancia tramite hook, senza chirurgia sui template | Vuoi una soluzione senza codice, resistente agli aggiornamenti, e vuoi gestire anche il dataLayer. |
Percorso A, la modifica del template (il metodo letterale dei "due frammenti")
GTM ti dà due frammenti quando crei un contenitore Web: uno per il <head> e uno da inserire subito dopo l'apertura del <body>. In un tema PrestaShop 1.7/8/9 basato su classic, il frammento dell'head va in themes/your-theme/templates/_partials/head.tpl, mentre il frammento del body (il fallback iframe <noscript>) va vicino all'inizio di layouts/layout-both-columns.tpl o del tuo layout base. Modifica un tema figlio, mai il padre: una modifica al tema padre è esattamente il tipo di intervento che un aggiornamento futuro annulla in silenzio. Dopo la modifica, svuota la cache da Parametri avanzati → Prestazioni (o elimina var/cache) altrimenti la modifica non verrà renderizzata.
Una trappola specifica di PrestaShop: se hai una cache aggressiva o una CDN davanti al negozio, il frammento del contenitore fa parte dell'HTML in cache, quindi una vecchia pagina in cache può servire un vecchio ID contenitore. Svuota entrambi i livelli quando cambi contenitore.
Percorso B, la strada del modulo (nessuna modifica ai template)
Il motivo per cui la maggior parte dei commercianti finisce qui non è la pigrizia: è che il Percorso A risolve solo metà del problema. Incollare il contenitore carica GTM; non fa nulla per il dataLayer, che è la parte difficile su PrestaShop (sezione successiva). Un modulo GTM/dataLayer fatto bene inietta il contenitore e emette gli eventi e-commerce sugli hook PrestaShop corretti, tutto configurabile dal back office. Quindi? Ottieni un funnel d'acquisto funzionante senza aprire un singolo template, e sopravvive agli aggiornamenti perché è un modulo, non una modifica al tema.
Il dataLayer: la parte che è davvero un problema di PrestaShop

È qui che "configurare il tracciamento senza toccare codice" diventa una promessa realistica. GTM può attivare un tag solo quando riceve un evento. Per l'e-commerce, GA4 si aspetta un vocabolario specifico di eventi con una struttura dati precisa, view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, ciascuno inviato a un oggetto JavaScript chiamato dataLayer con ID prodotto, prezzi, quantità e (per l'acquisto) ID ordine, valore, imposte e spedizione.
PrestaShop non emette nulla di tutto questo da solo. Il tema predefinito renderizza le pagine prodotto e pagamento senza inviare mai un evento dataLayer nel formato GA4. Quindi una semplice installazione di GTM ti dà le visualizzazioni di pagina e nient'altro: nessuna informazione sui prodotti visualizzati, nessun segnale di aggiunta al carrello, nessun ricavo. Il funnel è vuoto nel mezzo. Questo singolo fatto spiega perché il consiglio "installa semplicemente GTM" fallisce su PrestaShop e funziona bene su un negozio Shopify che fornisce questi eventi nativamente.
Hai tre modi per alimentare il dataLayer:
- Un modulo che emette gli eventi. Un modulo GTM/dataLayer si aggancia ai punti in cui PrestaShop sa già cosa sta accadendo, displayProductAdditionalInfo / pagina prodotto per view_item, la risposta AJAX add_to_cart del carrello, il controller del pagamento per i passaggi di inizio/spedizione/pagamento e l'hook di conferma ordine (displayOrderConfirmation, cioè l'hook di renderizzazione front-end che può emettere il push JavaScript, non l'hook PHP server-side actionValidateOrder che si limita a scattare quando l'ordine viene creato) per purchase, e invia eventi con la struttura corretta. È il percorso senza codice e quello che la maggior parte dei negozi dovrebbe scegliere.
- Push dataLayer scritti a mano nel tema. Aggiungi tu il JavaScript, leggendo dal JS esistente di PrestaShop (prestashop.cart, l'oggetto prodotto esposto sulla pagina, le variabili dell'ordine sulla pagina di conferma). Controllo totale, ma è vero lavoro front-end e si rompe se il tema cambia: l'opposto della promessa del titolo.
- Scraping solo con GTM. Allettante e fragile: usare variabili GTM per estrarre prezzi e ID dal DOM. Funziona finché una modifica al tema rinomina una classe CSS, poi i dati sui ricavi diventano sbagliati in silenzio. Da evitare per qualunque dato alimenti le offerte di Google Ads.
Qualunque percorso tu scelga, la struttura che GTM si aspetta sulla pagina di conferma ordine è questa. Nota la chiave event: 'purchase': quella stringa è ciò che un trigger GTM Evento personalizzato ascolta per attivare il tuo tag GA4 di acquisto, ed è la parte che lo scraping del DOM non può riprodurre in modo affidabile. I valori sono le variabili ordine di PrestaShop ($order->reference, totali, ISO della valuta, righe prodotto), renderizzate e sottoposte a escape nel template:
<script>
window.dataLayer = window.dataLayer || [];
dataLayer.push({ ecommerce: null }); // reset so items can't leak in
dataLayer.push({
event: 'purchase', // GTM Custom Event trigger listens on this
ecommerce: {
transaction_id: '{$order.reference}',
value: {$order.total_paid|floatval},
tax: {$order.total_tax|floatval},
shipping: {$order.total_shipping|floatval},
currency: '{$currency.iso_code}',
items: [
{foreach $products as $p}
{ldelim}
item_id: '{$p.reference}',
item_name: '{$p.name|escape:'javascript'}',
price: {$p.price_amount|floatval},
quantity: {$p.quantity|intval}
{rdelim}{if !$p@last},{/if}
{/foreach}
]
}
});
</script>
In GTM poi leggi ogni campo con una Variabile livello dati (ecommerce.transaction_id, ecommerce.value e così via) e li mappi nel tag evento di acquisto GA4. Proteggi il push in modo che si attivi una sola volta per riferimento ordine, altrimenti un ricaricamento della pagina di conferma conta due volte la vendita.
La sintesi onesta: l'unico modo davvero senza codice e sicuro per gli aggiornamenti per ottenere un dataLayer PrestaShop completo è un modulo che lo gestisca. Tutto il resto implica toccare codice o accettare fragilità.
I tag essenziali. In breve, perché la parte difficile è la struttura dei dati
Una volta che gli eventi arrivano al dataLayer, i tag in sé sono GTM standard e non specifici di PrestaShop, quindi ecco una mappa rapida invece di una guida generica:
- Configurazione GA4 + tag evento, il tuo primo tag; il Google tag/config di GA4 più i tag evento GA4 inviano dal dataLayer gli eventi e-commerce consigliati come view_item, add_to_cart, begin_checkout e purchase. Per capire quali metriche GA4 meritano attenzione e quali sono rumore, vedi le metriche GA4 che contano davvero; per una configurazione completa di proprietà e stream, la guida completa alla configurazione di GA4.
- Conversione Google Ads + remarketing, attiva il tag di conversione sulla conferma ordine, passando valore dell'ordine e ID transazione; il tag di remarketing crea segmenti di pubblico da visualizzazioni prodotto e carrelli abbandonati.
- Meta / pixel di altre piattaforme, installali tramite GTM invece che con moduli separati, così vengono gestiti (e vincolati al consenso) in un unico posto.
Qualunque cosa tu aggiunga, la disciplina qui sotto conta più dell'elenco dei tag.
Non contare due volte: GTM vs moduli di analisi di PrestaShop
Il caos più comune che vediamo su PrestaShop è il doppio tracciamento. Molti negozi usano un modulo Google Analytics come ps_googleanalytics / "PrestaShop Google Analytics", trattalo come un modulo, non come statistiche native di PrestaShop, e molti lo hanno attivo insieme a un tag GA4 che si attiva tramite GTM. Risultato: ogni visualizzazione di pagina, ogni acquisto, ogni euro di ricavo contato due volte, report gonfiati, tassi di conversione falsati e Google Ads che ottimizza su vendite fantasma.
Scegli una strada. Se punti tutto su GTM (la scelta giusta per la maggior parte dei negozi in crescita), disattiva il modulo GA da Moduli → Gestione moduli e lascia che GTM gestisca ogni tag. Se ti serve solo GA4 di base e nient'altro, un modulo GA da solo può bastare, ma solo se la sua versione attuale supporta GA4 e gli eventi e-commerce che ti servono, e non hai bisogno di GTM. Quello che non devi mai fare è eseguire entrambi sulla stessa proprietà. Verificalo in DebugView di GA4 con la modalità Anteprima attiva: ogni azione deve apparire esattamente una volta.
Consenso: GDPR/RODO e la realtà di PrestaShop
Nell'UE, la maggior parte dei tag marketing e di analisi richiede il consenso prima di attivarsi, e GTM è il posto giusto per farlo rispettare tramite Google Consent Mode v2. La particolarità di PrestaShop: PrestaShop non ha un banner cookie nativo consapevole della Consent Mode. I blocchi CCC/testi legali inclusi non sono una piattaforma di gestione del consenso. Quindi serve una vera CMP (un modulo dedicato o una CMP certificata da Google) che imposti i segnali di Consent Mode, e poi devi vincolare i tuoi tag GTM a quei segnali.
Consent Mode esiste in due modalità, e si comportano diversamente quando il consenso viene negato, quindi decidi quale usa il tuo negozio:
- Modalità base: i tag Google non vengono caricati affatto finché il consenso non viene concesso. Prima del consenso, i tag di analisi e pubblicitari restano semplicemente sospesi e non attivano nulla; se il consenso viene negato, restano bloccati e non inviano alcun ping.
- Modalità avanzata: i tag Google vengono caricati subito ma con la memorizzazione impostata su negata. Quando il consenso viene negato inviano comunque ping aggregati e senza cookie che Google può usare per la modellazione; quando il consenso viene concesso passano alla misurazione completa.
- Dopo il consenso: in entrambe le modalità, i tag si attivano in base alle categorie accettate dal visitatore.
I ping di modellazione senza cookie avvengono solo in modalità avanzata: la modalità base blocca fino al consenso, quindi non aspettarti segnali in stato negato. Scegli un modello e configura in modo coerente CMP e tag GTM attorno a quello.
Configura il blocco una sola volta a livello GTM invece che per singolo script: centralizza la conformità e trasforma un audit in un lavoro da cinque minuti invece che in una caccia nei template. Se consenso e proprietà dei dati sono una preoccupazione primaria per il tuo negozio, vale la pena valutare anche un'architettura orientata alla privacy: Matomo vs Google Analytics.
Checklist PrestaShop prima del lancio di GTM
- Contenitore presente su ogni tipo di pagina, pagina iniziale, categoria, prodotto, carrello, pagamento e conferma ordine. Conferma in Anteprima che la pagina di conferma (l'unico posto in cui purchase può attivarsi) contenga il contenitore; è la pagina più facile da perdere se usa un layout diverso.
- purchase si attiva una sola volta, con il valore corretto, controlla che ID ordine, valore, imposte e spedizione corrispondano all'ordine reale, e che un refresh della pagina non lo attivi due volte.
- Nessun GA duplicato, modulo GA di PrestaShop disattivato se GTM gestisce GA4.
- Il blocco del consenso funziona, con consenso negato, i tag di analisi e annunci devono restare bloccati in DebugView.
- Cache svuotata, dopo ogni modifica al contenitore o ai template, svuota la cache di PrestaShop e la CDN.
Dove GTM serve, e dove si ferma
GTM si ripaga il giorno stesso in cui lo installi: non in denaro, perché è gratuito, ma nelle sessioni FTP che non avvierai più e nei tracciamenti che smetterai di perdere in silenzio a causa degli aggiornamenti del tema. Su PrestaShop, in particolare, tutto il lavoro si riduce a due cose che la piattaforma non fa per te: inserire il contenitore in modo pulito (tema figlio o modulo, mai tema padre) e alimentarlo con un dataLayer completo e strutturato correttamente (un modulo è l'unico modo senza codice per farlo in modo affidabile). Fai bene queste due cose e la promessa del titolo diventa reale: ogni tag futuro è un form web, non un rilascio.
Domande frequenti
Se installo GTM, mi serve ancora un modulo GA4 su PrestaShop?
Ti serve l'uno o l'altro per GA4, non entrambi sulla stessa proprietà: eseguire insieme un modulo GA e un tag GA4 basato su GTM conta due volte ogni visualizzazione di pagina e acquisto. La vera domanda è chi alimenta il dataLayer. GTM distribuisce i tag ma non genera gli eventi e-commerce di PrestaShop; qualcosa deve comunque inviare view_item, add_to_cart e purchase. Se non vuoi scriverlo a mano nel tema, un modulo dataLayer lo fa dagli hook di PrestaShop, e tu punti i tag GTM agli eventi che emette.
Perché il mio GTM mostra visualizzazioni di pagina ma nessuna aggiunta al carrello o ricavo?
Perché il contenitore è presente ma il dataLayer è vuoto. Una semplice installazione di GTM su PrestaShop traccia le visualizzazioni di pagina e nient'altro: il tema predefinito non invia mai eventi e-commerce nel formato GA4. Il funnel resta vuoto nel mezzo finché un modulo o codice scritto a mano non emette quegli eventi. È il reclamo più comune "GTM non funziona su PrestaShop", e non è un bug di GTM: è il dataLayer mancante.
Dovrei estrarre prezzi e ID dalla pagina con variabili GTM?
Evitalo per tutto ciò che conta. Lo scraping del DOM funziona finché una modifica al tema rinomina una classe CSS, poi i dati su ricavi e offerte Google Ads diventano sbagliati in silenzio, senza errori. Invia invece valori reali al dataLayer dagli oggetti ordine e prodotto di PrestaShop: è la differenza tra dati affidabili e dati che si rompono al prossimo aggiornamento del tema.
Dove inserisco il contenitore perché sopravviva agli aggiornamenti del tema?
Mai nel tema padre: una modifica al tema padre è esattamente ciò che un aggiornamento futuro sovrascrive. Modifica un tema figlio (frammento head in _partials/head.tpl, frammento body noscript vicino all'inizio del layout base) oppure usa un modulo che inietti il contenitore tramite hook, così non c'è alcuna chirurgia sui template. Dopo l'una o l'altra opzione, svuota la cache di PrestaShop e la CDN, altrimenti una vecchia pagina in cache può continuare a servire un vecchio ID contenitore.
Consent Mode base o avanzata: quale dovrebbe usare il mio negozio?
Avanzata se vuoi dati modellati quando il consenso viene negato: i tag Google si caricano con memorizzazione negata e inviano ping aggregati e senza cookie finché il visitatore non accetta. La modalità base blocca completamente i tag fino al consenso e non invia alcun ping in stato negato. Entrambe sono valide; scegline una e configura CMP e tag GTM in modo coerente. Qualunque tu scelga, vincola i tag una volta sola a livello GTM invece che per singolo script. Se consenso e proprietà dei dati sono una preoccupazione primaria, vale la pena valutare anche un'architettura orientata alla privacy, vedi Matomo vs Google Analytics.
Un limite onesto: GTM ti dice che un passaggio è avvenuto, conta le aggiunte al carrello, i pagamenti iniziati, gli acquisti. Non può mostrarti perché un acquirente ha cliccato furiosamente su un filtro rotto o ha abbandonato al passaggio della spedizione. Per il "perché", affiancalo a strumenti a livello di sessione: vedi Microsoft Clarity e heatmap e registrazioni di sessione Hotjar. E una volta che i numeri scorrono in modo pulito, la domanda diventa come trasformarli in decisioni economiche: il nostro modulo di reportistica Financial Revolution legge direttamente i dati reali degli ordini del tuo negozio, niente dataLayer, niente tag, niente campionamento, così i report su margini e ricavi si basano su ciò che è stato davvero pagato, non su ciò che un tag nel browser è riuscito a catturare. Un'ultima nota per il 2026: una quota crescente del "traffico" non è umana, e le sessioni bot possono inquinare in silenzio proprio gli eventi che GTM inoltra a Google, vale la pena capirlo prima di fidarsi di un funnel, vedi Google Storebot nel tuo negozio PrestaShop.