Hvis du allerede bruker server-side GTM, ikke bygg en andre konkurrerende Google-målingspipeline bare for å legge til Google Tag Gateway. Googles anbefalte kombinerte mønster skiller to stier med samme opprinnelse: en skriptbane videresender gtm.js- eller gtag.js-forespørsler til Google, mens en innsamlingsbane videresender målehendelser til taggingserveren din. Serverbeholderen forblir stedet der hendelser behandles og rutes.
Den kombinerte arkitekturen
Et oppsett med samme opprinnelse kan bruke stier som www.example.com/scripts for førsteparts Google-skriptinnlasting og www.example.com/metrics for serverbeholderen. CDN eller lastbalanser ruter hvert prefiks til en annen opprinnelse. Google advarer om at begge banene må være ubrukte og ikke må inneholde /gtm.
Nettleseren laster nettbeholderen eller Google-taggen gjennom skriptbanen. Google-taggen konfigureres deretter til å sende målinger til innsamlingsbanen. sGTM-klienten hevder den forespørselen, produserer en hendelse og utløser de riktige servertaggene.
Når du kjører begge er nyttig
Kombinasjonen er nyttig når du vil ha fordelene med nettleserresiliens ved lasting av førstepartsskript og også trenger sGTMs transformasjoner, dataminimering, ikke-Google-destinasjoner eller observerbarhet. Google anbefaler eksplisitt innlasting av førstepartsskript sammen med tagging på serversiden for et holdbart oppsett.
Det er mindre nyttig når GTG bare dupliserer funksjonalitet som allerede er levert av en riktig konfigurert førsteparts sGTM-laster og innsamlingsrute. Overvåk gjeldende banene før du legger til en ny regel. Arkitektur bør bli tydeligere etter endringen, ikke bare inneholde flere produkter.
Duplikat-hendelsesfellen
Det farlige mønsteret er å sende den samme Google-konverteringen direkte gjennom en GTG-videresendingsbane og også sende den gjennom sGTM, hvor en server-tag sender den inn igjen. Begge nettverksforespørslene kan lykkes, og etterlater oppblåste konverteringer som ser ut som forbedret gjenoppretting.
Definer én leveringseier for hver hendelse og destinasjon. Stabile transaksjons-IDer eller hendelses-IDer er fortsatt nyttige, men deduplisering bør være en sikkerhetsmekanisme, ikke den primære arkitekturen. Forhåndsvis nettleseren og serverbeholderne sammen og tell utgående destinasjonsforespørsler.
Samme opprinnelse er bedre enn et tilfeldig sporingsunderdomene
Google dokumenterer samme opprinnelse som den beste fremgangsmåten for server-sett informasjonskapsler sikkerhet og holdbarhet. En bane på nettstedverten, for eksempel www.example.com/metrics, har samme opprinnelse. Et underdomene som metrics.example.com er førstepart, men ikke av samme opprinnelse.
Ruting med samme opprinnelse krever normalt en CDN eller lastbalanser og forsiktig baneprioritet. Videresend alle informasjonskapsler og spørringsstrenger som kreves av tagging-serveren, rute hver klientbane inkludert den dokumenterte /_/*-underbanen og verifiser helseendepunktet før du endrer produksjonstagger.
Samtykke og personvern styrer fortsatt flyten
Førstepartsservering er en transportbeslutning, ikke tillatelse. Initialiser samtykkestandarder før måling, overfør samtykketilstanden til innsamlingsforespørselen og konfigurer servertagger slik at nektet lagring eller annonseringsvalg håndteres som designet.
Minimer data ved servergrensen. Se gjennom hvilke informasjonskapsler, overskrifter, spørringsparametere og hendelsesfelt som kommer inn i serverbeholderen, og tillat deretter bare feltene hver destinasjon trenger. GTG slipper ikke-Google-førstepartsinformasjonskapsler på sin egen videresendingsbane, men sGTM-innsamlingsbanen din har sine egne datahåndteringsansvar.
En klar beslutningsregel
Hvis du ikke har noen sGTM og bare trenger støttet Google-måling, kan GTG alene være tilstrekkelig. Hvis du har sGTM, aktiver førsteparts Google-skriptservering som en del av den arkitekturen og hold målesamlingen pekt mot serverbeholderen.
Hvis to lag eier GTG og sGTM, publiser et rutekart og begivenhetseiermatrise før lansering. En CDN-regel, nettbeholderinnstilling og servertag kan endres hvor den samme hendelsen går; udokumentert overlapping er den vanlige kilden til duplisering.
Bruk to veier, ikke to måleeiere
Skriptbanen og samlingsbanen er med vilje forskjellige. Skriptbanen laster inn Google-kode fra førstepart; innsamlingsbanen sender hendelser til sGTM. Ikke la begge banene levere den samme konverteringen uavhengig av hverandre.
Konfigurer GTG med server-side GTM
De nøyaktige menyene varierer etter CDN, men ansvar og valideringssekvens forblir den samme.
- 01
Bekreft at serverbeholderen er produksjonsklar
Bruk en produksjonstagging, en fungerende forhåndsvisningsserver, tilgangskontroller, overvåking og et tilpasset domene før du endrer nettleserruten.
- 02
Reserver to ubrukte stier med samme opprinnelse
Velg én skriptbane som /scripts og én samlingsbane som /metrics. Ingen av banene kan komme i konflikt med nettstedet eller inneholde /gtm.
- 03
Ruter innsamlingsbanen til sGTM
Konfigurer CDN eller lastbalanser for å videresende hele samlingsprefikset, informasjonskapsler og spørringsstrenger til taggingserveren, inkludert stier som kreves av serverklienter.
- 04
Legg til samlings-URLen i serverbeholderinnstillingene
Sett serverbeholder-URLen til URL-adressen med samme opprinnelse, inkludert baneprefikset, og bekreft deretter at den forventede klienten krever en forhåndsvisningsforespørsel.
- 05
Ruter skriptbanen for GTG
Videresend det reserverte skriptprefikset til Google-gateway-opprinnelsen og oppdater gtm.js- eller gtag.js-kilden for å laste gjennom den banen.
- 06
Pek Google-hendelser på innsamlingsbanen
Sett server_container_url eller tilsvarende Google-tag-innstilling til /metrics-endepunktet slik at målingen går inn i sGTM i stedet for å gå direkte til samme destinasjon to ganger.
- 07
Konfigurer klienter, tagger og samtykke
Bekreft klientprioritet, hendelsestransformasjoner, samtykkesjekker, destinasjonskoder og stabile hendelsesidentifikatorer inne i serverbeholderen.
- 08
Test hele ruten
Bekreft at skriptet lastes inn fra /scripts, én forespørsel når /metrics, serverklienten gjør krav på den og nøyaktig én forventet forespørsel går for hver destinasjon.
- 09
Overvåk etter utgivelse
Varsle om helsesvikt og uvanlig volum, gjennomgå destinasjonsdiagnostikk og avstem kjøp eller kundeemner med sannhet i kildesystemet.
Kjør komplementære lag, ikke parallelle rørledninger
GTG og sGTM fungerer godt sammen når gatewayen håndterer førsteparts skriptlevering og sGTM eier hendelsesbehandling. To-banemønsteret gjør den grensen synlig og testbar.
Konfigurasjonen mislykkes når den samme konverteringen har to leveringseiere. Dokumentstier, bevar én hendelsesidentitet, test samtykketilstander og tell forespørslene som faktisk forlater serveren.
GTG pluss sGTM: vanlige spørsmål
Bør hvert sGTM-oppsett også bruke Google Tag Gateway?
Førsteparts skriptvisning anbefales av Google, men kontroller din eksisterende laster og ruter først. Noen sGTM-oppsett betjener allerede avhengigheter fra førstepart og trenger kanskje bare en konfigurasjonsoppdatering.
Kan GTG og sGTM bruke samme bane?
Googles CDN-mønster bruker separate baner: én for skript og én for hendelsesinnsamling. Separate ruter forhindrer opprinnelseskonflikter og tydeliggjør ansvar.
Hvordan forhindrer jeg dupliserte Google-konverteringer?
Velg én avsender for hver konvertering. Hvis sGTM sender Google-destinasjonsforespørselen, må du ikke også sende en tilsvarende direkte nettleserforespørsel. Bekreft antall utgående forespørsler i forhåndsvisning og destinasjonsdiagnostikk.
Er et underdomene det samme som visning med samme opprinnelse?
Nei. Et underdomene er førstepart, men samme opprinnelse betyr samme opplegg, vertsnavn og port som nettstedet. Google lister begge opp som støttende server-sett informasjonskapsler, men kaller samme opprinnelse den beste praksisen.
Hvilken bane skal sende Meta- eller TikTok-hendelser?
Disse destinasjonsforespørslene bør opprettes av servertagger i sGTM eller annen serverintegrasjon. GTGs Google-skriptbane er ikke en generell ikke-Google-konverterings-API-rute.