La versione 1.4.2 richiede almeno PHP 7.2.5 per le librerie HTTP incluse; la versione di PHP deve rispettare anche i requisiti della versione di PrestaShop utilizzata. Acquisti e rimborsi lato server richiedono inoltre PD Cookie Pro attivo in modalità live con Consent Mode v2, una revisione del consenso corrispondente, il consenso analitico e i dati di attribuzione cliente/sessione salvati. Il solo API Secret non basta.
I purchase lato server non vengono inviati per ordini con confezione regalo a pagamento, oltre 200 righe di prodotti o riferimento/EAN mancante quando si sceglie tale formato item_id. Le note di credito devono avere importi e voci coerenti; vengono rifiutati i record con partial != 0 e i tipi di buono. Il tipo 2 è supportato solo per un rimborso inequivocabile della sola spedizione. Un rimborso parziale delle quantità di prodotti non equivale al flag tecnico partial.
Caratteristiche e funzionalità principali
- 15 eventi e-commerce e account con nome:
view_item, view_item_list, select_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund, search, view_search_results, sign_up e login.
page_view opzionale: l’amministratore può lasciare la misurazione automatica delle visualizzazioni di pagina nel modulo oppure disattivarla, se la gestione delle visualizzazioni è affidata a Google Tag Manager o a un’altra soluzione.- Acquisto dopo uno stato configurato: la versione 1.4.2 invia purchase dal server dopo il salvataggio nello storico dell'ordine dello stato scelto dall'amministratore come conferma del pagamento, se sono soddisfatte anche le altre condizioni. Il modulo non verifica autonomamente il regolamento presso il fornitore di pagamento.
- Measurement Protocol per le operazioni finanziarie: per inviare
purchase e refund sono necessari: il Measurement ID principale, l’API Secret, i dati di attribuzione/sessione salvati e il consenso analitico attuale.
- Resi controllati: il modulo gestisce il rimborso completo in base allo stato selezionato e le nuove rettifiche di PrestaShop, comprese quelle parziali, esclusivamente se in precedenza è stato registrato un acquisto idoneo.
- Registro degli eventi finanziari: un registro persistente e un blocco per ordine controllano gli acquisti e i rimborsi propri del modulo; il back office offre una vista di sola lettura con filtri, ordinamento e paginazione. Ciò non deduplica gli eventi inviati indipendentemente da GTM o altri moduli.
- Due identificatori Measurement ID: è possibile configurare il principale e un secondo identificatore GA4 opzionale per gli eventi inviati dal tag nel browser.
- Cinque modalità di costruzione di
item_id: ID prodotto, ID prodotto con ID combinazione separato da trattino, ID prodotto con ID combinazione separato da underscore, riferimento oppure EAN.
- Dati di catalogo negli eventi: il modulo trasmette, tra l’altro, identificatore, nome, variante, marca, categorie, prezzo, sconto, quantità, valuta e dati della lista prodotti, se disponibili in PrestaShop.
- Codici sconto: gli eventi del browser supportati possono contenere il nome e il codice della regola carrello applicata. Nella versione 1.4.2, il purchase lato server inviato tramite Measurement Protocol non contiene codici sconto.
- User ID per il cliente autenticato: dopo l’attivazione dell’opzione, il modulo trasmette a GA4 l’identificatore tecnico del cliente con il consenso
analytics_storage; ciò non sostituisce i dati di contatto.
- Dati forniti dall’utente: dopo l’attivazione dell’opzione e con il consenso attuale
ad_user_data, il modulo può trasmettere e-mail e telefono o indirizzo disponibili nel formato richiesto da Google; i dati identificativi vengono normalizzati e sottoposti ad hash SHA-256.
- Remarketing dinamico Google Ads: dopo l’attivazione della funzione e l’inserimento dell’identificatore Google Ads, il tag riceve gli identificatori dei prodotti, il tipo di pagina e il valore del carrello.
- DebugView e diagnostica: la modalità debug registra gli eventi del browser e imposta il relativo flag debug_mode per GA4 DebugView. Non imposta questo flag per purchase e refund lato server. Il pannello mostra lo stato della configurazione e l'ultimo acquisto con risposta HTTP 2xx; gli eventi finanziari vanno verificati nel registro e nei report GA4.
- PrestaShop 1.7.x, 8.x e 9.x: questo è l'intervallo dichiarato dalla versione 1.4.2, non una garanzia per ogni versione di PHP, tema o checkout. Il codice include percorsi per il checkout standard e alcuni moduli one-page checkout; occorre verificare il percorso effettivo dell'ordine nel proprio negozio.
Quali fasi di vendita misura il modulo GA4 per PrestaShop?
| Fase nel negozio |
Eventi trasmessi dal modulo |
Ambito dei dati |
| Liste e scheda prodotto |
view_item_list, select_item, view_item |
Prodotto, variante, marca, categorie, prezzo, sconto e posizione nella lista. |
| Carrello |
add_to_cart, remove_from_cart, view_cart |
Articoli del carrello, quantità, valori, valuta e coupon disponibile. |
| Checkout |
begin_checkout, add_shipping_info, add_payment_info |
Composizione del carrello e informazioni selezionate durante il processo d’ordine. |
| Acquisto e rimborso |
purchase, refund |
Snapshot lato server della transazione o del rimborso idoneo inviato tramite Measurement Protocol. |
| Ricerca e account |
search, view_search_results, sign_up, login |
Termine cercato, risultati della ricerca oppure evento di creazione account e accesso. |
Misurazione di acquisti e rimborsi tramite Measurement Protocol
Nell’attuale modalità finanziaria il modulo non considera il clic sul pulsante né la sola pagina di conferma come prova di pagamento. L’evento purchase viene generato dopo il salvataggio nella cronologia dell’ordine di uno degli stati di pagamento selezionati. Per il rimborso, il modulo verifica prima se per quell’ordine esiste un acquisto precedente registrato come inviato nel registro; quindi contabilizza esclusivamente il valore residuo non ancora rimborsato. Il rimborso completo può essere attivato dallo stato selezionato, mentre le nuove rettifiche di PrestaShop sono gestite in modo indipendente, anche parzialmente.
Lo stato sent nel registro indica una risposta HTTP 2xx, cioè l’accettazione della richiesta da parte dell’endpoint Measurement Protocol. Non si tratta di una conferma che l’evento sia già stato elaborato o mostrato nei report di Google Analytics. Il modulo non ricrea acquisti o rimborsi storici dopo l’aggiornamento e non dispone di una coda automatica, di CRON né di un pulsante che forzi la ripetizione di un invio incerto.
GA4, Google Ads, consensi e dati utente
Il modulo può inizializzare il tag GA4 per uno o due Measurement ID. Per il remarketing dinamico Google Ads richiede inoltre un identificatore nel formato AW-…. Nell’attuale modalità di acquisto in base allo stato di pagamento, gli eventi purchase e refund vengono inviati a GA4 tramite Measurement Protocol; in questa modalità il modulo non invia una conversione di acquisto diretta dal browser a Google Ads.
L’opzione dei dati forniti dall’utente richiede PD Cookie Pro attivo con Consent Mode v2 e il consenso attuale ad_user_data. Inoltre, il proprietario del negozio deve attivare la raccolta di tali dati nel servizio GA4 e nelle impostazioni del tag Google; la configurazione delle conversioni avanzate in Google Ads è un’attività separata lato account Google. La revoca del consenso rimuove i dati identificativi dalla configurazione del tag, e l’invio lato server delle operazioni finanziarie verifica nuovamente il consenso attuale prima dell’invio. User ID e dati forniti dall'utente richiedono anche PD Cookie Pro attivo in modalità live, Consent Mode v2 e la revisione corrente del consenso. La revoca di analytics_storage azzera User ID nel tag; la revoca di ad_user_data azzera user_data. Ciò non elimina i dati già trasmessi a Google.
Configurazione e verifica dell’implementazione
- Inserisci il Measurement ID GA4 principale e il secondo identificatore solo se necessario.
- Per acquisti e rimborsi, inserisci l’API Secret di Measurement Protocol e seleziona gli stati che confermano realmente il pagamento e il rimborso completo dell’ordine nel negozio in questione.
- Scegli il formato di
item_id in base all’identificatore utilizzato nel catalogo o nel feed prodotti.
- Attiva solo le funzioni necessarie di Google Ads, User ID e dati forniti dall’utente, dopo aver verificato impostazioni e consensi negli strumenti Google.
- Per il test usa la modalità di debug e GA4 DebugView, e per le operazioni finanziarie controlla il registro del modulo. Il test deve essere eseguito sul reale percorso di acquisto e sul corretto stato dell’ordine.
Ambito del modulo e limitazioni importanti
- Il modulo trasmette i dati ai servizi Google configurati; non crea né amministra account GA4, Google Ads, Merchant Center o campagne pubblicitarie.
- Non sostituisce la configurazione dei consensi né l’analisi legale del negozio. Il proprietario del negozio è responsabile della base giuridica del trattamento dei dati, del contenuto dei consensi e delle impostazioni degli account Google.
- Il blocco degli script, la mancanza di consenso, l’assenza di attribuzione salvata, identificatori errati o impostazioni Google possono limitare la misurazione. Il modulo non garantisce la completezza dei dati.
- L’invio dei dati con API Secret richiede una corretta configurazione di GA4. La risposta HTTP 2xx deve essere considerata come conferma di ricezione della richiesta, non come prova della visibilità della transazione nei report.
