Sin impuesto Con impuesto

Conversioni dal server: Meta CAPI, GA4 e deduplicazione nel tuo negozio

Gli ad blocker e i limiti sui cookie fanno sì che il pixel nel browser perda parte degli acquisti. Inviare le conversioni dal server lo corregge, purché si deduplichi bene e si rispetti il consenso.

Jesús Meilán
Updated: 23/10/2026 77
Conversioni dal server: Meta CAPI, GA4 e deduplicazione nel tuo negozio
Share:

Apri il gestore inserzioni e vedi 40 acquisti. Il tuo negozio ha 60 ordini di quella campagna. La differenza non è un errore della piattaforma: sono acquisti che il browser del cliente non è mai riuscito a comunicare. Ad blocker, browser che limitano i cookie, schede chiuse prima che si carichi la pagina di conferma o pagamenti che tornano dal gateway per un'altra strada.

Il risultato è che le piattaforme ottimizzano le tue campagne con dati incompleti. La misurazione dal server (server-side) invia le conversioni direttamente dal tuo negozio alla piattaforma, senza dipendere dal browser.

Browser o server

Pixel nel browserInvio dal server
Ad blockerLo bloccanoNon lo influenzano
Pagamento che torna dal gatewayPuò andare persoSi invia alla creazione o all'incasso dell'ordine
Dati dell'ordineCiò che c'è nella paginaTutto ciò che ha il negozio
Comportamento sul sitoVede tuttoSolo ciò che il server conosce

Non si tratta di sceglierne uno: di solito si usano entrambi e si deduplica.

Meta: l'API Conversions

L'API Conversions (CAPI) riceve eventi dal tuo server con un token di accesso del pixel. Ogni evento contiene:

  • event_name (per esempio Purchase), event_time e action_source (website).
  • event_id: l'identificatore che permette di deduplicare.
  • user_data: dati del cliente con hash SHA-256 (email, telefono, nome…), più l'IP, lo user agent e i cookie _fbp e _fbc se esistono.
  • custom_data: valore, valuta, prodotti.

Deduplicazione: se il pixel e il server inviano lo stesso acquisto con lo stesso event_name e lo stesso event_id, Meta lo conta una sola volta. Senza un event_id condiviso, avrai acquisti doppi.

GA4: il Measurement Protocol

GA4 accetta eventi dal server tramite il Measurement Protocol, con un api_secret creato nel flusso di dati e l'ID di misurazione. Differenze importanti rispetto a Meta:

  • Serve il client_id del browser (deriva dal cookie _ga) per collegare l'evento alla sessione dell'utente. Senza di esso, l'acquisto compare senza sorgente di traffico.
  • Per gli acquisti, la deduplicazione si fa con il transaction_id: GA4 scarta gli acquisti ripetuti con lo stesso identificatore.
  • Gli eventi inviati con molto ritardo potrebbero non essere attribuiti alla sessione corretta.
Errore tipico: inviare l'acquisto a GA4 dal server e, in più, dalla pagina di conferma con un transaction_id diverso (per esempio, il numero del carrello in uno e il riferimento dell'ordine nell'altro). GA4 non li riconosce come lo stesso ordine e lo conta due volte.

Quando inviare l'acquisto?

  • Alla creazione dell'ordine: rapido, ma include ordini con bonifico o contrassegno che forse non verranno mai pagati.
  • All'incasso dell'ordine (quando passa a uno stato di pagamento accettato): più fedele alla realtà. È l'opzione consigliabile per la maggior parte dei negozi.

Conviene inviare anche i rimborsi, perché i report riflettano le vendite nette.

Consenso: non è facoltativo

Il fatto che l'invio avvenga dal server non cambia le regole. I dati che invii a Meta o a Google per la pubblicità richiedono il consenso dell'utente quando lo esige la normativa su cookie e protezione dei dati (in Spagna, l'articolo 22.2 della LSSI e il GDPR). In pratica:

  • Se l'utente ha rifiutato i cookie pubblicitari, i suoi identificatori non vengono inviati a quelle piattaforme.
  • Google Consent Mode v2 permette di comunicare lo stato del consenso (ad_storage, analytics_storage, ad_user_data, ad_personalization) perché Google tratti i dati di conseguenza.
  • Un rifiuto esplicito non deve mai essere sovrascritto con un valore predefinito.
  • Invia solo il necessario e con hash; il prezzo di costo o i margini non devono uscire dal tuo negozio, a meno che tu non lo decida.

Relay: un intermediario tra il negozio e le piattaforme

Una variante è non inviare direttamente dal negozio, ma a un server intermedio (un relay) che riceve gli eventi firmati e si occupa di consegnarli a ogni piattaforma, con i relativi tentativi e credenziali. Vantaggi: le chiavi delle piattaforme non risiedono nel negozio, i nuovi tentativi non caricano il tuo server e si possono gestire più negozi da un unico punto.

Checklist

  1. Pixel e server condividono l'event_id in Meta.
  2. GA4 riceve il client_id reale e un transaction_id univoco e costante.
  3. L'acquisto si invia all'incasso, e anche i rimborsi.
  4. Il consenso viene rispettato prima di caricare i tag e prima di inviare dal server.
  5. Confronti ogni settimana gli ordini del negozio con le conversioni su ogni piattaforma.
  6. Controlli in Gestione eventi di Meta la qualità della corrispondenza degli eventi.

Come risolverlo in PrestaShop

RKR API Conversions Pro invia le conversioni dal server a Meta, GA4, Google Ads, TikTok, Microsoft Ads, Pinterest, Snapchat, LinkedIn e OpenAI / ChatGPT Ads, con lo stesso event_id del tag nel browser perché la piattaforma deduplichi, e in GA4 evita che un evento arrivi due volte. Gli acquisti possono essere inviati all'incasso dell'ordine, e include rimborsi parziali e cancellazioni. Applica Consent Mode v2, ripristina il consenso salvato prima di caricare i tag, ha adattatori per Cookiebot, CookieYes, Complianz e OneTrust e non sovrascrive mai un rifiuto esplicito. In modalità coda non fa chiamate di rete mentre si genera la pagina o si paga, e una riconciliazione giornaliera confronta gli ordini con quanto consegnato a ogni piattaforma. Può anche inviare gli eventi a un relay lato server, con chiamate firmate e solo identificatori con hash; i piani di relay di Rekire accompagnano questo articolo.

Caricamento...
Consenso sui cookie
Torna all'inizio