Tracciamento lato server

Cosa cambia effettivamente: dove l'evento viene assemblato e inviato

Con un pixel del browser, uno script in esecuzione sul dispositivo dell'acquirente assembla l'evento. Legge la pagina per il valore e il contenuto dell'ordine, legge i propri cookie per gli identificatori di clic e browser e invia il payload al dominio della piattaforma dal dispositivo. Tutto ciò che riguarda questa catena è fuori dal tuo controllo: lo script deve caricarsi, essere eseguito e completare la sua richiesta prima che l'acquirente navighi via, su un dispositivo che potrebbe eseguire un ad blocker e un browser che limita la durata dei cookie.

Con la consegna lato server, il tuo server costruisce l'evento dai record che già possiede — l'ordine, il cliente, gli articoli — e lo invia all'endpoint delle conversioni della piattaforma come una chiamata server-to-server autenticata con un token di accesso. Il browser dell'acquirente non è coinvolto al momento dell'invio. L'evento si attiva perché un ordine è stato scritto nel tuo database, che è il segnale più affidabile nel settore.

Anche gli identificatori cambiano forma. Invece di affidarsi a un cookie che il browser potrebbe aver fatto scadere, il server invia chiavi di corrispondenza hash — indirizzo email normalizzato, numero di telefono, nome, codice postale — insieme a qualsiasi identificatore di clic catturato quando l'acquirente è atterrato e memorizzato con l'ordine, più l'indirizzo IP e l'user agent. La qualità della corrispondenza dipende quindi da ciò che hai raccolto al checkout piuttosto che da ciò che il browser ha conservato.

Cosa risolve e cosa no

Risolve la consegna. Gli eventi di acquisto che erano andati persi a causa di uno script bloccato, una richiesta fallita o un acquirente che chiudeva la scheda al reindirizzamento del pagamento ora arrivano, e arrivano con chiavi di corrispondenza estratte dal record dell'ordine anziché da ciò che è sopravvissuto nel browser. Sblocca anche una classe di eventi che il browser non può mai vedere affatto: rimborsi, rinnovi di abbonamento, chargeback, cancellazioni e ordini offline o telefonici, tutti eventi che avvengono molto tempo dopo la fine della sessione e che modificano materialmente ciò verso cui la piattaforma dovrebbe ottimizzare.

Non risolve il consenso. Questo è il malinteso più comune e il più costoso. L'obbligo si lega al trattamento dei dati personali, non al cavo su cui viaggiano. L'invio di un evento su un acquirente che ha negato il consenso è lo stesso trattamento con un percorso più lungo, e la decisione di consenso deve ora essere trasferita dal browser al tuo record d'ordine in modo che il server sappia se è autorizzato a inviare del tutto — un lavoro che il pixel faceva implicitamente.

Non crea identità che non hai mai raccolto. Un checkout come ospite senza email e senza identificatore di clic memorizzato non viene abbinato, sia che l'evento provenga da un browser o da un server. Inoltre, non sostituisce i segnali comportamentali sulla pagina: se desideri la profondità di scorrimento o le interazioni di aggiunta al carrello lato server, il browser deve comunque segnalarteli per primo.

E non migliora le prestazioni, solo la reportistica. Attivandolo, le conversioni riportate aumentano e il costo per acquisizione riportato diminuisce immediatamente, perché gli eventi che stavano sempre accadendo vengono ora contati. Questa è un'interruzione nella serie temporale, non un risultato. Segna la data sul grafico e non permettere a nessuno di confrontare il mese successivo con il mese precedente come se le campagne fossero cambiate.

Deduplicazione: il contratto dell'ID evento

Una volta che entrambi i percorsi sono attivi, ogni conversione che il browser ha segnalato con successo viene segnalata anche dal server. La piattaforma conterà entrambi a meno che tu non le dica che sono lo stesso evento, e il modo per dirglielo è un identificatore di evento condiviso: entrambe le parti inviano lo stesso nome evento e lo stesso ID, la piattaforma conserva quello che arriva per primo e scarta l'altro entro la sua finestra di deduplicazione.

Valuta il rischio con un esempio. Supponiamo 1.000 acquisti reali in un mese e che il 30% degli eventi del browser vada perso — il browser ne segnala 700, il server ne segnala tutti 1.000. Senza deduplicazione la piattaforma registra 1.700 conversioni contro 1.000 reali, una sovrastima del 70%, e il costo per acquisizione riportato scende a circa il 59% della verità. L'ottimizzatore impara quindi da un segnale in cui alcuni ordini contano due volte e altri una volta, il che è peggio di entrambi i percorsi da soli.

• Deriva l'ID da qualcosa che entrambe le parti già conoscono — l'ID dell'ordine è la scelta ovvia. Generare un ID casuale indipendentemente su ciascun lato garantisce che non corrisponderanno mai.
• Mantieni l'ID stabile tra i tentativi. Un tentativo che rigenera l'identificatore trasforma la tua gestione degli errori in una macchina per il doppio conteggio.
• Fai corrispondere esattamente il nome dell'evento, inclusi maiuscole/minuscole e tipo. Le piattaforme deduplicano sulla coppia, quindi un evento del browser e un evento del server che differiscono solo nel nome verranno entrambi mantenuti.
• Invia anche il clic del browser e gli identificatori del browser con l'evento del server. Sono ciò che consente alla piattaforma di riconoscere i due report come dello stesso utente, non solo dello stesso ordine.
• Rispetta la finestra di deduplicazione. Un evento consegnato giorni dopo — un webhook ritardato, un backfill — è al di fuori di essa e verrà contato di nuovo.
• Testa con ordini reali prima di fidarti dei numeri e riconcilia il conteggio delle conversioni riportato dalla piattaforma con il tuo conteggio degli ordini per lo stesso periodo. Dovrebbero essere vicini; un divario sistematico in una delle due direzioni è un errore di cablaggio.

Il costo operativo per cui nessuno fa un budget

Un pixel è un tag che qualcuno incolla una volta. La consegna lato server è un servizio che ora possiedi, con un access token, uno schema, una politica di riprovo e una modalità di errore, e ognuno di questi si rompe silenziosamente. Un token scaduto, una versione dell'API della piattaforma che ha smesso di accettare il payload che invii, un deploy che ha eliminato la cattura dell'identificatore di clic sulla landing page, un bug di hashing in cui gli indirizzi email non sono stati convertiti in minuscolo e troncati prima dell'hashing — nessuno di questi genera un errore che il team di marketing vedrà. Si presentano come un graduale declino nella qualità della corrispondenza o un improvviso calo delle conversioni che assomiglia esattamente a una brutta settimana di pubblicità.

Quindi il monitoraggio non è opzionale ed è semplice: confronta gli eventi server inviati con gli ordini creati, ogni giorno, e avvisa in caso di divergenza. Controlla la diagnostica degli eventi della piattaforma o il punteggio di qualità della corrispondenza, perché un tasso di corrispondenza in calo è solitamente un problema di dati piuttosto che di pubblico. Registra la risposta a ogni invio invece di "sparare e dimenticare", poiché un payload rifiutato è altrimenti indistinguibile da uno riuscito.

Prevedi un budget anche per l'infrastruttura del consenso. La decisione deve essere catturata nel browser, persistita con l'ordine e letta dal server prima che invii — tre componenti che devono tutti concordare, in un sistema in cui il fallimento è silenzioso in una direzione e un problema di conformità nell'altra.

Il riassunto onesto è che il tracciamento lato server scambia una categoria di inaffidabilità che non puoi risolvere con una categoria di manutenzione che puoi. Questo è solitamente lo scambio giusto, e smette di essere lo scambio giusto se nessuno si occuperà della pipeline dopo il trimestre in cui è stata costruita.