Hvis du allerede bruger server-side GTM, skal du ikke bygge en anden konkurrerende Google-målingspipeline bare for at tilføje Google Tag Gateway. Googles anbefalede kombinerede mønster adskiller to stier med samme oprindelse: en scriptsti videresender gtm.js- eller gtag.js-anmodninger til Google, mens en indsamlingssti videresender målehændelser til din tagging-server. Servercontaineren forbliver det sted, hvor hændelser behandles og dirigeres.
Den kombinerede arkitektur
En opsætning med samme oprindelse kan bruge stier såsom www.example.com/scripts til indlæsning af førsteparts Google-script og www.example.com/metrics til servercontaineren. CDN'en eller belastningsbalanceren dirigerer hvert præfiks til en anden oprindelse. Google advarer om, at begge stier skal være ubrugte og ikke må indeholde /gtm.
Browseren indlæser webcontaineren eller Google-tagget gennem scriptstien. Google-tagget konfigureres derefter til at sende måling til indsamlingsstien. sGTM-klienten hævder denne anmodning, producerer en hændelse og udløser de relevante server-tags.
Når du kører, er begge dele nyttigt
Kombinationen er nyttig, når du ønsker browser-resiliens-fordele ved indlæsning af scripts fra første part og også har brug for sGTM's transformationer, dataminimering, ikke-Google-destinationer eller observerbarhed. Google anbefaler eksplicit, at førsteparts script indlæses sammen med tagging på serversiden for en holdbar opsætning.
Det er mindre nyttigt, når GTG kun vil duplikere funktionalitet, der allerede er leveret af en korrekt konfigureret førsteparts sGTM-indlæser og indsamlingsrute. Overvåg de aktuelle stier, før du tilføjer en anden regel. Arkitekturen skal blive tydeligere efter ændringen, ikke blot indeholde flere produkter.
Duplikathændelsesfælden
Det farlige mønster er at sende den samme Google-konvertering direkte gennem en GTG-videresendelsessti og også sende den gennem sGTM, hvor et servertag sender den igen. Begge netværksanmodninger kan lykkes, hvilket efterlader oppustede konverteringer, der ligner forbedret gendannelse.
Definer én leveringsejer for hver begivenhed og destination. Stabile transaktions-id'er eller hændelses-id'er er stadig nyttige, men deduplikering bør være en sikkerhedsmekanisme, ikke den primære arkitektur. Se forhåndsvisning af browser- og serverbeholderne sammen, og tæl udgående destinationsanmodninger.
Samme oprindelse er bedre end et tilfældigt sporingsunderdomæne
Google dokumenterer samme oprindelse, hvilket fungerer som den bedste praksis for server-set cookie-sikkerhed og holdbarhed. En sti på webstedsværten, såsom www.example.com/metrics, har samme oprindelse. Et underdomæne såsom metrics.example.com er førstepart, men ikke af samme oprindelse.
Ruting med samme oprindelse kræver normalt en CDN eller load balancer og omhyggelig sti-forrang. Videresend alle cookies og forespørgselsstrenge, der kræves af tagging-serveren, rute hver klientsti inklusive den dokumenterede /_/*-understi og verificer sundhedsslutpunktet, før du ændrer produktionstags.
Samtykke og privatliv styrer stadig strømmen
Førstepartsservering er en transportbeslutning, ikke tilladelse. Initialiser samtykkestandarder før måling, overfør samtykketilstanden til indsamlingsanmodningen og konfigurer servertags, så afviste lagrings- eller reklamevalg håndteres som designet.
Minimer data ved servergrænsen. Gennemgå hvilke cookies, overskrifter, forespørgselsparametre og hændelsesfelter, der kommer ind i servercontaineren, og tillad derefter kun de felter, hver destination har brug for. GTG dropper ikke-Google-førstepartscookies på sin egen videresendelsessti, men din sGTM-indsamlingssti har sit eget datahåndteringsansvar.
En klar beslutningsregel
Hvis du ikke har nogen sGTM og kun har brug for understøttet Google-måling, kan GTG alene være tilstrækkeligt. Hvis du har sGTM, skal du aktivere førsteparts Google-scriptservering som en del af denne arkitektur og holde målesamlingen rettet mod servercontaineren.
Hvis to hold ejer GTG og sGTM, skal du offentliggøre et rutekort og begivenhedsejerskabsmatrix før lancering. En CDN-regel, webcontainerindstilling og servertag kan hver ændre sig, hvor den samme hændelse går; udokumenteret overlapning er den sædvanlige kilde til duplikering.
Brug to stier, ikke to måleejere
Scriptstien og samlingsstien er bevidst forskellige. Scriptstien indlæser Google-kode fra førstepart; indsamlingsstien sender hændelser til sGTM. Lad ikke begge stier uafhængigt levere den samme konvertering.
Konfigurer GTG med server-side GTM
De nøjagtige menuer varierer efter CDN, men ansvar og valideringssekvens forbliver den samme.
- 01
Bekræft, at servercontaineren er produktionsklar
Brug en produktions-tagging-implementering, en fungerende preview-server, adgangskontrol, overvågning og et tilpasset domæne, før du ændrer browserruten.
- 02
Reserver to ubrugte stier med samme oprindelse
Vælg en scriptsti såsom /scripts og en samlingssti såsom /metrics. Ingen af stierne må være i konflikt med webstedet eller indeholde /gtm.
- 03
Rut indsamlingsstien til sGTM
Konfigurer CDN eller load balancer til at videresende hele samlingspræfikset, cookies og forespørgselsstrenge til tagging-serveren, inklusive stier, der kræves af serverklienter.
- 04
Tilføj samlingens URL i servercontainerindstillinger
Indstil servercontainer-URL'en til URL-adressen med samme oprindelse inklusive dens stipræfiks, og bekræft derefter, at den forventede klient kræver en forhåndsvisningsanmodning.
- 05
Rut scriptstien til GTG
Videresend det reserverede script-præfiks til Google-gatewayens oprindelse, og opdater gtm.js- eller gtag.js-kilden for at indlæse gennem denne sti.
- 06
Peg Google-begivenheder på indsamlingsstien
Indstil server_container_url eller den tilsvarende Google-tag-indstilling til /metrics-slutpunktet, så målingen går ind i sGTM i stedet for at gå direkte til den samme destination to gange.
- 07
Konfigurer klienter, tags og samtykke
Bekræft klientprioritet, hændelsestransformationer, samtykketjek, destinationstags og stabile hændelses-id'er inde i servercontaineren.
- 08
Test hele ruten
Bekræft, at scriptet indlæses fra /scripts, én anmodning når /metrics, serverklienten gør krav på den, og præcis én forventet anmodning forlader hver destination.
- 09
Overvåg efter frigivelse
Advarsel om helbredsfejl og usædvanlig mængde, gennemgå destinationsdiagnostik og afstem køb eller kundeemner med kildesystemets sandhed.
Kør komplementære lag, ikke parallelle rørledninger
GTG og sGTM fungerer godt sammen, når gatewayen håndterer førsteparts scriptlevering, og sGTM ejer hændelsesbehandling. Det to-vejs mønster gør denne grænse synlig og testbar.
Konfigurationen mislykkes, når den samme konvertering har to leveringsejere. Dokumentstier, bevar én begivenhedsidentitet, test samtykketilstande og tæl de anmodninger, der faktisk forlader serveren.
GTG plus sGTM: almindelige spørgsmål
Skal hver sGTM-opsætning også bruge Google Tag Gateway?
Førsteparts script-visning anbefales af Google, men kontroller først din eksisterende loader og ruter. Nogle sGTM-opsætninger tjener allerede afhængigheder fra førstepart og behøver muligvis kun en konfigurationsopdatering.
Kan GTG og sGTM bruge den samme sti?
Googles CDN-mønster bruger separate stier: en til scripts og en til indsamling af begivenheder. Separate ruter forhindrer oprindelseskonflikter og gør ansvar klart.
Hvordan forhindrer jeg duplikerede Google-konverteringer?
Vælg én afsender for hver konvertering. Hvis sGTM sender Googles destinationsanmodning, skal du ikke også sende en tilsvarende direkte browseranmodning. Bekræft antallet af udgående anmodninger i forhåndsvisning og destinationsdiagnostik.
Er et underdomæne det samme som visning med samme oprindelse?
Nej. Et underdomæne er førstepart, men samme oprindelse betyder det samme skema, værtsnavn og port som webstedet. Google angiver begge som understøttende server-sæt cookies, men kalder samme oprindelse den bedste praksis.
Hvilken sti skal sende Meta- eller TikTok-begivenheder?
Disse destinationsanmodninger skal oprettes af servertags i sGTM eller en anden serverintegration. GTG's Google-scriptsti er ikke en generel ikke-Google konvertering API-rute.