Server-side tracking su Stape: basta il container o serve un dominio personalizzato?

Hai creato il container server di Google Tag Manager, Stape mostra lo stato attivo e l’anteprima riceve qualche evento. Il tracking server-side è pronto? Non ancora necessariamente. Il container è il motore; bisogna anche decidere da quale indirizzo il browser gli invierà le richieste.

Puoi usare il dominio predefinito fornito da Stape, un sottodominio come dati.azienda.it oppure un percorso sullo stesso hostname del sito, per esempio www.azienda.it/metrics. Le tre soluzioni possono trasportare eventi, ma non offrono lo stesso contesto, la stessa complessità né lo stesso controllo operativo.

Che cos’è il tagging server URL

Il tagging server URL è l’endpoint pubblico che riceve dal sito gli eventi destinati al container server. Il browser non “parla” con l’interfaccia di Stape: invia richieste HTTP a quell’indirizzo; i client del container le interpretano e i tag server decidono quali dati inoltrare alle destinazioni configurate.

Google distingue tre configurazioni. Il dominio predefinito del provider funziona in un contesto di terza parte. Un sottodominio del sito e il same-origin permettono invece al tagging server di operare in un contesto proprietario; nella documentazione Google entrambi possono accedere ai vantaggi dei cookie impostati dal server, mentre il same-origin è indicato come pratica preferibile. Fonte: Google, configurazione del dominio personalizzato.

Tradotto: il dominio predefinito può essere utile per configurazione e test, ma “il container risponde” non equivale a “l’architettura di produzione è finita”. Significa soltanto che almeno qualcosa respira.

Dominio Stape, sottodominio o same-origin?

• Dominio predefinito Stape: è già disponibile e riduce i passaggi iniziali. La richiesta, però, non usa il dominio del sito.
• Sottodominio proprietario: un indirizzo come sgtm.azienda.it condivide il dominio registrabile con il sito. In genere richiede una configurazione DNS e l’associazione dell’hostname in Stape.
• Same-origin: il traffico passa dallo stesso hostname del sito, spesso tramite un percorso dedicato. Richiede che CDN, proxy o load balancer inoltrino correttamente quelle richieste al tagging server.

Stape documenta le stesse opzioni e, per il sottodominio, descrive l’aggiunta del dominio nel pannello e la configurazione del record DNS indicato. Dopo la verifica, l’URL deve essere riportato anche nelle impostazioni del container e nella raccolta web. Fonte: Stape, aggiungere un dominio personalizzato al container server.

Non sceglierei il same-origin solo perché è la soluzione più avanzata sulla carta. Se l’infrastruttura non dispone già di un livello di routing gestito e verificabile, un sottodominio proprietario può essere più semplice da mantenere. La decisione va presa insieme a chi gestisce DNS, hosting, CDN e sicurezza.

Che cosa migliora davvero il dominio personalizzato

Il vantaggio principale è rendere proprietario il contesto dell’endpoint e permettere la corretta gestione dei cookie server-side prevista dall’implementazione. Consente inoltre di controllare un indirizzo coerente con il sito, invece di lasciare il flusso legato al nome tecnico del fornitore.

Non è, però, una macchina del tempo. Non recupera eventi che il sito non ha mai raccolto, non corregge parametri sbagliati, non deduplica da solo browser e server e non rende affidabile un CRM compilato male. Per capire questi limiti puoi leggere che cosa può e non può recuperare il server-side tracking.

Neppure il consenso scompare. Google descrive un flusso in cui il banner raccoglie la scelta nel browser, il Google tag aggiunge i parametri di consenso alla richiesta e il container server li elabora. Cambiare endpoint non cambia la volontà espressa dall’utente. Fonte: Google, Consent Mode con Tag Manager server-side. Ho approfondito la distinzione tra implementazione Basic e Advanced nell’articolo su Consent Mode v2 dopo il rifiuto dei cookie.

Un esempio ipotetico

Esempio ipotetico, non riferito a un cliente: il sito www.azienda.it usa inizialmente l’URL assegnato da Stape per verificare che gli eventi GA4 arrivino al container. Prima della pubblicazione, l’azienda configura dati.azienda.it, completa la verifica DNS e lo imposta come URL del tagging server.

Il Google tag sul sito viene poi configurato per inviare le richieste al nuovo endpoint. In anteprima si controllano almeno una visualizzazione, un invio modulo e le diverse scelte del banner. Solo dopo si verifica che i tag server abbiano ricevuto i parametri attesi e che le destinazioni abbiano accettato gli eventi.

Se il sito usa anche shop.azienda.it, landing page su un altro dominio o moduli ospitati da terzi, non darei per scontato che il nuovo endpoint risolva tutto. Origini, cookie, redirect, identificativi e consenso devono essere mappati per ciascun percorso.

La checklist prima di considerarlo pronto

• Il dominio o percorso risponde in HTTPS senza redirect imprevisti.
• DNS, CDN e proxy inoltrano soltanto le route previste.
• Il Google tag web invia davvero le richieste al nuovo endpoint.
• L’anteprima del container server riceve gli eventi e il client corretto li acquisisce.
• I tag rispettano gli stati di consenso anche prima della scelta, dopo il rifiuto e dopo l’accettazione.
• Gli eventi browser e server condividono gli identificativi necessari alla deduplicazione prevista.
• Date, valori e ID arrivano al CRM senza essere sovrascritti o ricostruiti a memoria.
• Esiste un controllo periodico su errori, risposte e modifiche all’infrastruttura.

Google ricorda inoltre che il server container va prima creato e il tagging server va effettivamente distribuito: il dominio è un livello della configurazione, non il servizio stesso. Fonte: Google, panoramica del server-side tagging.

La risposta breve è quindi: per fare una prova può bastare l’URL predefinito; per una configurazione di produzione valuterei un endpoint sul dominio dell’azienda, scegliendo tra sottodominio e same-origin in base all’infrastruttura. Poi testerei l’intero percorso fino al CRM e al segnale restituito alle piattaforme, come descritto nel test completo prima di ottimizzare le campagne.

Fonti ufficiali consultate il 25 ottobre 2026. L’esempio è ipotetico. Dominio personalizzato e server-side tracking non eliminano gli obblighi di consenso e non garantiscono risultati pubblicitari.