Se utilizzi già server-side GTM, non creare una seconda pipeline di misurazione Google concorrente solo per aggiungere Google Tag Gateway. Il modello combinato consigliato da Google separa due percorsi della stessa origine: un percorso di script inoltra le richieste gtm.js o gtag.js a Google, mentre un percorso di raccolta inoltra gli eventi di misurazione al server di tagging. Il contenitore del server rimane il luogo in cui gli eventi vengono elaborati e instradati.
L'architettura combinata
Una configurazione della stessa origine può utilizzare percorsi come www.example.com/scripts per il caricamento di script Google proprietari e www.example.com/metrics per il contenitore del server. La CDN o il sistema di bilanciamento del carico instrada ciascun prefisso a un'origine diversa. Google avverte che entrambi i percorsi devono essere inutilizzati e non devono contenere /gtm.
Il browser carica il contenitore web o il tag Google tramite il percorso dello script. Il tag Google viene quindi configurato per inviare la misurazione al percorso di raccolta. Il client sGTM rivendica tale richiesta, produce un evento e attiva i tag del server appropriati.
Quando si eseguono entrambi sono utili
La combinazione è utile quando si desiderano i vantaggi della resilienza del browser derivanti dal caricamento di script proprietari e sono necessarie anche le trasformazioni di sGTM, la minimizzazione dei dati, le destinazioni non Google o l'osservabilità. Google consiglia esplicitamente il caricamento di script proprietari insieme al tagging lato server per una configurazione duratura.
È meno utile quando GTG duplica solo la funzionalità già fornita da un caricatore sGTM di prima parte e da un percorso di raccolta correttamente configurato. Controlla i percorsi correnti prima di aggiungere un'altra regola. L'architettura dovrebbe diventare più chiara dopo il cambiamento e non contenere semplicemente più prodotti.
La trappola degli eventi duplicati
Lo schema pericoloso invia la stessa conversione di Google direttamente tramite un percorso di inoltro GTG e anche tramite sGTM, dove un tag del server la invia nuovamente. Entrambe le richieste di rete potrebbero avere esito positivo, lasciando conversioni gonfiate che sembrano un recupero migliorato.
Definisci un proprietario di consegna per ogni evento e destinazione. Gli ID transazione o ID evento stabili sono ancora utili, ma la deduplicazione dovrebbe essere un meccanismo di sicurezza, non l'architettura primaria. Visualizza l'anteprima dei contenitori browser e server insieme e conta le richieste di destinazione in uscita.
La stessa origine è migliore di un sottodominio con tracciamento casuale
Google documenta la stessa origine e funge da best practice per la sicurezza e la durata dei cookie impostati sul server. Un percorso sull'host del sito Web, ad esempio www.example.com/metrics, ha la stessa origine. Un sottodominio come metrics.example.com è proprietario ma non ha la stessa origine.
Il routing con la stessa origine richiede normalmente una CDN o un bilanciatore del carico e un'attenta precedenza dei percorsi. Inoltra tutti i cookie e le stringhe di query richieste dal server di tagging, instrada ogni percorso client incluso il sottopercorso /_/* documentato e verifica l'endpoint di integrità prima di modificare i tag di produzione.
Il consenso e la privacy continuano a controllare il flusso
La pubblicazione da parte dei proprietari è una decisione relativa al trasporto, non un'autorizzazione. Inizializza le impostazioni predefinite del consenso prima della misurazione, passa lo stato del consenso nella richiesta di raccolta e configura i tag del server in modo che l'archiviazione negata o le scelte pubblicitarie vengano gestite come previsto.
Ridurre al minimo i dati al limite del server. Controlla quali cookie, intestazioni, parametri di query e campi di eventi entrano nel contenitore del server, quindi consenti solo i campi necessari a ciascuna destinazione. GTG rilascia cookie proprietari non di Google nel proprio percorso di inoltro, ma il percorso di raccolta sGTM ha le proprie responsabilità di gestione dei dati.
Una regola decisionale chiara
Se non disponi di sGTM e hai solo bisogno della misurazione supportata da Google, GTG da solo potrebbe essere sufficiente. Se disponi di sGTM, abilita lo script Google proprietario che funge da parte di tale architettura e mantieni la raccolta delle misurazioni puntata sul contenitore del server.
Se due team possiedono GTG e sGTM, pubblica una mappa del percorso e una matrice di proprietà dell'evento prima del lancio. Una regola CDN, un'impostazione del contenitore Web e un tag del server possono modificare ciascuno la destinazione dello stesso evento; la sovrapposizione non documentata è la solita fonte di duplicazione.
Utilizza due percorsi, non due proprietari di misurazioni
Il percorso dello script e il percorso della raccolta sono intenzionalmente diversi. Il percorso dello script carica il codice Google di prima parte; il percorso di raccolta invia gli eventi a sGTM. Non lasciare che entrambi i percorsi forniscano indipendentemente la stessa conversione.
Configura GTG con server-side GTM
I menu esatti variano in base al CDN, ma le responsabilità e la sequenza di convalida rimangono le stesse.
- 01
Confermare che il contenitore del server sia pronto per la produzione
Utilizza una distribuzione di tag di produzione, un server di anteprima funzionante, controlli di accesso, monitoraggio e un dominio personalizzato prima di modificare il percorso del browser.
- 02
Prenota due percorsi della stessa origine non utilizzati
Scegli un percorso di script come /scripts e un percorso di raccolta come /metrics. Nessuno dei due percorsi può entrare in conflitto con il sito o contenere /gtm.
- 03
Indirizzare il percorso di raccolta a sGTM
Configura la CDN o il bilanciatore del carico per inoltrare il prefisso completo della raccolta, i cookie e le stringhe di query al server di tagging, inclusi i percorsi richiesti dai client del server.
- 04
Aggiungi l'URL della raccolta nelle impostazioni del contenitore del server
Imposta l'URL del contenitore del server sull'URL della stessa origine incluso il prefisso del percorso, quindi conferma che il client previsto richiede una richiesta di anteprima.
- 05
Instradare il percorso dello script per GTG
Inoltra il prefisso dello script riservato all'origine del gateway Google e aggiorna l'origine gtm.js o gtag.js per caricare tramite quel percorso.
- 06
Indirizza gli eventi di Google al percorso di raccolta
Imposta server_container_url o l'impostazione equivalente del tag Google sull'endpoint /metrics in modo che la misurazione entri in sGTM invece di andare direttamente alla stessa destinazione due volte.
- 07
Configura client, tag e consenso
Verifica la priorità del client, le trasformazioni degli eventi, i controlli del consenso, i tag di destinazione e gli identificatori di eventi stabili all'interno del contenitore del server.
- 08
Prova il percorso completo
Conferma che lo script viene caricato da /scripts, una richiesta raggiunge /metrics, il client del server la rivendica e parte esattamente una richiesta prevista per ciascuna destinazione.
- 09
Monitorare dopo il rilascio
Avvisa su problemi di salute e volumi insoliti, esamina la diagnostica della destinazione e riconcilia gli acquisti o i lead con la verità del sistema di origine.
Esegui livelli complementari, non pipeline parallele
GTG e sGTM funzionano bene insieme quando il gateway gestisce la consegna degli script proprietari e sGTM possiede l'elaborazione degli eventi. Il modello a due percorsi rende quel confine visibile e verificabile.
La configurazione ha esito negativo quando la stessa conversione ha due proprietari di consegna. Documenta i percorsi, preserva l'identità di un evento, testa gli stati di consenso e conta le richieste che lasciano effettivamente il server.
GTG più sGTM: domande comuni
Ogni configurazione sGTM dovrebbe utilizzare anche Google Tag Gateway?
Google consiglia la pubblicazione di script proprietari, ma controlla prima il caricatore e i percorsi esistenti. Alcune configurazioni sGTM supportano già le dipendenze di prima parte e potrebbero richiedere solo un aggiornamento della configurazione.
GTG e sGTM possono utilizzare lo stesso percorso?
Il modello CDN di Google utilizza percorsi separati: uno per gli script e uno per la raccolta degli eventi. Percorsi separati prevengono i conflitti di origine e chiariscono le responsabilità.
Come posso evitare conversioni Google duplicate?
Scegli un mittente per ogni conversione. Se sGTM invia la richiesta di destinazione di Google, non inviare anche una richiesta equivalente diretta del browser. Verifica il conteggio delle richieste in uscita nell'anteprima e nella diagnostica della destinazione.
Un sottodominio è uguale alla pubblicazione della stessa origine?
No. Un sottodominio è di prima parte, ma stessa origine significa lo stesso schema, nome host e porta del sito web. Google li elenca entrambi come cookie impostati sul server che supportano, ma ritiene che la stessa origine sia la migliore pratica.
Quale percorso deve inviare eventi Meta o TikTok?
Tali richieste di destinazione devono essere create dai tag del server in sGTM o da un'altra integrazione del server. Il percorso dello script Google di GTG non è un percorso API di conversione generale non Google.