Come configurare un Dominio personalizzato GTM server-side

Hai creato il container server, risponde sul suo URL di default e ti stai chiedendo se puoi già iniziare a mandargli eventi? Puoi, ma stai buttando via il motivo principale per cui hai fatto tutto questo: finché il container non risponde su un sottodominio del tuo sito, i cookie restano di terze parti e il vantaggio sul dato si riduce quasi a zero.

Questa guida segue l’ordine reale delle operazioni: prima decidi il nome del sottodominio, poi raccogli i prerequisiti, poi configuri DNS e certificato, poi sposti il lato client, infine verifichi. In fondo trovi la diagnosi degli errori che bloccano davvero le persone e il criterio per capire se puoi procedere da solo.

Perché l’URL di default non ti basta

Quando crei un container server, l’endpoint che ricevi appartiene a un dominio che non è il tuo: un sottodominio di run.app, di appspot.com o del dominio condiviso del provider di hosting. Dal punto di vista del browser è un dominio di terze parti rispetto al sito che l’utente sta visitando.

Da qui nascono due conseguenze concrete.

La prima riguarda i cookie. Il vantaggio del server-side sta nel fatto che il container può impostare il cookie tramite header Set-Cookie nella risposta HTTP, invece che via JavaScript. Ma quell’header vale solo per il dominio che risponde. Se il dominio che risponde è xyz.run.app, il cookie FPID finisce lì: è un cookie di terze parti, con tutte le restrizioni che i browser applicano — in Safari le limitazioni di Intelligent Tracking Prevention sono documentate da WebKit e rendono quei cookie sostanzialmente inutili per l’attribuzione a medio termine.

La seconda riguarda il blocco delle richieste. Un endpoint su un dominio noto e condiviso da migliaia di installazioni finisce nelle filter list pubbliche. La richiesta parte dal browser, viene intercettata, l’evento non arriva mai al server.

Cosa il dominio personalizzato non fa

Qui serve onestà, perché in giro si legge il contrario. Un sottodominio first-party:

• non ti esonera dal consenso: il GDPR si applica alla finalità del trattamento, non al dominio da cui parte la richiesta;
• non rende i dati anonimi: l’identificativo utente c’è comunque;
• non sostituisce il Consent Mode: continui a dover gestire gli stati di consenso e a propagarli al container.

Il dominio personalizzato risolve un problema tecnico di durata e recapito del dato. Non è uno scudo legale. Se qualcuno te lo vende come tale, cambia interlocutore.

La regola che decide tutto: same-site, non "un dominio qualsiasi"

È il punto che quasi nessuna guida spiega, ed è quello che fa fallire le configurazioni in silenzio: tutto sembra funzionare, ma il beneficio sui cookie non c’è.

Il browser ragiona su tre livelli:

• same-origin: stesso schema, stesso host, stessa porta. https://www.miosito.it e https://www.miosito.it sono same-origin.
• same-site: stesso dominio registrabile. https://www.miosito.it e https://sgtm.miosito.it sono same-site, anche se non sono same-origin.
• cross-site: tutto il resto.

Il cookie first-party vive sul concetto di same-site. Quindi:

Sito	Endpoint container	Relazione	Cookie utile?
www.miosito.it	sgtm.miosito.it	same-site	sì
www.miosito.it	sgtm-miosito.it	cross-site	no
www.miosito.it	tracking.agenzia.it	cross-site	no
www.miosito.it	xyz.run.app	cross-site	no

Il secondo caso è l’errore più frequente: un dominio comprato apposta, con il nome del cliente dentro, che sembra "suo" ma per il browser è un dominio diverso. Soldi e tempo spesi per niente.

Il ruolo della Public Suffix List

"Dominio registrabile" non significa "le ultime due etichette". Il browser consulta la Public Suffix List, un elenco di suffissi sotto i quali gli utenti possono registrare nomi: .co.uk, .com.br, ma anche domini di servizi di hosting condiviso.

Conseguenza pratica: se il tuo sito è su miosito.co.uk, il dominio registrabile è miosito.co.uk e sgtm.miosito.co.uk è same-site. Ma se il sito gira su un sottodominio di una piattaforma inclusa nella lista, ogni sottodominio è trattato come sito a sé e non ottieni nulla. Verifica prima, non dopo.

Come scegliere il nome

Due criteri, in questo ordine.

Neutralità. Evita tag, track, tracking, analytics, gtm, metrics, pixel. Sono stringhe che compaiono nelle regole generiche delle filter list e che rendono il tuo endpoint individuabile con una ricerca testuale. Usa nomi funzionali e noiosi: s.miosito.it, data.miosito.it, api.miosito.it, edge.miosito.it.

Stabilità. Quel sottodominio finirà hardcoded nel tag di configurazione, nei consent manager, forse in una CSP. Cambiarlo dopo costa. Scegli un nome che resista a un rebranding della sezione marketing.

Se lavori su piattaforme chiuse (Shopify, Wix, alcuni SaaS B2B), verifica subito due cose: se puoi creare record DNS sul dominio del negozio e se puoi modificare il tag di configurazione lato client. Su molte piattaforme il DNS è gestibile ma l’iniezione dello script è limitata ad app ufficiali: lì il sottodominio si crea, ma l’endpoint personalizzato va impostato dove la piattaforma te lo consente.

Prerequisiti: cosa avere in mano prima di toccare il DNS

Non aprire il pannello DNS finché non hai queste sei informazioni scritte da qualche parte.

1. Il dominio esatto del sito in produzione, con e senza www. Serve a stabilire il dominio registrabile.
2. Chi è autoritativo sul DNS. Non il registrar: i nameserver effettivi. Capita spesso che il dominio sia comprato da un registrar ma delegato a Cloudflare, a un hosting o al reparto IT. Controlla con dig NS miosito.it o nslookup -type=NS miosito.it.
3. Presenza di proxy o CDN davanti al dominio. Cambia la configurazione e i controlli successivi.
4. TTL dei record esistenti. Se il TTL è a 86400, una modifica sbagliata ti tiene fermo un giorno.
5. Eventuale record CAA. Se esiste e autorizza solo una CA, l’emissione del certificato fallirà senza dirti perché.
6. Policy IT del cliente. In aziende strutturate una modifica DNS passa da un ticket, con tempi di approvazione che superano di molto quelli tecnici.

Serve anche un container server già creato e funzionante sul suo URL di default, e serve sapere chi emette il certificato TLS: Google in modalità gestita, il provider di hosting, o tu con Let’s Encrypt.

Sui tempi realistici: la propagazione DNS dipende dal TTL precedente, non da una media generica. L’emissione del certificato gestito richiede in genere qualche decina di minuti dopo che il record risolve correttamente, ma può arrivare a ore. Pianifica la finestra di lavoro, non il quarto d’ora prima di una riunione.

Configurazione su Google Cloud Run e App Engine

Se gestisci l’infrastruttura direttamente su Google Cloud, il percorso è questo.

Verifica della proprietà del dominio. Prima della mappatura, Google chiede di dimostrare che il dominio è tuo tramite Search Console. Spesso chiede il dominio radice anche se stai mappando un sottodominio: verifica miosito.it, non solo sgtm.miosito.it. La verifica a livello di dominio (record TXT) è quella che ti evita di ripetere l’operazione per ogni sottodominio futuro.

Mappatura e record. Creata la mappatura del dominio sul servizio Cloud Run, la console ti indica i record da inserire. Per un sottodominio è un CNAME verso ghs.googlehosted.com. Per un dominio radice servono record A e AAAA con gli IP indicati: un CNAME sulla radice non è ammesso dallo standard DNS, e questo è uno dei motivi per cui il sottodominio è la strada giusta.

Load balancer: quando serve davvero. La mappatura diretta basta nella maggior parte dei casi: un servizio, una regione, nessun WAF. Il load balancer con IP statico diventa necessario se distribuisci il container su più regioni, se metti Cloud Armor davanti, se hai più servizi dietro lo stesso hostname. Ha un costo orario fisso più il traffico, quindi è una voce che va messa a budget prima: se vuoi un confronto strutturato su quanto pesano queste scelte sul conto mensile, trovi i numeri nell’analisi su quanto costa un container server side e nel confronto tra gestione diretta su Cloud Run e hosting gestito.

Stato del certificato. La mappatura mostra uno stato. PROVISIONING significa che Google sta emettendo il certificato: aspetta. FAILED_NOT_VISIBLE significa che Google non vede il record DNS atteso: o non l’hai creato, o è sbagliato, o non è ancora propagato, o un proxy sta rispondendo al posto tuo. Non è un errore del container: è un errore DNS.

Verifica finale. Una richiesta HTTPS a https://sgtm.miosito.it/healthz deve restituire una risposta positiva dal container. Se ottieni la pagina di default di Cloud Run, la mappatura punta al servizio sbagliato.

Configurazione su hosting gestito, Cloudflare e server proprio

Provider di hosting gestito

Il flusso è compresso: inserisci il dominio nel pannello, il provider ti restituisce un CNAME o un record A, lo crei sul tuo DNS, attendi la validazione. Il certificato è emesso e rinnovato dal provider. È il percorso con meno punti di rottura, ed è il motivo per cui è la scelta sensata quando non hai un sistemista a disposizione — ne parlo più in dettaglio nella panoramica sull’hosting del container server-side.

Cloudflare davanti al container

Qui si concentrano gli errori. Tre regole.

Proxy sì o no. Con la nuvoletta arancione attiva, Cloudflare risponde al posto dell’origine con i propri IP. Funziona, ma introduce un hop in più e, soprattutto, impedisce a Google di vedere il record atteso durante l’emissione del certificato gestito. Se stai mappando su Cloud Run, metti il record in DNS only finché il certificato non è emesso. Poi, se vuoi, riattiva il proxy.

Modalità SSL: Full (strict), sempre. Con la modalità Flexible, Cloudflare parla in HTTP con l’origine mentre l’origine si aspetta HTTPS: il risultato è un loop di redirect o un errore 525. È la causa più comune di container "che non rispondono" quando in realtà rispondono benissimo.

Cache: esclusa. Il container server non va messo in cache. Se hai regole aggressive sul dominio, crea un’eccezione esplicita sull’hostname del container. Una risposta di /g/collect servita dalla cache significa eventi persi e cookie sbagliati assegnati a utenti diversi.

Self-hosted su Docker o Compute Engine

Se gestisci tu il server, il reverse proxy Nginx davanti al container è lo schema standard. Tre dettagli che fanno la differenza:

• Let’s Encrypt con rinnovo automatico attivo e monitorato. Un certificato scaduto non degrada il tracciamento: lo azzera.
• Header X-Forwarded-For e X-Forwarded-Proto propagati. Senza il primo, il container vede l’IP del proxy e la geolocalizzazione di ogni utente diventa quella del tuo datacenter. È un errore che non genera messaggi: te ne accorgi guardando i report geografici in GA4 e trovando tutto concentrato in una città.
• Timeout e dimensione del body adeguati: alcuni payload di eventi e-commerce sono più grandi di quanto ti aspetti.

Dopo il DNS: spostare il lato client senza perdere dati

Il dominio risponde. Ora l’endpoint va comunicato al browser.

Dove si cambia. Nel tag Google (o nella configurazione GA4) imposti il campo server_container_url con https://sgtm.miosito.it. Per i tag Google Ads che instradi al container, il parametro è transport_url. Se usi un container web su GTM, lo imposti nelle impostazioni di configurazione in un unico punto, non tag per tag.

Caricare anche gtm.js dal tuo dominio. Il container server espone il path /gtm.js?id=GTM-XXXX: puoi servire lo script del container web dal tuo sottodominio invece che da googletagmanager.com. È il passaggio che toglie dal percorso un dominio presente in tutte le filter list. Fallo dopo aver verificato che il resto funziona, non insieme.

Path personalizzato. Puoi sostituire i path standard con percorsi tuoi. Il beneficio è reale contro i blocchi basati su pattern di URL. Il rischio è altrettanto reale: ogni aggiornamento dei template dei tag può ripristinare i path di default e tu non ricevi nessuna notifica. La mia posizione: fallo solo se hai un monitoraggio attivo sul volume di eventi che ti avvisa entro un’ora se crolla. Senza quel monitoraggio, guadagni qualche punto di raccolta e rischi di perdere giorni interi di dati senza accorgertene.

Switch senza buchi nei dati

Non spegnere il vecchio endpoint il giorno in cui accendi il nuovo.

1. Attiva il nuovo endpoint su una property GA4 di test o con un parametro che ti permetta di distinguere le due fonti.
2. Tieni il doppio invio per almeno tre giorni pieni, includendo un weekend se il tuo traffico ha stagionalità settimanale.
3. Confronta i conteggi evento per evento. page_view, session_start, purchase: se lo scarto è nell’ordine dell’uno-due per cento sei a posto; se mancano intere categorie di eventi, hai un problema di configurazione, non di dominio.
4. Controlla DebugView per verificare che source/medium e i parametri gclid arrivino integri. Un’attribuzione che collassa su "direct" è il sintomo tipico di un referral mal gestito.
5. Tieni la finestra di rollback: il vecchio valore di server_container_url scritto da qualche parte e un deploy pronto.

Verificare che sia davvero first-party: cinque controlli

Dieci minuti, browser aperto.

1. Network. Filtra per collect. La richiesta deve partire verso sgtm.miosito.it e tornare con 200 o 204. Se vedi ancora google-analytics.com, il campo non è stato applicato o c’è un tag duplicato.

2. Application > Cookies. Il cookie FPID deve comparire sotto il dominio del sito. Se lo trovi solo sotto l’hostname del container o non lo trovi affatto, il server non sta impostando il cookie via HTTP.

3. Header Set-Cookie. Apri la risposta della richiesta di collect e leggi l’header: ti aspetti Domain=.miosito.it, SameSite=Lax, Secure, e una Max-Age lunga. È qui che vedi nero su bianco se il cookie è first-party o no.

4. Safari e browser con ad-blocker. Apri il sito in Safari e in un browser con blocco attivo, naviga tre o quattro pagine, confronta gli eventi che arrivano. È il test che misura il beneficio reale, non la configurazione.

5. Catena del certificato. Un controllo SSL esterno ti dice se la catena è completa, qual è la data di scadenza e se il rinnovo è gestito. Segnalo la scadenza in calendario anche quando il rinnovo è automatico.

Multi-sito e agenzie: un container per tutti o uno per cliente?

La risposta discende dalla regola same-site: non puoi condividere un sottodominio first-party tra domini diversi. Se metti cinque clienti su tracking.agenzia.it, per i browser dei loro utenti quell’endpoint è cross-site in tutti e cinque i casi. Hai costruito un’infrastruttura che non produce il risultato per cui esiste.

Setup corretto per un’agenzia: un container per cliente, con sottodominio sul dominio del cliente. Il DNS lo gestisce chi ha accesso al dominio, l’infrastruttura può restare intestata all’agenzia o al cliente — ma mettilo per iscritto prima, insieme a chi paga il consumo e a chi risponde se l’endpoint cade. Se strutturi questo tipo di servizio in modo ricorrente, l’impostazione commerciale e operativa è trattata nella pagina dedicata alle web agency che rivendono il server-side.

Container condiviso: quando ha senso. Quando i siti stanno sotto lo stesso dominio registrabile. shop.brand.it, blog.brand.it e www.brand.it possono condividere s.brand.it e, impostando cookie_domain su .brand.it, condividono anche l’identificativo utente: un visitatore che passa dal blog allo shop resta la stessa persona. È uno dei pochi casi in cui il consolidamento porta un vantaggio analitico oltre che economico.

Governance. Separa il controllo del DNS dall’accesso al container. Chi modifica i tag non deve poter spostare un record DNS, e viceversa. E chiedi per iscritto al cliente l’autorizzazione a creare il sottodominio: è una modifica alla sua infrastruttura, non un dettaglio operativo.

Diagnosi: gli errori che bloccano davvero

Certificato fermo in provisioning. Nel 90% dei casi è uno di tre motivi: record CAA che non autorizza la CA di Google, record in modalità proxy che impedisce la validazione, record semplicemente non ancora propagato. Controlla il CAA con dig CAA miosito.it.

FAILED_NOT_VISIBLE. Google non vede il record atteso. Verifica con dig CNAME sgtm.miosito.it da una rete esterna, non dal tuo PC con la cache DNS piena.

404 o pagina di default di Cloud Run. La mappatura funziona ma punta a un servizio che non è il container, oppure il container non è in ascolto sul path richiesto. Prova /healthz.

CNAME in conflitto con un record A esistente. Il DNS non ammette un CNAME sullo stesso host dove esiste già un altro record. Rimuovi il vecchio record prima di creare il nuovo.

Dominio già verificato in un altro progetto GCP. Capita a chi ha ricreato il container o migrato progetto. La mappatura fallisce perché il dominio risulta rivendicato altrove: va rimossa la mappatura precedente o estesa la verifica al nuovo account.

CORS. Se il sito è su HTTPS e qualcosa nel percorso retrocede a HTTP, o se ci sono porte non standard, le richieste vengono bloccate dal browser. Si vede subito in console.

Cookie ancora di terze parti. Il sottodominio non è same-site. Torna alla tabella della seconda sezione.

Errore 525 o loop di redirect. SSL Flexible su Cloudflare. Passa a Full (strict).

Geolocalizzazione tutta uguale. Header di forwarding mancanti sul reverse proxy.

TTL alto. La configurazione sembra rotta per ore. Non aspettare guardando il browser: interroga direttamente i nameserver autoritativi con dig @ns1.provider.it sgtm.miosito.it e vedi la verità immediatamente.

Costi, manutenzione e quando serve aiuto

Il sottodominio non costa nulla: è un record sul dominio che già paghi. Il certificato gestito, su Cloud Run o su un hosting gestito, è incluso. L’unica voce fissa che il dominio personalizzato può introdurre è il load balancer, e solo negli scenari in cui serve davvero.

La manutenzione ricorrente è breve ma non è zero: rinnovo del certificato (verificato, non assunto), monitoraggio dell’uptime dell’endpoint, un alert che ti avvisa se il volume di eventi crolla. Quest’ultimo vale più degli altri due messi insieme.

Puoi procedere da solo?

Rispondi a queste quattro domande:

1. Sai chi sono i nameserver autoritativi del dominio e hai accesso a quel pannello?
2. Sai dire se davanti al dominio c’è un proxy, e sai cambiarne la modalità SSL?
3. Sai leggere l’output di dig e distinguere un record non propagato da un record sbagliato?
4. Sai dove si imposta server_container_url nella tua configurazione lato client?

Quattro sì: procedi. Un no sulla uno o sulla due: ti serve chi gestisce il DNS, e va coinvolto prima, non quando il certificato è già fallito. Se il blocco è sulla tre o sulla quattro, è materia da affiancamento tecnico — il percorso di tutoring su GTM server-side nasce esattamente per questi passaggi.

Documenta in otto righe

Prima di chiudere il ticket, scrivi da qualche parte: hostname completo, provider DNS, tipo di record creato e valore, chi gestisce il certificato e quando scade, se c’è un proxy e in che modalità, dove è impostato l’endpoint lato client, chi ha accesso al DNS, data della configurazione.

Tra otto mesi, quando qualcosa smetterà di funzionare, quelle otto righe varranno più di qualsiasi ricostruzione a memoria.

Domande frequenti

Posso usare un dominio completamente diverso da quello del sito per il container server?

Tecnicamente sì, funzionerà. Ma perdi il motivo per cui stai configurando un dominio personalizzato: per il browser quel dominio è cross-site rispetto al sito, quindi i cookie impostati dal container restano di terze parti e subiscono le stesse limitazioni dell’URL di default. Vale anche per un dominio che contiene il nome del cliente, tipo sgtm-miosito.it: il dominio registrabile è diverso, quindi è cross-site. Serve un sottodominio del dominio che l’utente sta visitando.

Cloudflare in modalità proxy crea problemi al container server?

Può crearne tre. Primo: durante l’emissione di un certificato gestito da Google, il proxy impedisce la validazione del record, con stato FAILED_NOT_VISIBLE. Metti il record in DNS only finché il certificato non è emesso. Secondo: con modalità SSL Flexible ottieni loop di redirect o errore 525, va impostata Full (strict). Terzo: se hai regole di cache aggressive sul dominio, devi escludere esplicitamente l’hostname del container, che non va mai messo in cache.

Cosa succede ai dati già raccolti quando cambio l'endpoint di tracciamento?

I dati storici in GA4 restano dove sono. Il rischio è sugli utenti in corso: cambiando il meccanismo di impostazione del cookie, alcuni visitatori possono essere riconosciuti come nuovi e le sessioni aperte possono spezzarsi. Per questo lo switch si fa con un periodo di doppio invio di almeno tre giorni, confrontando i conteggi evento per evento in DebugView e tenendo pronto il valore precedente di server_container_url per il rollback.

Devo creare un sottodominio anche per l'ambiente di staging?

Sì, se vuoi testare in condizioni realistiche. Usa un sottodominio dedicato sul dominio di staging, mantenendo la stessa relazione same-site che avrai in produzione: altrimenti i test sui cookie non ti dicono nulla di utile. Se lo staging gira su un dominio diverso dalla produzione, ricordati che i risultati sul comportamento dei cookie non sono trasferibili e vanno riverificati dopo il rilascio.