--- type: "product" id: 215 url: "https://prestadev.pl/it/google-analytics-4-pro-modulo-per-prestashop.html" markdown_url: "https://prestadev.pl/it/markdown/product/215.md" title: "Google Analytics 4 Pro modulo per PrestaShop" description: "Implementa GA4 in PrestaShop: eventi e-commerce, misurazione degli acquisti e Google Ads. Utilizza il tracciamento JavaScript e l'invio delle transazioni tramite Measurement Protocol." image: "https://prestadev.pl/1304/google-analytics-4-pro-modulo-per-prestashop.jpg" sku: "PDGA4P" brand: "PrestaDev.pl" price: 169.00 regular_price: 189.00 discount_percent: 10.58 discount_amount: 20.00 price_tax_excluded: 137.40 currency: "PLN" tax_included: true availability: "in_stock" is_pack: false customization_required: false condition: "new" categories: ["Integrazioni Google", "Integrazioni PrestaShop", "Moduli PrestaShop", "Principale", "Pubblicità e analisi"] language: "it" updated: "2026-10-15" --- # Google Analytics 4 Pro modulo per PrestaShop **Google Analytics 4 Pro** aggiunge a PrestaShop la misurazione Google per prodotti, carrello, checkout, ricerca e account. La versione 1.4.2 invia acquisti e rimborsi idonei al flusso GA4 principale via Measurement Protocol: servono API Secret, attribuzione salvata e PD Cookie Pro attivo in modalità live con Consent Mode v2 e consenso analitico. Le opzioni includono un secondo ID GA4, User ID, dati forniti dall'utente e remarketing dinamico Google Ads. Il modulo non configura gli account Google né garantisce report completi. ## Description 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 1. Inserisci il Measurement ID GA4 principale e il secondo identificatore solo se necessario. 2. 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. 3. Scegli il formato di `item_id` in base all’identificatore utilizzato nel catalogo o nel feed prodotti. 4. Attiva solo le funzioni necessarie di Google Ads, User ID e dati forniti dall’utente, dopo aver verificato impostazioni e consensi negli strumenti Google. 5. 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. ## Features | Feature | Value | | --- | --- | | Supporto per Prestashop 9.x | Sì | | Supporto per Prestashop 8.x | SÌ | | Supporto per Prestashop 1.7.x | sì | | Traduzioni di moduli | PL, IT | | Supporto gratuito | sì | | Aggiornamenti gratuiti (1 anno) | sì | | Facile da installare | sì | | Richiede la modifica del motore | No | ## Variants | Variant | SKU | Price | Availability | Variant ID | | --- | --- | --- | --- | --- | | Tipo di licenza / aggiornamento: Versione completa / licenza a vita | ` PDGA4P-FULL ` | 169.00 | ` in_stock ` | ` 598 ` | | Tipo di licenza / aggiornamento: Solo aggiornamento (proroga dell'accesso per ulteriori 12 mesi) | ` PDGA4P-UPD ` | 84.50 | ` in_stock ` | ` 599 ` | ## Categories - Integrazioni Google - Integrazioni PrestaShop - Moduli PrestaShop - Principale - Pubblicità e analisi ## Related products - [Google Remarketing Dinamico Pro per PrestaShop](https://prestadev.pl/it/markdown/product/102.md) - [Google Shopping Pro / Google Shopping per PrestaShop](https://prestadev.pl/it/markdown/product/128.md) - [Google Tag Manager Pro modulo per PrestaShop](https://prestadev.pl/it/markdown/product/329.md) - [Modulo Google AdWords monitoraggio delle conversioni di vendita Pro per PrestaShop](https://prestadev.pl/it/markdown/product/57.md) ## Questions and answers ### A cosa serve il modulo Google Analytics 4 Pro per PrestaShop? Language: it Google Analytics 4 Pro aggiunge al negozio il tag Google e trasmette a Google Analytics 4 gli eventi relativi ai prodotti, al carrello, al checkout, alla ricerca e all’account cliente. Una parte separata del modulo invia gli acquisti idonei e i resi supportati al flusso principale di GA4 tramite Measurement Protocol. Il modulo non crea un account GA4 né gestisce le campagne Google Ads. ### Con quali versioni di PrestaShop è compatibile il modulo? Language: it La versione 1.4.2 dichiara la compatibilità con le serie PrestaShop 1.7.x, 8.x e 9.x. Le librerie HTTP incluse richiedono almeno PHP 7.2.5; occorre inoltre rispettare i requisiti PHP della versione di PrestaShop utilizzata. Questo non implica la compatibilità con PHP 7.0 o 7.1 né la conferma dell'intera matrice di versioni. Prima dell'implementazione è necessario verificare il negozio, il tema e il checkout specifici, perché gli altri moduli e il codice HTML e JavaScript della pagina influiscono sugli eventi del browser. ### Quali dati bisogna preparare per la configurazione di GA4? Language: it La base è il Measurement ID principale di GA4 nel formato G-XXXXXXXX. Per l’invio server-side di acquisti e resi è necessario fornire l’API Secret del Measurement Protocol e selezionare gli stati dell’ordine che confermano effettivamente il pagamento e il rimborso completo. Le funzioni di Google Ads richiedono un identificatore separato AW-XXXXXXXXX, mentre l’opzione dei dati forniti dall’utente richiede anche impostazioni corrette e consensi lato Google. Nella versione 1.4.2, gli eventi purchase e refund server-side richiedono inoltre un PD Cookie Pro attivo in modalità live con Consent Mode v2, una revisione aggiornata del consenso analitico e il contesto del cliente conservato. ### Quanti eventi gestisce il modulo? Language: it Il codice del modulo elenca 15 eventi e-commerce e account denominati: 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. Separatamente è possibile attivare o disattivare il page\_view automatico. Pertanto, i 15 eventi elencati non devono essere definiti “16 eventi e-commerce”. ### Quali eventi vengono inviati negli elenchi e nelle schede prodotto? Language: it Nelle liste di prodotti supportate, il modulo invia view\_item\_list e, dopo il clic sul prodotto, select\_item. Nella scheda prodotto invia view\_item, anche dopo la modifica della variante nell'interfaccia supportata. Negli eventi può trasmettere l'identificativo del prodotto, il nome, la variante, il marchio, le categorie, il prezzo, lo sconto e la posizione nell'elenco. ### Come misura il modulo le azioni nel carrello e nel checkout? Language: it Il modulo supporta add\_to\_cart, remove\_from\_cart e view\_cart, e all'ingresso in un processo d'ordine supportato begin\_checkout. I template per il checkout trasmettono anche add\_shipping\_info e add\_payment\_info. Gli eventi contengono gli articoli del carrello, le quantità, i prezzi, la valuta e il coupon disponibile, se i dati sono disponibili in PrestaShop. ### Il modulo misura la ricerca, la registrazione e il login? Language: it Sì. L'elenco delle funzioni del modulo comprende gli eventi search, view\_search\_results, sign\_up e login. Per la ricerca, il codice recupera la frase di ricerca e prepara i risultati dei prodotti disponibili; vale la pena verificare il funzionamento del singolo evento in DebugView sul tema utilizzato. ### Quando il modulo invia l'evento purchase a GA4? Language: it Dalla versione 1.4 purchase viene inviato dal server solo dopo il salvataggio nella cronologia dell’ordine dello stato selezionato nella configurazione come conferma del pagamento o dell’incasso del dovuto. Il semplice clic sul pulsante di pagamento e la sola pagina di conferma non sono considerati una conferma del pagamento. Un ulteriore tentativo nella pagina di conferma può gestire solo un ordine non inviato che soddisfa le stesse condizioni. ### Quali condizioni sono necessarie per l'invio lato server di un acquisto o di un reso? Language: it La versione 1.4.2 richiede il Measurement ID principale, l'API Secret, uno stato di acquisto selezionato, l'attribuzione salvata con client\_id e session\_id e un consenso analitico corrente. Il rimborso totale attivato da uno stato richiede una configurazione separata degli stati di rimborso. Il consenso registrato proviene da PD Cookie Pro attivo nel negozio in modalità live con Consent Mode v2 e la versione corrente del consenso; un'altra CMP non soddisfa automaticamente questa condizione. Per i dati dell'utente viene verificato separatamente il consenso ad\_user\_data. L'acquisto non viene inviato in presenza di confezionamento a pagamento, di oltre 200 righe di prodotti o di un riferimento/EAN vuoto quando si usa tale formato di item\_id. Anche gli importi e le voci devono essere validati. ### La risposta HTTP 2xx significa che l'acquisto è già visibile nei report di GA4? Language: it No. Nel registro del modulo, lo stato sent indica che l’endpoint Measurement Protocol ha restituito una risposta HTTP 2xx, quindi ha accettato la richiesta. Non si tratta di una conferma dell’elaborazione dell’evento né della sua visibilità nei report di Google Analytics. La ricezione deve essere verificata nel servizio e nel flusso Google corretti. ### Il Measurement Protocol garantisce la misurazione quando il cliente utilizza un ad blocker? Language: it Non esiste una tale garanzia. L'invio server-side dell'acquisto richiede un'attribuzione precedentemente salvata, inclusi i dati di sessione, nonché un consenso analitico attuale. Il blocco degli script, la mancanza di consenso, una configurazione errata o limitazioni da parte di Google possono impedire o limitare la misurazione. ### Come gestisce il modulo i resi completi? Language: it Per il rimborso completo l'amministratore seleziona stati separati che attivano il rimborso. Il modulo richiede un acquisto precedente registrato come sent nel proprio registro e un precedente stato di pagamento. La reimpostazione dello stesso stato non invia un ulteriore rimborso completo e viene contabilizzato esclusivamente il valore residuo dopo i rimborsi precedenti. ### Il modulo supporta i resi parziali e le correzioni di PrestaShop? Language: it Il modulo supporta le nuove note di credito di PrestaShop idonee con voci salvate, compreso il rimborso di una parte della quantità dei prodotti, se l'acquisto è stato precedentemente registrato come sent ed esiste uno stato di acquisto idoneo. Non sono incluse tutte le note di credito: vengono rifiutati i record con il flag tecnico partial != 0 e i tipi diversi da 0 o 2; il tipo 2 è supportato solo quando rappresenta inequivocabilmente il rimborso delle sole spese di spedizione. Vengono inoltre rifiutati gli importi arbitrari ambigui e le voci incoerenti. Il rimborso parziale della quantità non equivale al flag partial. Le note di credito storiche precedenti all'attivazione di questa gestione non vengono ricostruite. ### Il modulo invierà i vecchi acquisti e resi dopo l'installazione o l'aggiornamento? Language: it Non è prevista la ricostruzione automatica dello storico. L'aggiornamento salva i limiti degli ordini esistenti, della cronologia degli stati e delle note di credito e non reimposta i flag di invio conservati. Per un ordine precedente, la prima voce idonea dello stato di acquisto deve essere successiva al limite salvato della cronologia; sono inoltre necessari un record del carrello conservato con order\_send=0 e l'assenza di un invio precedente. La sola reimpostazione dello stato non basta quando una precedente voce idonea è anteriore a tale limite. ### Il modulo ritenta automaticamente un invio non riuscito o incerto? Language: it Non sono presenti una coda automatica, un CRON o un pulsante per forzare un nuovo tentativo di un'operazione finanziaria. Un'operazione non inviata in stato pending può essere ritentata al successivo evento di attivazione appropriato, ad esempio uno stato idoneo o la pagina di conferma, se soddisfa tutte le condizioni. Lo stato sending dopo un'interruzione e unknown in caso di esito incerto del trasporto bloccano il nuovo tentativo automatico per limitare il rischio di duplicati. Non vengono trattati come le operazioni non inviate in stato pending. ### Come fa il modulo a prevenire il doppio invio di purchase e refund? Language: it Il modulo controlla le proprie operazioni finanziarie tramite un registro persistente con una chiave unica per operazione e un blocco di concorrenza per l'ordine. Per l'acquisto e il rimborso vengono salvati gli importi, la valuta e le voci, mentre i rimborsi sono limitati al valore dell'acquisto precedentemente inviato. Uno stato incerto non viene automaticamente considerato come non inviato. Questi meccanismi non eliminano i duplicati inviati indipendentemente da GTM o da altri moduli. ### È possibile inserire due identificatori Google Analytics 4? Language: it Sì. La configurazione contiene l'ID di misurazione principale e un secondo ID di misurazione opzionale. Il tag del browser inizializza entrambi gli identificatori configurati, il che può servire, ad esempio, per una misurazione parallela in un secondo servizio GA4. Gli eventi purchase e refund lato server vengono inviati al flusso principale utilizzato per l'attribuzione. ### Come si può configurare l'identificatore del prodotto item\\\_id? Language: it Sono disponibili le seguenti opzioni: ID prodotto, ID prodotto con ID combinazione separato da un trattino, ID prodotto con ID combinazione separato da un trattino basso, riferimento prodotto ed EAN. La variante riferimento o EAN utilizza il valore della combinazione, se disponibile. Il formato selezionato deve corrispondere all'identificatore utilizzato nel catalogo o nel feed di prodotto. ### Il modulo trasmette i codici sconto a GA4? Language: it Negli eventi del browser supportati, il modulo può trasmettere il nome e il codice della regola del carrello applicata come informazione sul coupon. Nella versione 1.4.2, purchase lato server inviato tramite Measurement Protocol non contiene il campo coupon né i codici coupon nelle voci. Il modulo non crea sconti, regole del carrello o codici promozionali in PrestaShop. ### A cosa serve l'opzione ID utente? Language: it Dopo l'attivazione di User ID, il modulo trasmette l'identificativo tecnico del cliente autenticato nel browser e l'identificativo del cliente dell'ordine negli eventi lato server. La versione 1.4.2 richiede il consenso analytics\_storage da PD Cookie Pro attivo nel negozio in modalità live con Consent Mode v2 e una versione del consenso corrispondente a quella corrente. User ID è indipendente dai dati forniti dagli utenti, non è un hash dell'indirizzo email e non sostituisce i dati di contatto. ### Quali dati dell'utente può trasmettere il modulo al tag Google e al Measurement Protocol? Language: it Dopo aver attivato l'opzione appropriata, il modulo può utilizzare l'e-mail salvata in PrestaShop e, facoltativamente, il numero di telefono e i dati dell'indirizzo. Il solo indirizzo e-mail corretto è sufficiente; il telefono e l'indirizzo sono dati aggiuntivi, se soddisfano le condizioni di convalida. Il modulo non legge i campi non salvati inseriti nel modulo né gli indirizzi e-mail presenti nel contenuto della pagina. ### I dati identificativi del cliente sono sottoposti ad hashing? Language: it Sì. E-mail, telefono, nome e cognome vengono normalizzati e sottoposti a hash SHA-256 prima della trasmissione. Per l’invio tramite Measurement Protocol è supportato anche l’hash della via, mentre il codice postale, il Paese e facoltativamente la città hanno il formato richiesto da Google. I dati e gli hash non vengono aggiunti al registro delle transazioni né alla configurazione del modulo. ### Quali consensi sono richiesti per il trasferimento dei dati dell'utente? Language: it I dati forniti dagli utenti richiedono il consenso ad\_user\_data corrente da PD Cookie Pro attivo nel negozio in modalità live con Consent Mode v2 e una versione del consenso corrispondente a quella corrente. User ID e l'invio lato server tramite Measurement Protocol richiedono il consenso analytics\_storage. La revoca di analytics\_storage azzera User ID nel tag, mentre la revoca di ad\_user\_data azzera user\_data; questo non elimina i dati già trasmessi a Google. Prima dell'invio di un'operazione finanziaria, il modulo rilegge lo stato del consenso salvato e la sua versione, senza basarsi sui cookie del callback di pagamento. ### È sufficiente abilitare l'opzione nel modulo per utilizzare i dati trasmessi dall'utente o le conversioni avanzate? Language: it No. Il proprietario del negozio deve abilitare la raccolta dei dati forniti dall’utente nel servizio GA4 e nelle impostazioni del relativo tag Google. Le conversioni avanzate richiedono una configurazione separata lato Google Ads. Il modulo non ha accesso alle impostazioni dell’account Google e non può abilitarle automaticamente. ### Come funziona il remarketing dinamico di Google Ads? Language: it Dopo aver attivato la funzione e configurato il Google Ads Conversion ID, il modulo trasmette al tag i dati di remarketing sulle pagine del negozio: identificatori dei prodotti, tipo di pagina e valore del carrello. Questi dati possono essere utilizzati nella configurazione del remarketing dinamico di Google Ads. Il modulo non crea campagne, segmenti di pubblico né annunci nel pannello di Google Ads. ### Il modulo invia la conversione di acquisto diretta a Google Ads? Language: it Nella modalità di acquisto attuale, in base allo stato del pagamento, purchase e refund vengono inviati a GA4 tramite Measurement Protocol. In questa modalità, il codice del modulo non invia direttamente la conversione browser-side dell'acquisto a Google Ads. L'identificatore Google Ads viene utilizzato, tra l'altro, per la configurazione del tag e il remarketing dinamico. ### Gli acquisti e i rimborsi vengono inviati al secondo stream GA4? Language: it No. Nella versione 1.4.2, il secondo Measurement ID serve al funzionamento parallelo del tag nel browser. Gli eventi purchase e refund lato server vengono inviati tramite Measurement Protocol soltanto allo stream principale associato all'attribuzione salvata. L'API Secret deve appartenere a questo stream principale. La configurazione di un secondo Measurement ID non duplica gli acquisti e i rimborsi lato server nella seconda proprietà GA4. ### A cosa servono la modalità di debug e GA4 DebugView? Language: it La modalità di debug registra gli eventi del browser nella console e imposta per essi debug\_mode, utilizzato da GA4 DebugView. Nella versione 1.4.2, l'interruttore non aggiunge questo flag agli eventi purchase e refund lato server e non attiva l'endpoint di validazione di Measurement Protocol. Gli eventi finanziari devono essere verificati separatamente nel registro del modulo e nella proprietà e nei report GA4 corretti; una risposta HTTP 2xx non conferma l'elaborazione dell'evento. La modalità va disattivata al termine della diagnostica. ### Cosa mostra il pannello di stato e il registro finanziario del modulo? Language: it Il pannello di stato mostra se GA4, Google Ads e Measurement Protocol sono configurati, se la modalità di debug è attiva e l’ultimo acquisto con risposta HTTP 2xx. Il registro finanziario è di sola lettura e offre il filtraggio, l’ordinamento e la paginazione delle registrazioni purchase e refund. Non espone segreti API, identificatori del browser né payload grezzi. ### Il modulo funziona con il checkout in una sola pagina? Language: it Il codice del modulo supporta la pagina d’ordine standard e i percorsi utilizzati dalle popolari soluzioni di one-page checkout, e nella descrizione della configurazione sono indicati, tra gli altri, TheCheckout, SuperCheckout e STEasyCheckout. Poiché gli eventi del browser dipendono dall’effettivo HTML e JavaScript del checkout, dopo l’installazione è necessario eseguire un test dell’intero percorso carrello–pagamento–stato dell’ordine nel tema utilizzato. ### È possibile disattivare il page\\\_view automatico? Language: it Sì. Nella configurazione è presente un interruttore per il page\_view automatico. Può essere disattivato quando le visualizzazioni di pagina sono già gestite da Google Tag Manager o da un altro strumento, per evitare di creare una misurazione duplicata delle visualizzazioni di pagina. La disattivazione del page\_view non rimuove le altre funzioni degli eventi del modulo. ### Il modulo garantisce la conformità legale, la completezza dei dati e i risultati della campagna? Language: it No. Il modulo trasmette tecnicamente i dati configurati ai servizi Google, ma non sostituisce l’implementazione dei consensi, l’analisi legale né la configurazione degli account GA4 e Google Ads. Il proprietario del negozio è responsabile della base giuridica del trattamento dei dati, del contenuto dei consensi e delle impostazioni dei servizi Google. La completezza dei dati e i risultati delle campagne dipendono anche dai consensi degli utenti, dal browser, dal tema, dal checkout e dai sistemi Google. ## Customer reviews - Average rating: 4.50/5 - Public reviews: 4 - Source: iqitreviews