Arkitektur och upplägg

    Ska du köra Google Tag Gateway och sGTM tillsammans?

    Ja, när varje lager har ett tydligt jobb. Servera Google-skript från första part, skicka händelser till en sGTM-uppsamlingsväg och förhindra parallellleverans från att duplicera konverteringar.

    2 augusti 2026 · 12 min läsning

    Om du redan använder server-side GTM, bygg inte en andra konkurrerande Google mätpipeline bara för att lägga till Google Tag Gateway. Googles rekommenderade kombinerade mönster separerar två sökvägar med samma ursprung: en skriptsökväg vidarebefordrar gtm.js- eller gtag.js-förfrågningar till Google, medan en insamlingsväg vidarebefordrar mäthändelser till din taggningsserver. Serverbehållaren förblir platsen där händelser bearbetas och dirigeras.

    Den kombinerade arkitekturen

    En konfiguration med samma ursprung kan använda sökvägar som www.example.com/scripts för att ladda Google-skript från första part och www.example.com/metrics för serverbehållaren. CDN eller lastbalanseraren dirigerar varje prefix till ett annat ursprung. Google varnar för att båda sökvägarna måste vara oanvända och inte får innehålla /gtm.

    Webbläsaren laddar webbbehållaren eller Google-taggen via skriptsökvägen. Google-taggen konfigureras sedan för att skicka mätning till insamlingsvägen. sGTM-klienten hävdar den begäran, producerar en händelse och utlöser lämpliga servertaggar.

    /scripts: förstaparts gtm.js eller gtag.js leverans
    /metrics: händelseinsamling av sGTM-slutpunkten
    sGTM-klient: konverterar begäran till en händelse
    Servertaggar: skicka kontrollerade nyttolaster till destinationer

    När du kör båda är användbart

    Kombinationen är användbar när du vill ha fördelarna med webbläsarmotståndskraft med att ladda skript från första part och även behöver sGTMs transformationer, dataminimering, icke-Google-destinationer eller observerbarhet. Google rekommenderar uttryckligen att förstapartsskript laddas tillsammans med taggning på serversidan för en hållbar installation.

    Det är mindre användbart när GTG bara skulle duplicera funktionalitet som redan tillhandahålls av en korrekt konfigurerad förstaparts sGTM-lastare och insamlingsväg. Granska de aktuella sökvägarna innan du lägger till ytterligare en regel. Arkitekturen ska bli tydligare efter förändringen, inte bara innehålla fler produkter.

    Förstapartsskriptleverans plus programmerbar bearbetning
    En styrd händelse kan mata flera destinationer
    Servercookies med samma ursprung var korrekt konfigurerade
    Ett ställe att inspektera transformationer och utgående taggar

    Dubbletthändelsefällan

    Det farliga mönstret är att skicka samma Google-konvertering direkt via en GTG-vidarebefordran och även skicka den via sGTM, där en servertagg skickar den igen. Båda nätverksförfrågningarna kan lyckas, vilket ger uppblåsta konverteringar som ser ut som förbättrad återställning.

    Definiera en leveransägare för varje händelse och destination. Stabila transaktions-ID:n eller händelse-ID:n är fortfarande användbara, men deduplicering bör vara en säkerhetsmekanism, inte den primära arkitekturen. Förhandsgranska webbläsaren och serverbehållaren tillsammans och räkna utgående destinationsförfrågningar.

    En ägare för varje evenemang-destinationspar
    En stabil transaktion eller händelse-ID från början
    Inga direkta Google-sändningar tillsammans med en motsvarande servertagg
    Räkna utgående förfrågningar, inte bara aktiverade taggar

    Samma ursprung är bättre än en slumpmässig spårningsunderdomän

    Google dokumenterar samma ursprung som bästa praxis för serveruppsättning av cookiessäkerhet och hållbarhet. En sökväg på webbplatsvärden, till exempel www.example.com/metrics, har samma ursprung. En underdomän som metrics.example.com är förstapart men inte av samma ursprung.

    Rutning med samma ursprung kräver normalt en CDN eller lastbalanserare och noggrann vägföreträde. Vidarebefordra alla cookies och frågesträngar som krävs av taggningsservern, dirigera varje klientsökväg inklusive den dokumenterade /_/* undersökvägen och verifiera hälsoslutpunkten innan du ändrar produktionstaggar.

    Samtycke och integritet styr fortfarande flödet

    Förstapartsservering är ett transportbeslut, inte tillstånd. Initiera standardinställningarna för samtycke före mätning, skicka samtyckestillståndet till insamlingsbegäran och konfigurera servertaggar så att nekad lagring eller reklamval hanteras som avsett.

    Minimera data vid servergränsen. Granska vilka cookies, rubriker, frågeparametrar och händelsefält som kommer in i serverbehållaren och tillåt sedan endast de fält som varje destination behöver. GTG släpper icke-Googles förstapartscookies på sin egen vidarebefordran, men din sGTM-insamlingsväg har sitt eget datahanteringsansvar.

    En tydlig beslutsregel

    Om du inte har någon sGTM och bara behöver stödd Google-mätning, kan enbart GTG vara tillräckligt. Om du har sGTM, aktivera förstapartstjänst av Google-skript som en del av den arkitekturen och håll mätinsamlingen riktad mot serverbehållaren.

    Om två lag äger GTG och sGTM, publicera en ruttkarta och evenemangsägarmatris innan lanseringen. En CDN-regel, webbbehållareinställning och servertagg kan var och en ändra vart samma händelse går; odokumenterad överlappning är den vanliga källan till dubbelarbete.

    Använd två vägar, inte två mätägare

    Skriptsökvägen och samlingsvägen är avsiktligt olika. Skriptsökvägen laddar Google-kod från första part; insamlingsvägen skickar händelser till sGTM. Låt inte båda vägarna leverera samma konvertering oberoende av varandra.

    Konfigurera GTG med server-side GTM

    De exakta menyerna varierar beroende på CDN, men ansvaret och valideringssekvensen förblir desamma.

    1. 01

      Bekräfta att serverbehållaren är produktionsklar

      Använd en produktionstaggning, en fungerande förhandsgranskningsserver, åtkomstkontroller, övervakning och en anpassad domän innan du ändrar webbläsarvägen.

    2. 02

      Reservera två oanvända sökvägar med samma ursprung

      Välj en skriptsökväg som /scripts och en samlingsväg som /metrics. Ingen av sökvägarna får komma i konflikt med webbplatsen eller innehålla /gtm.

    3. 03

      Led insamlingsvägen till sGTM

      Konfigurera CDN eller lastbalanserare för att vidarebefordra hela samlingsprefixet, cookies och frågesträngar till taggningsservern, inklusive sökvägar som krävs av serverklienter.

    4. 04

      Lägg till samlings-URL i serverbehållarens inställningar

      Ställ in serverbehållarens URL till samma ursprungs-URL inklusive dess sökvägsprefix och bekräfta sedan att den förväntade klienten gör anspråk på en förhandsgranskningsbegäran.

    5. 05

      Dirigera skriptsökvägen för GTG

      Vidarebefordra det reserverade skriptprefixet till Googles gateway-ursprung och uppdatera gtm.js- eller gtag.js-källan för att ladda genom den sökvägen.

    6. 06

      Peka Google-händelser på insamlingsvägen

      Ställ in server_container_url eller motsvarande Google-tagg-inställning till /metrics-slutpunkten så att mätningen går in i sGTM istället för att gå direkt till samma destination två gånger.

    7. 07

      Konfigurera klienter, taggar och samtycke

      Verifiera klientprioritet, händelsetransformationer, samtyckeskontroller, destinationstaggar och stabila händelseidentifierare inuti serverbehållaren.

    8. 08

      Testa hela rutten

      Bekräfta att skriptet laddas från /scripts, en begäran når /metrics, serverklienten gör anspråk på den och exakt en förväntad begäran lämnas för varje destination.

    9. 09

      Övervaka efter släpp

      Varna om hälsofel och ovanliga volymer, granska destinationsdiagnostik och stämma av köp eller potentiella kunder med sanning i källsystemet.

    Kör kompletterande lager, inte parallella pipelines

    GTG och sGTM fungerar bra tillsammans när gatewayen hanterar skriptleverans från första part och sGTM äger händelsebearbetning. Tvåvägsmönstret gör den gränsen synlig och testbar.

    Konfigurationen misslyckas när samma konvertering har två leveransägare. Dokumentsökvägar, bevara en händelseidentitet, testa samtyckestillstånd och räkna de förfrågningar som faktiskt lämnar servern.

    GTG plus sGTM: vanliga frågor

    Bör varje sGTM-installation också använda Google Tag Gateway?

    Förstapartsskriptvisning rekommenderas av Google, men granska din befintliga laddare och rutter först. Vissa sGTM-inställningar tjänar redan beroenden från första part och behöver kanske bara en konfigurationsuppdatering.

    Kan GTG och sGTM använda samma sökväg?

    Googles CDN-mönster använder separata sökvägar: en för skript och en för insamling av händelser. Separata vägar förhindrar ursprungskonflikter och gör ansvar tydligt.

    Hur förhindrar jag dubbletter av Google-konverteringar?

    Välj en avsändare för varje konvertering. Om sGTM skickar Googles destinationsbegäran, skicka inte också en motsvarande direkt webbläsarförfrågan. Verifiera antalet utgående begäranden i förhandsgransknings- och destinationsdiagnostik.

    Är en underdomän detsamma som visning med samma ursprung?

    Nej. En underdomän är förstapart, men samma ursprung betyder samma schema, värdnamn och port som webbplatsen. Google listar båda som stödjande serveruppsättningscookies men kallar samma ursprung bästa praxis.

    Vilken sökväg ska skicka Meta- eller TikTok-händelser?

    Dessa destinationsbegäranden ska skapas av servertaggar i sGTM eller annan serverintegrering. GTG:s Google-skriptsökväg är inte en allmän väg för konverterings-API som inte kommer från Google.

    Primära källor och vidare läsning

    Relaterade artiklar

    Bygg sGTM-lagret utan att köra infrastrukturen

    Tracking Hippo tillhandahåller hanterad EU-värd, övervakning och förutsägbar prissättning för din server-side GTM-container.

    Utforska fördelarna