Con l’aumento delle questioni legate a dati, privacy e “First Party” nel marketing digitale, il tema del tagging “lato server” ritorna spesso sul tavolo. La domanda di fondo, dal punto di vista del pilotaggio, è: “Devo andare lì o non dovrei andare?” oppure "Devo andare adesso o più tardi?" In questo articolo, tenteremo un approccio sintetico per aiutare nel processo decisionale.
Sommario:
- 3 questioni principali
- Fiducia nei dati raccolti
- Controllo dei dati inviati a terzi
- Ottimizzazione delle prestazioni del sito
- “Lato server”, Kézako?
- Idee ricevute
- Come facciamo
- Conclusione
Definizioni utili:
- Cookie di prima parte: un cookie associato allo stesso nome di dominio del sito web visitato.
- Cookie di terze parti (o cookie di terze parti): un cookie associato a un dominio diverso dal sito web visitato (spesso un dominio di una piattaforma pubblicitaria).
- ITP (Prevenzione del tracciamento intelligente) : funzionalità di privacy introdotta da Apple su Safari nel 2017.
- TMS (Tag Management System): sistema di gestione dei tag
3 questioni principali
Innanzitutto, mettiamo sul tavolo tre questioni principali spesso sollevate nel contesto di una strategia “lato server”. Per ciascuno di questi problemi, ne affronteremo gli impatti e ciò che la tecnologia lato server può apportare.
Problema 1: fiducia nei dati (qualità dei dati)
Le decisioni importanti vengono prese in base ai risultati osservati nei report di Web Analytics. Anche le campagne pubblicitarie vengono adattate e ottimizzate in base ai dati raccolti. La affidabilità dei dati così è un problema serio.
Negli ultimi anni, diversi eventi tecnici o normativi hanno influenzato la raccolta dei dati:
- RGPD (regolamentare) : perdiamo parte dei dati.
- Bloccanti annuncio (tecnico) : perdiamo un'altra parte dei dati.
- Safari/iOS/Firefox(tecnico) : perdiamo ancora dati (con ITP, un sistema di prevenzione del tracciamento che limita notevolmente l'uso dei cookie)
- Cookie di terze parti di Chrome (tecnico): per il momento in stand-by, ma ci aspettiamo sviluppi futuri che porteranno sicuramente ad un'ulteriore perdita di dati
Esaminiamo questi diversi punti un po' più da vicino:
1 – GDPR
Dal punto di vista normativo, alcuni visitatori non danno il proprio consenso. E' normale, è fatto. E potremmo anche essere chiari fin dall'inizio, l’idea del lato server non è quella di sovrascrivere i consensi !
ℹ️ In Francia, si stima che circa il 35% degli internauti non dia il proprio consenso.
(fonte: Barometro digitale Credoc – 2022)
⚠️ Impatto: parte dei dati non vengono raccolti. I KPI volumetrici nei report di Web Analytics perdono significato (le proporzioni e gli sviluppi restano utilizzabili. Le funzionalità di targeting pubblicitario sono un po' meno precise).
2 – Blocco degli annunci
Una percentuale significativa di utenti equipaggia il proprio browser componenti aggiuntivi, chiamati blocco degli annunci (blocco annunci). Il ruolo di questi strumenti è principalmente quello di ostacolare il funzionamento dei processi di marketing/pubblicità sui siti visitati. A volte questi strumenti possono addirittura andare oltre questo obiettivo, arrivando addirittura a impedire del tutto il caricamento di Tag Manager.
Come abbiamo detto, in sostanza si tratta ovviamente di rispettare le scelte dell'utente in termini di GDPR. Per questo probabilmente il vostro sito web è già dotato di un gestore del consenso (Axeptio, Cookiebot, Didomi, ecc.).
Ma caricando un Tag Manager, eseguendo tag e raccogliendo dati nel rispetto delle normative, stai semplicemente facendo il tuo lavoro come operatore di un sito web e puoi legittimamente puntare all'obiettivo di non lasciare che i tuoi strumenti conformi siano d'intralcio.
ℹ️ In Francia, circa il 30-40% degli utenti Internet (desktop) utilizzano gli ad-blocker
⚠️ Impatto: un'ulteriore parte dei dati non viene raccolta. L’impatto del punto precedente (GDPR) è amplificato.
3 – ITP (Safari/Firefox…)
Il sistema ITP (Intelligent Tracking Prevention), lanciato nel 2017, ha lo scopo di limitare l’uso dei cookie. È presente, tra gli altri, nei browser Safari e Firefox.
In particolare, blocca i cookie di terze parti ed elimina i cookie di prima parte dopo 1 giorni.
ℹ️ In Francia, circa il 32% degli utenti Internet utilizza Safari (fonte Statista)
⚠️ Impatto: ad essere colpite sono soprattutto le capacità di targeting o i modelli di attribuzione dei sistemi pubblicitari di terzi (cookie di terzi bloccati). Sul lato Web Analytics, non sono più in grado di riconoscere un utente ricorrente in modo efficace (i cookie originali vengono eliminati entro 1-1 giorni).
4 – Bloccare i cookie di terze parti su Chrome
Stessa idea qui: dopo aver menzionato per la prima volta a posticipo al 2025 il deprezzamento dei cookie di terze parti, Google lo ha recentemente annunciato I cookie di terze parti su Chrome non verrebbero infine deprecati (22/07/24). Nonostante tutto, questo blocco dei cookie di terze parti resta un problema da affrontare. Anche se i futuri sviluppi di Chrome non consisteranno in un blocco totale, possiamo aspettarci che lasceranno un maggiore controllo agli utenti con, di conseguenza, un'alterazione del funzionamento attuale.
È soprattutto il brusio attorno a questo punto che sta generando un recente aumento di interesse per le tecnologie lato server.
ℹ️ In Francia, circa il 57% degli utenti Internet utilizza Chrome (fonte Statista)
⚠️ Impatto: Ciò amplificherà l'impatto del punto precedente (ITP) sui cookie di terze parti. Quindi soprattutto per quanto riguarda la targetizzazione delle campagne pubblicitarie e dei modelli di attribuzione (calo del ritorno sugli investimenti pubblicitari o ROAS).
In sintesi, riducendo la quantità di dati raccolti, la massa statistica viene naturalmente indebolita. La fiducia nei dati vacilla e le strategie di marketing perdono parte della loro precisione ed efficacia.
Contributi lato server sulla fiducia nei dati:
Su questo primo tema, un’implementazione lato server ridurrà l’impatto dei limiti tecnici:
- Riduci l'impatto degli ad blocker (a seconda della soluzione tecnica utilizzata).
- Riduci l'impatto delle limitazioni su Safari/Firefox (ITP).
- Riduci l'impatto del blocco di terze parti su Chrome.
⚠️ Tieni presente che esistono diversi modi per implementare lato server, garantendo più o meno efficienza. Discuteremo i nostri consigli in quest’area alla fine dell’articolo.
👍 Con il lato server, la raccolta dei dati sarà più ampia e qualitativa, il che sarà favorevole per ottimizzare le strategie delle campagne di marketing e migliorare la qualità dell'analisi del pubblico.
Problema 2: controllare i dati raccolti (governance dei dati)
Lato client, gli script di tag possono raccogliere determinati dati senza che siano completamente trasparenti e controllati. Infatti è abbastanza difficile verificare cosa viene effettivamente catturato e inviato dal tag.
Sul lato server, l'implementazione del tagging implica un processo in cui ogni dato acquisito sul lato client viene definito e inviato ai tag sul lato server.
Contributi lato server sulla governance dei dati:
Su questo secondo problema, il lato server fornisce:
- Visibilità totale dei dati veicolati dai tag
- Controllo totale dei dati veicolati dai tag (anonimizzazione/modifica dei dati personali)
- I “venditori” (Meta, Google, ecc.) accedono solo ai dati configurati sui tag nel Tag Manager.
👍 Il lato server consente di riprendere il controllo dei dati coinvolti nei processi di Web Analytics e Digital Marketing.
Problema 3: preservare le prestazioni del sito Web
In un sistema di tagging lato client, i tag vengono caricati ed eseguiti dal browser dell'utente.
Alcuni tag, presi singolarmente, sono già piuttosto pesanti (es: Facebook Pixel). Ma nel loro insieme, a volte abbiamo costi cumulativi significativi e di grande impatto per i visitatori.
© Sorriso
Contributi lato server alle prestazioni del sito web:
Per quanto riguarda il problema delle prestazioni, il lato server fornisce:
- Ottimizzazione/limitazione della quantità di elementi elaborati lato Cliente.
- Favorevole per l'esperienza utente (UX).
- Favorevole per il SEO.
👍 Il lato server promuove le prestazioni del sito Web e il SEO.
Il “lato server”, cosa?
Ma Jamy, cos'è un tag “lato server”?
Di solito un tag di tracciamento viene eseguito sul browser del cliente. Lo scambio di dati è diretto tra il browser del visitatore e la piattaforma di marketing o di analisi. Parliamo quindi di tag “lato client”.
Lato client:
- Ogni tag viene caricato/eseguito dal browser.
- Ogni tag raccoglie i propri dati (spesso gli stessi degli altri tag).
Nel caso di un tag lato server, le informazioni vengono trasmesse dal lato client ad un altro contenitore ospitato su un server nel cloud, tramite un unico tag che funge da “trasportatore”. I tag vengono quindi eseguiti con questi dati dal server alle piattaforme di marketing o di analisi.
Lato server:
- Il browser carica un solo tag di raccolta.
- Un singolo tag di raccolta prende i dati e li rende disponibili ai tag lato server.
© Sorriso
Ok, ma qual è il punto?
Grazie al fatto che i tag vengono eseguiti da un server anziché dal browser/client, otteniamo le seguenti caratteristiche:
- Un tag lato server non inserisce cookie di terze parti nei browser dei visitatori. Tuttavia, i cookie inseriti dal server diventano di prima parte.
- Un tag lato server può inviare solo i dati ricevuti dal singolo punto di ingresso dal client.
- Un tag lato server non viene eseguito sui browser dei visitatori.
Ciò conferisce quindi questi principali vantaggi:
- Migliore qualità dei dati
Limitando l'impatto dei blocchi pubblicitari o delle limitazioni legate ai cookie di terze parti, raccogliamo più dati.
- Controllo dei dati raccolti
Gestendo la canalizzazione dei dati verso i tag lato server, si riprende il controllo di ciò che viene inviato e quindi raccolto.
- Ottimizzazione dei tempi di scarico
Eseguendo i tag lato server, riduciamo il lavoro del browser. Questo va nella direzione del miglioramento dell’esperienza utente e dell’ottimizzazione SEO.
- Metodo più sostenibile
L’evoluzione delle normative e delle tecnologie tende ad aumentare l’interesse del lato server. Salendo a bordo abbastanza presto, possiamo sperare in una buona sostenibilità, al contrario di tutto ciò che ruota attorno ai cookie e al lato client
Alcune idee preconcette
-
Il lato server ti consente di aggirare i blocchi degli annunci
Secondo me questo è un po' vero e un po' falso :cQuesto non è lo scopo principale del lato server. Tuttavia è vero
Questo non è lo scopo principale del lato server. Però infatti, logicamente, inviando tag lato server, questi non verranno più ostacolati.
Tuttavia, affinché la codifica lato server funzioni, il tuo sito deve comunque utilizzare un contenitore Tag Manager lato client con tag collegati al lato server. Questi tag "ponte" potrebbero rimanere bloccati da un blocco annunci. In questo caso, non possiamo dire che il lato server stia bypassando il blocco annunci. Stessa cosa se l'Ad blocker blocca completamente il Tag Manager.
In sintesi, il lato server di per sé non è sufficiente per aggirare gli ad blocker.
Menzioneremo più avanti in questo articolo che le tecniche di implementazione avanzate consentono di limitare l'impatto degli ad blocker.
-
Il lato server ti consente di non caricare nulla sul lato client
Anche qui è da qualificare e pper lo stesso motivo: Infatti, la maggior parte delle volte quando parliamo di tagging lato server, in realtà parliamo di “Client to Server to Server”. Da notare che esiste un tipo di implementazione avanzata che consente Server to Server (con il Measurement Protocol, riservato agli esperti).
Per far funzionare la codifica "classica" lato server, il tuo sito deve comunque continuare a utilizzare un contenitore Tag Manager lato client con tag che costituiscono il "ponte" verso il lato server. Quindi, in tutti i casi, ci sono ancora processi sul lato browser/client.
Ma in effetti, alcuni tag verranno trasferiti sul lato server.
In sintesi, il lato server (classico) può ridurre i carichi lato client, ma non eliminarli completamente.
-
Il lato server è buono, ma è costoso
Quindi, in tema di costi, tutto è relativo (di nuovo!?): se guardiamo solo ai costi diretti delle soluzioni e al tempo degli esperti necessari per l'implementazione, la situazione può diventare fredda (altrimenti non facciamo nulla e non spendere nulla in più).
Ma ovviamente mi propongo qui di ampliare un po' la riflessione: ho effettuato un rapido calcolo su un angolo di una tovaglia (ok... ho usato un foglio di calcolo) che vorrei condividere con voi:
Partiamo dall'ipotesi di un e-retailer che realizza campagne SEA utilizzando il retargeting. Abbiamo a disposizione alcuni KPI:
- Spende 5€/mese in SEA.
- Il suo CPC medio è di € 1,5/clic.
- Il suo paniere medio è di 140 euro con un margine lordo del 40%.
- Osserva un tasso di conversione medio da SEA del 3%.
Tutto sta andando bene nel migliore dei mondi possibili e tutto ronza con circa 100 conversioni al mese e un margine lordo totale generato di € 7 / mese. L'impatto diretto della SEA è positivo e ammonta a + € 000 / mese (margine lordo – spesa CPC). E poi, un “bel giorno”, abbiamo ridotto le sue capacità di targeting a causa di un aggiornamento di Chrome che bloccava i cookie di terze parti… Da lì in poi, essendo le sue campagne un po' meno efficaci, ha visto il suo tasso di conversione scendere al 2%. Perde quindi 2 € di margine al mese, solo per un tasso di conversione del -1%…
Ti lascerò pianificare in anticipo e immaginare altri scenari. Ma in sintesi, mettendo in prospettiva i costi lato server, è generalmente abbastanza rassicurante. Ciò che potrebbe essere costoso è non fare nulla.
Come facciamo ?
Quindi la questione è piuttosto ampia. Dato che ho già consumato molto del vostro prezioso tempo (e esperti molto più preparati di me sull'argomento offrono già ottime risorse), cercherò di riassumere il mio modo di vedere le cose in maniera concisa e semplificata:
-
Metodo 1: “vecchia scuola”
Il cliente ci apre un'istanza del server nel cloud (spesso su Google Cloud Platform perché offerto direttamente da Google Tag Manager), noi mettiamo tutto a posto per trasportare i dati dal lato client al lato server... Facciamo dopo i test, vediamo i tag lato server che se ne vanno... va tutto bene. Stiamo lavorando lato server!
Ma... senza rendercene conto immediatamente, abbiamo tag "bridge" lato client bloccati da adblocker... abbiamo gestori di tag contenitore lato client bloccati da adblocker... potremmo avere un problema sull'istanza di Google Cloud per un problema di fatturazione che il cliente non ha gestito... potremmo avere problemi con dati raccolti in modo inadeguato... ecc.
Ci troviamo rapidamente di fronte a un forte rischio legato alla mancanza di monitoraggio e all'effetto "scatola nera". In breve, ci stiamo arrivando, ma ehi, è pieno di piccoli problemi, spesso piuttosto subdoli e di impatto per le prestazioni della tua operazione "lato server".
-
Metodo 2: affidarsi a una soluzione/partner esperto
E poi, un giorno, scopriamo su un forum di dati/marketing o in un articolo di blog che un'azienda francese offre una piattaforma e servizi che rispondono a questi problemi.
Non siamo più soli, i veri esperti sono con te. Gli strumenti semplificano notevolmente l'implementazione. La piattaforma si evolve regolarmente.
In breve, il tutto supera di gran lunga il metodo “vecchia scuola”.
Questo partner tecnologico è Addingwell. E no, non ho alcuna azione con loro (peccato). Esiste davvero un divario (il che, tra l'altro, non è illogico). Ci accorgiamo subito che conoscono molto bene la materia e che tutto ciò che mettono in atto risponde direttamente a questioni concrete. Guadagniamo enormemente in termini di tempo di installazione, possibilità e affidabilità.
Conclusione
Dovrei andarci o no?
- Andare avanti! Dati i problemi di dati e prestazioni già esistenti e quelli futuri, è necessario posizionarsi su questa tecnologia (a meno che non si effettui alcuna acquisizione/pubblicità di traffico).
Dovrei andare adesso o più tardi?
- Lo vedete, ma non aspettate troppo a lungo: quando arriveranno le prossime modifiche a Chrome relative ai cookie di terze parti (2025?), c'è il rischio di un ingorgo delle richieste di implementazione lato server.
E come lo faccio?
- Chiami UX-Republic (in modo casuale).
- Studieremo la necessità ed eventualmente suggeriremo al nostro partner Addingwell di unirsi a noi per elaborare un progetto adatto a te.
In ogni caso si sconsiglia di recarsi senza essere accompagnati. La complessità dell'impostazione del tagging lato server è un gradino sopra l'implementazione lato client (che può già essere piuttosto complicata).
Laurent Neuville, Consulente senior di analisi web presso Smile