Recupera i dati che il browser perde, ma non aggira il consenso e non si mantiene da solo. Come funziona, cosa non risolve e quando lasciar perdere.
Il tracking server-side viene venduto come un interruttore: lo accendi e recuperi le conversioni che il browser ti fa perdere. In parte è vero, qualcosa recuperi davvero. Quello che non ti dicono è quanto costa tenerlo in piedi, e che oltre una certa dose di entusiasmo diventa il modo più elegante di avere numeri sbagliati con più sicurezza di prima.
Conviene capire il meccanismo. Non la sigla: il meccanismo.
Il tracciamento classico funziona così: la pagina carica uno script, lo script raccoglie qualche informazione e la spedisce al dominio della piattaforma. Tutto dentro il browser di chi visita, un ambiente che non controlli e che negli ultimi anni ha smesso di collaborare. Le perdite arrivano da quattro direzioni, e vanno tenute separate perché non si riparano allo stesso modo.
Estensioni, browser con blocco integrato, filtri di rete o di DNS aziendale. Le liste che usano contengono i domini dei pixel più diffusi: la richiesta non parte proprio, e spesso lo script non viene nemmeno scaricato. Dalla pagina non te ne accorgi: il codice che dovrebbe segnalarti il problema è esattamente quello bloccato.
Safari con ITP limita a pochi giorni la durata dei cookie scritti da JavaScript; gli altri browser hanno regole proprie, e le cambiano nel tempo. Il cookie che identifica un visitatore scade prima che quel visitatore torni a comprare. Qui non perdi l'evento: perdi il filo che lega la visita di oggi all'ordine della settimana prossima. È più subdola, perché i conteggi restano in piedi mentre l'attribuzione si accorcia da sola.
Se chi arriva rifiuta i cookie di marketing, i tag non partono. Non è un guasto da riparare: è il sistema che funziona come deve. Tienilo da parte: è il punto su cui il server-side viene raccontato peggio.
La pagina di conferma chiusa un istante prima che la richiesta parta. Il ritorno dal gateway di pagamento che salta il passaggio dove sta il tag. L'errore JavaScript di un altro script che interrompe l'esecuzione prima che tocchi al tuo. Nessuna di queste è drammatica da sola; insieme fanno un buco.
Sotto la stessa etichetta finiscono due cose diverse. La prima è spostare il punto di raccolta: invece che al dominio della piattaforma, il browser manda i dati a un endpoint tuo, di solito un sottodominio, e da lì un server li inoltra. Cambia chi fa la telefonata finale. Aiuta contro una parte dei blocchi, non contro tutti, e non c'entra niente con il consenso.
La seconda è quella che conta: generare l'evento dove il fatto accade davvero. Quando un ordine viene scritto nel tuo database, quello è un fatto. Non dipende dal browser, né da uno script, né dalla rete di chi ha comprato. La Conversions API di Meta e il Measurement Protocol di GA4 sono i due modi standard per raccontarlo da server a server. La differenza è tutta qui: smetti di chiedere al browser di testimoniare una cosa che sai già.
C'è poi un effetto di cui si parla meno e che vale quanto il recupero: la qualità. Il valore che dichiara il browser è quello che stava nel carrello un istante prima; quello che conosce il server è l'importo davvero incassato, al netto di sconti e spedizione, nella valuta giusta. Dal server puoi inviare in forma hashata i dati identificativi raccolti legittimamente in fase d'ordine, e alzare la probabilità che la conversione venga abbinata alla persona giusta. E puoi correggere: un reso, un ordine annullato, un pagamento non riuscito sono cose che il browser non saprà mai.
Nella maggior parte delle implementazioni i due canali convivono: l'evento lo manda il browser e lo manda anche il server. Ognuno copre i buchi dell'altro. Però la stessa conversione arriva due volte, e qualcuno deve capire che è la stessa.
Meta lo fa con l'event_id, un identificatore che accompagna l'evento su entrambi i canali: se nome dell'evento ed event_id coincidono, i due arrivi diventano uno solo. Regola semplice e proprio per questo fragile. L'identificatore va generato una volta sola e deve viaggiare intatto fino in fondo. L'errore più comune è generarlo due volte, uno nella pagina e uno nel backend, e ritrovarsi con due stringhe diverse per lo stesso ordine. La deduplica non scatta, e ogni conversione vale doppio.
Il guaio è che sembra un miglioramento. I numeri salgono, il ritorno sulla spesa dichiarato dalla piattaforma migliora. Poi l'algoritmo ottimizza su un segnale gonfiato e il budget lo muovi su una realtà che non esiste. Un tracking che perde dati è un problema circoscritto; uno che ne inventa è peggio, perché è credibile.
Il Measurement Protocol di GA4 funziona in un altro modo, ed è meglio saperlo prima: non esiste un campo che dica a GA4 che quell'evento potrebbe essere già arrivato. L'evento va agganciato alla sessione giusta tramite il client_id, e la coerenza la garantisci tu, decidendo evento per evento chi lo manda. Per gli acquisti, l'identificativo dell'ordine è la chiave per verificare a valle che lo stesso ordine non sia finito nei conti due volte.
È il fraintendimento più grosso ed è quello che costa di più. Il GDPR non regola il punto della rete da cui parte una richiesta: regola il trattamento dei dati personali. Se una persona ha detto no, spedire lo stesso evento dal server invece che dal suo browser non lo rende lecito: è lo stesso trattamento, fatto da un'altra macchina. Il server-side non scavalca il banner: chi te lo vende così ti sta vendendo un rischio. Il consenso va raccolto prima e propagato fino al server, che deve sapere se quell'evento può partire.
Se gli eventi sono definiti male, se il valore dell'ordine era già sbagliato, se mancano i parametri che servono, il server-side replica gli stessi errori con più affidabilità di prima. Prima si mette in ordine cosa misuri e perché; poi da dove spedirlo.
Sapere che una conversione è avvenuta non dice che cosa l'ha causata: il modello di attribuzione resta quello della piattaforma, con le sue convenzioni. E il server non sa niente più di quello che il tuo sistema ha raccolto davvero: se il grosso del traffico se ne va senza mai identificarsi, il server-side non ti regala persone, ti restituisce meglio quelle che avevi già.
La costruzione è la parte breve. Quello che resta è un sistema in più da tenere in piedi.
Le API delle piattaforme hanno versioni, e le versioni scadono. Ogni tanto un campo cambia nome o diventa obbligatorio, e se nessuno se ne accorge gli eventi smettono di arrivare in silenzio. È qui che il server-side è diverso da un pixel rotto: quando si rompe un tag qualcuno lo nota dal crollo dei dati, mentre se si inceppa l'inoltro dal server continuano ad arrivare gli eventi dal browser, e il calo sembra stagionalità.
Se ospiti un container server-side, hai un servizio che gira, costa e va monitorato. E chiunque metta mano al checkout deve ricordarsi che lì sotto c'è un'integrazione appesa. Quando lo affrontiamo come sviluppo software su misura è una voce che mettiamo a preventivo fin dall'inizio: non è una funzione che consegni e dimentichi, è infrastruttura che qualcuno deve possedere. Non a caso le integrazioni sono una delle voci che pesano su un preventivo, e questa è tra quelle che si sottovalutano più spesso.
Prima della domanda «lo faccio?» ce n'è una più utile: quanto sto perdendo davvero? È una misura che si fa con i dati che hai già in casa. Prendi gli ordini reali del gestionale o del backend dello store e confrontali con le conversioni registrate dalle piattaforme nello stesso periodo. Il divario è il tuo numero. Senza, il server-side è la risposta a una domanda che non hai fatto.
Se il divario è piccolo hai finito, il problema è altrove. Se è grande, la domanda dopo non è come recuperarlo ma da dove viene. Spesso da cause banali e più economiche da riparare: una pagina di conferma che parte degli utenti non vede mai, un evento agganciato al clic sul bottone invece che all'ordine confermato, un banner di consenso che quasi nessuno accetta. Vanno sistemate comunque, perché il server-side non le supera: le eredita.
Quando il lato browser è già in ordine e il buco resta, guarda queste quattro cose.
Se la maggior parte delle risposte è no, non è il momento. Non è una sconfitta, è un ordine di priorità.
Non dal fatto che i numeri sono saliti: è il test sbagliato, ed è il primo che fanno tutti. Il confronto resta quello di prima, eventi registrati contro ordini reali. Se gli eventi superano gli ordini non hai recuperato niente, stai contando doppio. Se si avvicinano senza superarli, funziona. Poi ci sono le diagnostiche delle piattaforme, che dicono quanti eventi arrivano da quale canale e quanti vengono deduplicati: vanno guardate con regolarità, non solo il giorno del lancio. Un'integrazione così non si collauda, si presidia.
Il tracking server-side è idraulica, non magia. Fatto bene, ti restituisce un'immagine più vicina alla realtà e dà a chi gestisce le tue campagne Google e Meta un segnale su cui vale la pena ottimizzare. Fatto male, ti restituisce un'immagine più bella della realtà, ed è il caso peggiore, perché nessuno la mette in dubbio.
Non è un acceleratore di vendite e non è un permesso per ignorare il consenso. È una condizione perché le decisioni poggino su qualcosa di vero. Se non hai mai confrontato i numeri delle piattaforme con i tuoi ordini, quello è il lavoro da fare prima: costa meno e chiarisce di più. Se l'hai fatto e il buco c'è, allora la conversazione ha senso, e la prima call di analisi è gratuita, anche solo per sentirti dire che nel tuo caso non serve.
Parliamone. Una prima call di misurazione è sempre gratuita.
Prenota una call