- Il tracciamento server-side invia gli eventi di conversione, come gli acquisti, da un server all’API della piattaforma pubblicitaria, invece che solo da un pixel nel browser.
- Quando l’acquisto viene inviato dai dati dell’ordine del tuo negozio, gli ad blocker e una pagina di ringraziamento che non si carica mai non causano più vendite perse.
- Il browser serve ancora per salvare il click id all’arrivo, e il pixel può funzionare insieme al server con lo stesso event_id, così ogni acquisto viene contato una sola volta.
- Il server-side tagging, come un container server di Google Tag Manager, parte comunque dagli eventi del browser, quindi non può recuperare gli acquisti che il browser non ha mai inviato.
- Il tracciamento server-side non è un modo per aggirare il consenso: le norme sulla privacy si applicano ai dati qualunque strada prendano.
Tracciamento server-side significa che gli eventi di conversione, come un acquisto, vengono inviati alle piattaforme pubblicitarie da un server invece che solo da uno script nel browser dell’acquirente. Per un negozio online, il server invia ogni ordine a Meta, TikTok o Google tramite le loro API, così la vendita viene registrata anche quando il pixel del browser è bloccato o non si carica mai.
Questa guida spiega la differenza tra un pixel del browser e il tracciamento server-side, segue i dati dal clic sull’annuncio fino alla piattaforma pubblicitaria e mostra cosa contiene un evento server. Tratta anche la deduplicazione, il server-side tagging, il consenso e come capire se il tuo negozio ne ha bisogno. Per la configurazione su Shopify, leggi il tracciamento server-side su Shopify.
Pixel del browser vs tracciamento server-side
Un pixel del browser è un frammento di JavaScript della piattaforma pubblicitaria. Gira sulle tue pagine e invia gli eventi dal dispositivo dell’acquirente direttamente alla piattaforma: una visualizzazione di pagina, un’aggiunta al carrello, un acquisto sulla pagina di ringraziamento. Funziona solo se lo script si carica, viene eseguito e raggiunge la piattaforma prima che l’acquirente lasci la pagina.
Il tracciamento server-side sposta l’invio su un server. L’evento può partire da dati che il tuo negozio ha già, come un ordine pagato, e il server lo invia all’API della piattaforma. Meta chiama questa API Conversions API e TikTok la chiama Events API. Google Ads usa le conversioni avanzate, che aggiungono alla conversione dati del cliente sottoposti ad hash.
- Viene eseguito nel browser dell’acquirente
- Invia gli eventi direttamente alla piattaforma pubblicitaria
- Imposta e legge cookie first-party, come _fbp per Meta
- Non invia nulla se lo script è bloccato o la pagina non si carica
- Gira su un server controllato da te o da un fornitore di servizi
- Invia gli eventi all’API della piattaforma
- Può partire dall’ordine registrato nel tuo negozio
- Non dipende dal caricamento della pagina di ringraziamento
Usarli entrambi dà alla piattaforma i dati più completi. L’evento del browser aggiunge cookie e contesto della pagina. L’evento del server arriva anche quando il browser fallisce. Un event id condiviso garantisce che la piattaforma conti ogni acquisto una sola volta.
Come funziona il tracciamento server-side?
Il tracciamento server-side per un negozio online ha due metà. La prima avviene nel browser: quando un acquirente arriva da un annuncio, uno script salva il click id dall’URL. La seconda avviene sul server: quando l’ordine viene pagato, il server collega quel click id all’ordine e invia l’acquisto.
Catturare il clic
Le piattaforme pubblicitarie aggiungono un click id all’URL della landing page: fbclid per Meta, ttclid per TikTok, gclid per Google Ads e msclkid per Microsoft Ads. Il click id è il collegamento più forte tra una vendita e l’annuncio che l’ha generata, quindi va salvato alla prima visualizzazione di pagina. I parametri UTM aggiungono i nomi di campagna, gruppo di annunci e annuncio in un formato che controlli tu.
Abbinare l’ordine
Il server deve poi sapere quale visitatore ha effettuato l’ordine. Il collegamento più affidabile è un valore che viaggia con il carrello fino all’ordine, come un visitor id salvato sul carrello. Gli altri metodi sono più deboli: un indirizzo email inserito dal visitatore in precedenza sul sito, oppure lo stesso indirizzo IP e lo stesso browser visti poco prima dell’ordine. Ogni piattaforma di negozio online offre opzioni diverse. La nostra guida per gli altri negozi online elenca i metodi che ROASaurus usa per ogni piattaforma.
Invio dell’evento
Infine il server invia l’acquisto all’API di ogni piattaforma. L’evento include il valore dell’ordine, il click id e i dati del cliente che aiutano la piattaforma a trovare la persona che ha cliccato. Se una piattaforma non è raggiungibile o restituisce un errore, una buona configurazione riprova più tardi, così l’acquisto non va perso.
Cosa contiene un evento server?
Ogni piattaforma ha i propri nomi dei campi, ma un evento di acquisto porta ovunque gli stessi tipi di dati. Ecco un esempio abbreviato per la Meta Conversions API:
{
"data": [{
"event_name": "Purchase",
"event_time": 1793009700,
"event_id": "order-1042",
"action_source": "website",
"event_source_url": "https://yourstore.com/checkout/thank-you",
"user_data": {
"em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
"ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
"client_ip_address": "203.0.113.24",
"client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
"fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
"fbp": "fb.1.1792832529000.1234567890"
},
"custom_data": { "currency": "USD", "value": 84.00 }
}]
}| Campo | Cos’è | Con hash? |
|---|---|---|
| Nome e ora dell’evento | Purchase, e il momento in cui è stato effettuato l’ordine | No |
| Valore e valuta | Il valore dell’ordine che la piattaforma usa per il ROAS e per le offerte basate sul valore | No |
event_id | Un id univoco per evento, lo stesso nel browser e sul server, per la deduplicazione | No |
| Email, telefono, nome, indirizzo | Dati del cliente presi dall’ordine, normalizzati e sottoposti ad hash con SHA-256 | Sì |
| Click id (fbc, ttclid, gclid) | L’id del clic sull’annuncio, salvato quando l’acquirente è arrivato | No |
| Indirizzo IP e user agent | Aiutano la piattaforma ad associare l’evento a un dispositivo | No |
L’hash trasforma un indirizzo email in una stringa di caratteri di lunghezza fissa. Lo stesso indirizzo dà sempre la stessa stringa, ma la stringa non rivela l’indirizzo. La piattaforma usa i valori con hash solo per cercare una corrispondenza tra i propri utenti. È così che un acquisto può essere associato alla persona che ha visto o cliccato l’annuncio, anche quando il browser di quella persona ha bloccato il pixel.
Come funziona la deduplicazione?
Quando il pixel e il server inviano entrambi lo stesso acquisto, la piattaforma deve contarlo una volta sola. Entrambe le copie portano lo stesso nome evento e lo stesso event id, per esempio order-1042. Meta confronta la coppia e tiene una sola copia, purché la seconda arrivi entro 48 ore dalla prima.
Purchase event_id=order-1042 browserRicevuto dal pixelPurchase event_id=order-1042 serverStesso nome e stesso id: contato una voltaPurchase event_id=order-1043 serverIl pixel è stato bloccato: la copia del server è l’unicaPurchase event_id=1044 serverIl browser ha inviato order-1044: gli id sono diversi, quindi viene contato due volteIl doppio conteggio nasce quasi sempre da due mittenti che non condividono gli id. Un caso tipico è l’app per negozi di una piattaforma e uno strumento di tracciamento separato che inviano entrambi gli acquisti con i propri id. Il nostro articolo di aiuto su come evitare il doppio conteggio elenca le cause e le soluzioni più comuni.
Server-side tagging vs invio dai dati dell’ordine
Il termine tracciamento server-side viene usato per due configurazioni diverse. Entrambe inviano eventi da un server, ma partono da punti diversi.
Server-side tagging, come i container server di Google Tag Manager
Con il server-side tagging, il browser invia i propri eventi al tuo server invece che a ciascun fornitore. Il container server di Google Tag Manager ne è un esempio noto. Gira nel tuo progetto Google Cloud o in un altro ambiente a tua scelta. Riceve le richieste dal browser e i suoi tag inoltrano i dati a Google Analytics, Meta e altri fornitori. Sei tu a decidere quali dati vanno dove, e il server può girare su un sottodominio del tuo sito.
Gli eventi partono comunque dal browser. Se il tag nel browser è bloccato, o la pagina di ringraziamento non si carica mai, il container server non ha nulla da inoltrare. Inoltre il server lo gestisci, lo paghi e lo aggiorni tu.
Invio dai dati dell’ordine
Il secondo approccio fa partire l’acquisto dall’ordine registrato nel tuo negozio. Il negozio comunica l’ordine pagato al server tramite un webhook o un’API, e il server lo invia a ogni piattaforma collegata. Il browser serve solo prima, per salvare il click id quando l’acquirente arriva.
| Server-side tagging | Invio dai dati dell’ordine | |
|---|---|---|
| Da dove parte l’acquisto | Un tag nel browser | L’ordine pagato nel tuo negozio |
| Pagina di ringraziamento chiusa in anticipo | Acquisto perso | Acquisto inviato |
| Tag bloccato nel browser | Acquisto perso, a meno che l’endpoint first-party non passi | Acquisto inviato |
| Pagamento alla consegna e pagine di pagamento esterne | Dipende dalla pagina di ringraziamento | Inviato quando l’ordine viene creato o pagato |
| Eventi di navigazione (visualizzazioni di pagina, aggiunte al carrello) | Sì | Richiede un collettore separato nel browser |
| Chi gestisce il server | Tu: hosting e aggiornamenti | Tu o un fornitore di servizi |
I due approcci si possono combinare. Molti negozi raccolgono nel browser le visualizzazioni di pagina e gli eventi di aggiunta al carrello, e inviano l’acquisto dai dati dell’ordine. L’acquisto è l’evento che le piattaforme pubblicitarie usano per riportare il ROAS e per ottimizzare le offerte, quindi è quello che ha più bisogno di essere completo.
Cosa risolve il tracciamento server-side e cosa non risolve?
- Acquisti persi perché un ad blocker ha bloccato il pixel
- Acquisti persi perché la pagina di ringraziamento non si è caricata
- Acquisti con metodi di pagamento che si concludono fuori dal tuo sito
- Associazione debole, aggiungendo a ogni evento dati del cliente sottoposti ad hash
- Consenso: un visitatore che ha rifiutato resta un visitatore che ha rifiutato
- Finestre e modelli di attribuzione diversi per ogni piattaforma
- Mittenti duplicati che usano event id diversi
- Click id che non sono mai stati salvati all’arrivo
Il consenso continua ad applicarsi
Il tracciamento server-side è un modo di consegnare i dati, non un modo per aggirare le norme sulla privacy. Dove la legge richiede il consenso per i cookie di marketing o per il tracciamento, quell’obbligo copre i dati che raccogli, qualunque strada prendano verso la piattaforma. Spostare un tracker sul tuo server non cambia ciò a cui un visitatore ha acconsentito.
L’attribuzione resta specifica di ogni piattaforma
Ogni piattaforma continua ad attribuire gli acquisti con le proprie finestre e le proprie regole. Gli eventi server danno a ogni piattaforma dati migliori, ma i totali di Meta, TikTok e Google possono comunque sommarsi a più dei ricavi del tuo negozio. Per confrontare i canali con un unico insieme di regole, usa un solo modello di attribuzione per tutti, come i modelli dell’attribuzione di ROASaurus.
Il tuo negozio ha bisogno del tracciamento server-side?
Un negozio che spende un budget significativo in annunci social o di ricerca a pagamento di solito ne trae vantaggio. Il vantaggio è più netto quando diversi di questi punti sono veri:
- La piattaforma pubblicitaria riceve chiaramente meno eventi di acquisto di quanti ordini web abbia il tuo negozio. La nostra guida a ad blocker e tracciamento mostra come misurare questo divario.
- Molti dei tuoi visitatori usano Safari su iPhone o Mac, dove i cookie impostati dagli script durano al massimo 7 giorni. Vedi Safari ITP e tracciamento pubblicitario.
- Gli acquirenti spesso comprano giorni dopo il primo clic sull’annuncio.
- Il pagamento si conclude fuori dal tuo sito, oppure gli ordini vengono pagati in un secondo momento, come con il pagamento alla consegna o il bonifico bancario.
- Ottimizzi le campagne per gli acquisti o per il valore degli acquisti, quindi la piattaforma ha bisogno di ogni vendita da cui imparare.
Ecco come un divario cambia le decisioni nella pratica. Un negozio di esempio ha 1,000 ordini web in un mese. Il suo pixel Meta ha registrato 820 eventi Purchase, quindi il 18% degli ordini non è mai arrivato a Meta dal browser.
Il ROAS di pareggio del negozio è 2.5 e Ads Manager mostra un ROAS di 2.3 sui dati del pixel. Con questi numeri le campagne perdono denaro. Se gli ordini generati dagli annunci fossero stati persi allo stesso tasso del 18%, il ROAS reale sarebbe circa 2.3 ÷ 0.82 = 2.8, sopra il pareggio. È una stima per eccesso, perché non tutti gli ordini mancanti provenivano da un annuncio. Mostra comunque come un divario nel tracciamento possa far sembrare in perdita una campagna redditizia.
Il tracciamento server-side conta meno per un negozio che non fa pubblicità o che spende pochissimo in annunci.
Come ROASaurus invia gli eventi server-side
ROASaurus acquisisce 19 click id e sei campi UTM all’arrivo e li salva con un visitor id first-party. Invia ogni acquisto dagli ordini pagati del tuo negozio a Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll e Outbrain. Su Shopify, le conversioni di Google Ads vengono inviate dal checkout di Shopify. I pixel del browser possono funzionare insieme agli eventi server con lo stesso event id, e Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin e Spotify li deduplicano. Ogni invio e la risposta della piattaforma sono elencati nell’Event log.
Approfondisci nella pagina sul tracciamento server-side, oppure trova il tuo negozio online nella pagina delle integrazioni.
Fonti
- Meta for Developers: Conversions API
- Meta for Developers: Handling Duplicate Pixel and Conversions API Events
- Meta for Developers: Customer Information Parameters
- Google for Developers: An introduction to server-side tagging
- Google Ads Help: About enhanced conversions