La scelta tra il modulo GA4 diretto e Google Tag Manager dovrebbe iniziare dalla definizione di chi crea gli eventi, quando considera un ordine come acquisto e chi mantiene la configurazione. Il solo identificatore G-… o GTM-… non risponde a queste domande.
Confrontiamo versioni specifiche: PD Google Analytics 4 Pro 1.4.2, PD Google Tag Manager Pro 2.3.4 e il precedente PD Google Tag Manager 1.2.4. La descrizione deriva dal loro codice e dalle istruzioni verificate il 26 settembre 2026. Questo è l’ambito di tali versioni, non una dichiarazione di comportamento identico di tutti i moduli disponibili per PrestaShop.
Due percorsi per lo stesso evento
Schema dimostrativo dell’evento view_item. Mostra la ripartizione delle responsabilità, non il risultato della misurazione in un account GA4 attivo.
Nella variante diretta il modulo raccoglie i dati del prodotto e prepara la chiamata del Google tag. Nella variante GTM Pro il modulo trasmette l’oggetto evento al dataLayer, e il contenitore pubblicato decide l’attivazione del tag e il suo destinatario. Per entrambe le varianti occorre definire separatamente le regole di consenso e la correttezza dei parametri.
Il dataLayer è presente anche nell’uso diretto di gtag. La sola presenza di questa variabile nel browser non dimostra che il negozio utilizzi un contenitore GTM. Google descrive entrambi gli utilizzi nella documentazione del data layer.
La differenza più importante: quando nasce purchase?
Comportamento delle versioni dei moduli verificate
Area
GA4 Pro 1.4.2
GTM Pro 2.3.4
Eventi del browser
Il modulo prepara le chiamate del Google tag, tra cui la visualizzazione del prodotto e l’avvio del checkout.
Il modulo crea eventi nel dataLayer. Nel contenitore occorre configurare e pubblicare i tag, le regole e le variabili appropriate.
Acquisto
Il flusso server-side Measurement Protocol verifica lo stato di pagamento configurato e la cronologia del pagamento qualificante. In questa versione il purchase lato browser è disattivato.
Il purchase lato browser viene generato alla conferma dell’ordine. Il codice di questo flusso non utilizza lo stesso elenco di stati pagati di GA4 Pro.
Flusso server-side aggiuntivo
Gestisce le operazioni finanziarie al soddisfacimento dei requisiti di identificazione, configurazione e consenso.
La coda opzionale di recupero dell’acquisto richiede la configurazione di Measurement Protocol e di un’attività CRON. La registrazione del rendering della conferma influisce sulla decisione di un nuovo tentativo.
Rimborso
Sono previste operazioni in base allo stato configurato o al documento di rettifica, con controllo dell’acquisto precedente e dei rimborsi.
Il documento di rettifica può alimentare la coda refund; l’invio dipende dal contesto, dal consenso e dall’automazione attiva.
Non confrontare quindi i numeri di purchase senza averne definito il significato. Ordine creato, mostrato nella pagina di conferma e qualificato come pagato sono tre momenti diversi. Nel caso di un bonifico in attesa di accredito, la differenza può essere particolarmente evidente.
Matrice degli eventi prima dell’avvio della misurazione
Per ogni evento annota la fonte, il destinatario, la condizione di consenso e la persona responsabile. Scarica la matrice CSV modificabile. Contiene esempi dimostrativi e campi per il risultato della tua verifica.
Esempio di ripartizione delle responsabilità da completare per il proprio negozio
Evento
Fonte
Destinatario
Consenso e responsabilità
view_item
Modulo diretto oppure modulo dataLayer e tag GTM — scegli un solo flusso.
Flusso GA4 indicato.
La persona che gestisce l’analitica verifica i segnali CMP e le condizioni del tag.
purchase
Momento di business definito e un solo proprietario dell’emissione.
Lo stesso flusso concordato.
Il proprietario dell’integrazione verifica il contesto del cliente, i consensi, l’identificatore della transazione e i nuovi tentativi.
refund
Stato selezionato o documento di rettifica in base alla soluzione utilizzata.
Flusso in cui è stato registrato l’acquisto.
La persona responsabile dei rimborsi concorda l’ambito completo e parziale e il metodo di validazione.
Consensi e Measurement Protocol fanno parte del progetto
Nella versione verificata di GA4 Pro, il consenso attendibile per il salvataggio dell’attribuzione e per le operazioni finanziarie server-side è collegato a PD Cookie Pro attivo, alla sua modalità live, al Consent Mode v2 e alla revisione attuale del consenso. Non presumere che la sostituzione di questo fornitore con qualsiasi altro banner mantenga l’intero flusso server-side senza ulteriori verifiche.
GTM Pro ha proprie impostazioni di Consent Mode e integrazioni specifiche con i fornitori di consenso. Con PD Cookie Pro attivo, gli lascia la gestione dei consensi. Il comportamento finale dipende anche dal contenitore pubblicato. La presenza del banner o di un campo di configurazione non è ancora il risultato del test “rifiuto → consenso → revoca”.
Il flusso server-side non significa aggirare il consenso né recuperare automaticamente la sorgente della sessione. L’API Secret appartiene alla configurazione del server. Il collegamento con l’attività del browser richiede identificatori e contesto corretti; il punto di riferimento è la documentazione sull’invio degli eventi Measurement Protocol.
Il vecchio GTM e GTM Pro non sono la stessa offerta
Il precedente PD Google Tag Manager 1.2.4 serve per incorporare il contenitore. Il codice verificato non contiene il modello ecommerce e la coda Measurement Protocol descritti sopra per la versione Pro. Non considerare il nome “GTM” come una promessa di eventi di acquisto già pronti.
PD Google Tag Manager Pro aggiunge il data layer e gli strumenti di configurazione. L’esportazione del contenitore è il punto di partenza per l’importazione, la revisione e la pubblicazione in GTM. Non sostituisce la presa in carico della configurazione. Anche il campo per l’indirizzo del proprio server non crea automaticamente un’infrastruttura GTM server-side.
Come scegliere la variante ed evitare due proprietari dell’acquisto?
Modulo diretto: valuta GA4 Pro se vuoi gestire questo flusso nelle impostazioni del modulo e se la sua definizione di acquisto pagato e i requisiti di consenso corrispondono al negozio.
Contenitore GTM: valuta GTM Pro se hai una persona responsabile di tag, regole, ambienti e pubblicazione delle modifiche. Definisci anche chi gestisce l’eventuale coda server-side.
Implementazione esistente: prima fai l’inventario dei moduli e dei tag attivi. Non aggiungere un secondo emettitore di purchase solo perché il numero di acquisti nel report suscita dubbi.
La presa in carico dovrebbe comprendere un solo passaggio controllato per prodotto, carrello, momento corretto dell’acquisto e rimborso, oltre al rifiuto e alla revoca del consenso. Separa la prova “evento creato”, “invio eseguito” ed “evento visibile in GA4”. Il solo dataLayer.push, il rendering della pagina o la risposta HTTP del trasporto non confermano ancora la completezza del report.
Google Analytics 4 Pro – modulo GA4 per PrestaShop
Google Analytics 4 Pro è un modulo PrestaShop per implementare il tag Google e misurare il comportamento degli utenti in Google Analytics 4. Registra eventi relativi ai prodotti, agli elenchi di prodotti, al carrello, al checkout, alla ricerca e all’account cliente. Gli acquisti e i resi supportati...
PD Google Tag Manager Pro è un modulo PrestaShop avanzato per l’implementazione di Google Tag Manager con DataLayer e-commerce completo, integrazione con GA4 e supporto per Google Consent Mode v2. Il modulo inserisce automaticamente il codice GTM nella sezione head e nella parte noscript dopo l’apertura del tag body, può funzionare con un secondo...
Patryk Marek — proprietario di PrestaDev.pl e sviluppatore specializzato in PrestaShop. Da molti anni si occupa della creazione, dello sviluppo e della manutenzione di negozi online. Unisce il lavoro sul codice del negozio e dei moduli alla configurazione dell’ambiente server in cui queste soluzioni operano.
Progetta e sviluppa moduli PrestaShop, adatta le funzionalità esistenti e prepara integrazioni con grossisti e servizi esterni. Lavora sull’importazione e sull’aggiornamento dei dati dei prodotti, sull’automazione della gestione del catalogo, sul processo dell’ordine e sugli strumenti che supportano il lavoro quotidiano del proprietario del negozio.
La sua esperienza comprende anche aggiornamenti e migrazioni dei negozi, diagnosi degli errori, analisi delle prestazioni e configurazione dei server e dei servizi necessari al funzionamento di PrestaShop. Nella risoluzione dei problemi tiene conto delle dipendenze tra moduli, tema, PHP, database e impostazioni di hosting.
Nel blog condivide conoscenze derivanti da molti anni di pratica nello sviluppo e dal lavoro con il backend tecnico dei negozi. Le guide si concentrano su problemi concreti, sui modi per verificarli e sui limiti delle soluzioni descritte. Aiutano i proprietari dei negozi e le figure tecniche a preparare le modifiche, valutarne la portata e verificarne il risultato.
Commenti (0)