Cosa stiamo davvero risolvendo
Quando un cliente ci chiede “vale la pena passare al server-side?”, il punto vero non è la tecnologia: è capire quante conversioni stai perdendo oggi e perché.
Le tre cause più comuni di conversioni “fantasma” su un e-commerce o un lead-gen B2B:
- Ad-blocker browser-side: tra 20% e 35% del traffico desktop in Europa, meno su mobile.
- ITP di Safari che limita i cookie first-party a 7 giorni (a volte 24 ore).
- Negazione consenso che fa partire il tag senza id utente, perdendo l’attribuzione.
Server-side risolve bene il primo, parzialmente il secondo, non risolve il terzo. Questo è il punto che chi vende il servizio non sempre dice chiaro.
Come funziona davvero (senza disegnini)
Nel client-side classico, il browser parla direttamente con Google, Meta, TikTok eccetera. Ad-blocker e ITP intercettano lì.
Nel server-side, il browser parla con un endpoint che hai tu (su un sottodominio del cliente, tipo metrics.cliente.it). Quell’endpoint inoltra l’evento alle piattaforme passando per le loro API server.
Tre conseguenze pratiche: l’ad-blocker non riconosce il tuo endpoint custom, i cookie first-party non vengono limitati come quelli di terze parti, e tu hai pieno controllo su cosa esce dal tuo dominio verso fuori.
In pratica significa un cloud run o equivalente che gira 24/7. Costa ~5-15 €/mese per traffico medio, può salire a 40-60 € su e-commerce con eventi pesanti.
Quando recuperi le conversioni
Sui clienti dove abbiamo migrato negli ultimi 12 mesi, il recupero medio di conversioni tracciate è stato:
- E-commerce B2C medio (ordini): +18-26% sulle conversioni Ads attribuite.
- Lead-gen B2B (form): +12-19% sui lead tracciati.
- Servizi su appuntamento (call): +8-14% (qui il browser-side era già ok perché basso traffico desktop).
Questi numeri non sono “vendite vere in più”. Sono conversioni che stavano già succedendo ma che non venivano attribuite. Il valore sta nell’ottimizzazione automatica delle campagne: dare a Google/Meta dati più completi alza la qualità del bidding.
Quando NON ha senso (ancora)
Tre casi reali in cui abbiamo sconsigliato il passaggio:
- Sotto 1.500 transazioni/mese: il rumore statistico è troppo alto, il guadagno di qualità non si vede.
- Ads spend sotto 800 €/mese: il costo del server-side erode il vantaggio.
- Brand-only / ricerca su nome: se vendi solo a chi ti cerca per nome, l’attribuzione è già robusta lato browser.
Il punto è che server-side è uno strumento per chi fa già advertising serio e perde dati nelle pieghe. Non è una bacchetta magica per chi sta partendo.
Il consenso resta il vero collo di bottiglia
Una cosa che troppi vendor di server-side glissano: se l’utente non dà consenso, server-side non cambia nulla. Il tag non parte, e con GDPR + sentenza Schrems II non puoi “girarci attorno” inviando comunque l’evento alle piattaforme USA.
Quello che server-side ti dà sul fronte privacy è altro: trasparenza su cosa esce dal sito, possibilità di filtrare PII prima dell’invio (es. togliere email da URL), logging centralizzato per dimostrare compliance.
Sono cose serie, ma non sono “più conversioni”. Vanno raccontate al cliente per quello che sono: una postura di compliance migliore, non un trucco SEO/Ads.
La domanda giusta da farsi
Se stai valutando il passaggio, prova a rispondere a queste tre prima di decidere:
- Quante conversioni mensili tracci oggi e quanto spendi in advertising?
- Hai già un consent management decente? (Iubenda, Cookiebot, OneTrust)
- Hai un developer/agenzia che gestisce un endpoint cloud per te?
Se le risposte sono “tante, sì, sì” il ROI di solito si vede in 60-90 giorni. Se anche una è no, probabilmente ci sono cose con priorità più alta.
Su posizionamento e advertising lavoriamo entrambe le leve insieme: ha senso passare al server-side solo quando il resto della casa è in ordine.
