Client-side vs server-side, senza gergo

La campagna sembra a posto. Budget stabile, creatività fresca, offerte invariate. Ma le conversioni in Ads Manager continuano a scendere, e nessuno sa dirti perché. Qualcuno ti dice di passare al server-side. Nessuno ti dice cosa significa.

Eccolo, in parole semplici e con esempi.

Pensalo come spedire una lettera

Ogni volta che qualcuno compra sul tuo sito, un evento deve viaggiare dal suo browser fino a Meta. Come viaggia è tutta la storia.

Il client-side è come dare la lettera a un corriere che esce dalla porta principale. A volte passa. Spesso lo fermano: un ad blocker, Safari, un'impostazione privacy dell'iPhone, una pagina lenta. La lettera non arriva, e tu non lo scopri.

Il server-side è come spedirla dal tuo ufficio postale. L'evento passa prima da un server che controlli tu, e il tuo server lo inoltra. Meno controlli, e decidi tu cosa mettere nella busta.

Cosa vuol dire nel tuo account

Mettiamo che un cliente e-commerce spenda 10k al mese. Una buona fetta dei suoi acquirenti usa un ad blocker o è su un iPhone che blocca il tracciamento. Quelle persone comprano lo stesso. Ma una parte di quelle vendite non arriva mai a Meta.

Ecco la parte che fa male: Meta non sa che mancano dei dati. Ottimizza verso gli acquirenti che vede e ignora quelli che non vede. Quindi non stai solo sotto-riportando, stai allenando l'algoritmo su metà del quadro. Lo abbiamo spiegato nel dettaglio per gli ad blocker.

Client-side, in una riga

Uno script (il Pixel) gira nel browser e invia gli eventi da lì. Facile da installare, ed esposto a tutto ciò che blocca i browser: ad blocker, prevenzione del tracciamento di Safari, opt-out di iOS, un errore JavaScript nella pagina.

Server-side, in una riga

Gli eventi vanno a un dominio che controlli (come server.tuocliente.it), il tuo server li ripulisce e li manda a Meta tramite la Conversions API, fuori dal browser dove vivono i blocker. (Google spiega la stessa distinzione qui.)

Il bonus: il tuo server può inviare anche cose che il browser non vede mai, come una vendita chiusa al telefono, un rinnovo di abbonamento, o un lead che diventa cliente settimane dopo nel CRM.

La parte onesta (leggila)

Il server-side non è un interruttore magico. Riduce i dati persi, non li recupera tutti, e non ti rende compliant da solo. Il divario tipico del solo tracciamento da browser sta tra il 15 e il 30 percento, ma dipende dal tuo traffico. Chi ti promette un numero esatto sta tirando a indovinare.

Non ne scegli uno, li usi entrambi

Il setup migliore è averli tutti e due: tieni il Pixel per ciò che il browser vede, aggiungi il server-side per ciò che gli sfugge, e deduplica così una vendita non viene mai contata due volte.

Sentirai parlare di EMQ (Event Match Quality). Versione semplice: è un punteggio di quanto bene Meta riesce ad abbinare il tuo evento a una persona reale. Dati più puliti lo alzano. È un indicatore di qualità, non un pulsante che aumenta i risultati.

Dove entra Roasync

Farlo da solo significa un dominio da configurare, un server da gestire, eventi da mappare e la deduplica da fare bene. Per la maggior parte dei team è un progetto da sviluppatori, non un pomeriggio.

Roasync è la scorciatoia. Colleghi un cliente, gli eventi passano da un dominio first-party, e noi li mandiamo a Meta server to server con la deduplica gestita. Il punto è un segnale più pulito e completo: quando Meta vede le conversioni davvero avvenute, ha qualcosa di reale su cui ottimizzare. (Meta indica che affiancare la Conversions API al Pixel porta più eventi abbinati e un costo per risultato più basso in media, quando l'implementazione è fatta bene. È il meccanismo, non una promessa sul tuo account.) Nei settori regolati come la sanità, la stessa logica diventa solo più stringente.

In sintesi

Client-side: parla il browser per te, e lo interrompono di continuo. Server-side: parla il tuo server, e controlli tu il messaggio. Per la maggior parte dei team la risposta è entrambi, fatti bene. Vuoi la metà server-side senza costruirla? È ciò per cui esiste Roasync.