Hvis dit website bruger Google Tag Manager, ændrer Google den måde, Tag Manager starter på dine sider. I en produktnote dateret 8. oktober 2026 skriver Google, at alle Tag Manager-containere (den boks i Tag Manager, der rummer dit websites tags) starter, så snart de er indlæst, i stedet for at vente på en gtag('config')-kommando på siden. Denne Google Tag Manager gtag config-ændring betyder mest for websites, der blander Tag Manager med separat Google tag-kode, og for containere med regler (triggere), der kører tags ved hver hændelse.

Google har sendt en mail til ejerne af de containere, som Google mener er sat forkert op. Google har ikke oplyst, hvor mange der er tale om, og hjælpesiden om løsningen siger stadig, at opdateringen kommer “snart”.

Hvad ændrede sig i Google Tag Manager den 8. oktober?

Google oplyser, at Tag Manager-containere ikke længere venter på linjen gtag('config'), den kommando, der fortæller et Google tag, hvilken konto data skal sendes til, og med hvilke indstillinger. I produktnoten fra 8. oktober står der: “Med denne opdatering initialiseres alle Google Tag Manager-containerkodestykker (gtm.js) ved indlæsning i container, uanset eventuelle gtag(‘config’)-kommandoer.”

Et kodestykke (snippet) er de få linjer kode, der indsættes på hver side af dit website. Et tag er et lille stykke kode, der registrerer, hvad der sker på dit website, for eksempel en sidevisning eller en sendt formular. Tagget sender oplysningerne til et værktøj som Google Analytics eller Google Ads. Et website kan indlæse Googles tags med et af to kodestykker:

Tag Manager-kodestykkeGoogle tag-kodestykke
Fil, der indlæsesgtm.jsgtag.js
ID, der brugesStarter med GTM-Et produkt-ID, for eksempel G- eller AW-

Begge kodestykker skriver til dataLayer, en kø af beskeder på siden, som Tag Manager læser. Indtil nu kunne en container få øje på en gtag('config')-linje et andet sted på siden og vente på den, og nogle websites var afhængige af det. Produktnoten ændrer også, hvad containeren ser: ændringen betyder, “at config-kommandoer nu vises i dataLayer som synlige gtag.config-hændelser”.

Sammenligning af Google Tag Manager før og efter ændringen i oktober: containerens start, gtag config-linjer, triggere med jokertegn og blandede opsætninger
Google siger, at containeren ikke længere venter. En gtag config-linje kommer som en hændelse, og triggere med jokertegn kan reagere på den.

Hvilke websites rammer Google Tag Manager gtag config-ændringen?

To grupper af websites er berørt. Googles mails gik til den første gruppe, som har det, Google kalder en implementering, “der ikke understøttes”. Den anden gruppe kan have en opsætning, som Google betragter som korrekt, men har regler (triggere), der kører tags ved hver hændelse.

Blandede opsætninger. Googles hjælpeside om opsætning af gtag.js beskriver websites, der indlæser et G-, AW- eller DC-ID via Tag Manager-kodestykkets sti. Googles eksempel på en forkert opsætning er det almindelige GTM-kodestykke efterfulgt af en selvstændig gtag('config')-linje. Om disse websites skriver Google, at de “kan opleve uventede ændringer i deres tagadfærd”, og at brugerne af containerne “har modtaget en mailnotifikation”.

Triggere med jokertegn. En trigger er reglen, der fortæller et tag, hvornår det skal køre. En trigger for tilpasset hændelse kan matche hændelsesnavne med mønsteret .*, som matcher alle hændelser i dataLayer. Googles produktnote advarer: “Hvis dine Google Tag Manager-containere bruger jokertegn til triggere for tilpasset hændelse, kan denne ændring medføre, at disse tags aktiveres.”

Googles hjælp om triggere for tilpasset hændelse anbefalede allerede et smallere mønster, fordi .* også matcher hændelser, som Tag Manager og Google tagget sender automatisk. PPC Land påpeger, at risikoen ved triggere med jokertegn også gælder websites, hvis opsætning Google betragter som korrekt, fordi selve standardkodestykket for gtag.js indeholder et config-kald.

Hvornår annoncerede Google gtag config-ændringen?

Advarslen kom uger før produktnoten. PPC News Feed omtalte meddelelsen på Googles hjælpeside den 27. august 2026. Den 20. august lagde en bruger i WordPress.org-supportforummet den mail ud, som en kunde havde fået fra Google. I mailen stod der (i vores oversættelse): “Fra den 2. oktober 2026 initialiseres alle gtm.js-kodestykker ved indlæsning af containeren”.

Produktnoten er dateret 8. oktober. Googles hjælpeside om løsningen siger stadig, at Tag Manager-kodestykker “opdateres snart”. Som både PPC Land og Relevant Audience påpeger, har Google ikke sagt, om ændringen nåede alle containere på én dag eller rulles ud gradvist.

Hvad Google ikke har sagt

Google har ikke givet en endelig frist eller noget mål for, hvor meget data ændringen kan forstyrre. Relevant Audience bemærker, at produktnoten “ikke nævner nogen begrænsning til bestemte lande eller regioner”, og hjælpesiden om løsningen nævner heller ingen.

Der er også et praktisk hul. Mailen gik til den person, der står på containeren. Relevant Audience påpeger, at hvis den person er en tidligere medarbejder eller en tidligere webudvikler, “er advarslen måske aldrig nået frem til den, der står for websitet i dag”.

Hvad det betyder for din virksomhed

Efter vores vurdering kræver det en omhyggelig gennemgang af din sporing. Opgaven er at tjekke, hvad dine sider indlæser, vælge en af Googles to løsninger, hvis din opsætning er blandet, og teste, at hver henvendelse tælles én gang. Vi ville tage trinnene i denne rækkefølge, før der ændres noget i dine annoncekonti.

  1. Find ud af, hvem der ejer containeren. Du skal have adgang til Tag Manager for at kunne tjekke noget, og det er virksomheden, der bør eje den, med et eventuelt bureau tilføjet som bruger. Vores guide til, hvordan du evaluerer et marketingbureau, forklarer, hvorfor kontiene bør ligge hos dig.
  2. Se, hvilket kodestykke dine sider indlæser. Åbn dit website, vis sidens kildekode, og søg efter “googletagmanager.com”. Hvis adressen indeholder gtm.js med et ID, der starter med GTM-, er din container indlæst ad den understøttede vej. Hvis gtm.js har et G-, AW- eller DC-ID, eller hvis en selvstændig gtag('config')-linje står ved siden af Tag Manager-kodestykket, har du den opsætning, Google advarede om.
  3. Vælg en af Googles to løsninger. Brug Google tag-kodestykket (gtag.js) på alle sider, og fjern gtm.js-kodestykket og eventuelle selvstændige config-linjer. Eller, hvis Tag Manager kører dine andre tags, så behold kodestykket med dit GTM-ID, og opsæt Google tagget inde i containeren. Overfør de indstillinger, den gamle config-linje sendte med, og lad din opsætning af cookiesamtykke blive, så tags stadig følger den besøgendes valg i dit cookiebanner.
  4. Søg i containeren efter .*-triggere. Åbn listen over triggere, og find triggere for tilpasset hændelse, der matcher alle hændelser. Indsnævr hver af dem til de hændelsesnavne, den har brug for, for et tag, der kører på gtag.config, kan sende de samme data igen og for eksempel tælle én henvendelse som to.
  5. Test med Tag Assistant og en rigtig henvendelse. Tag Assistant er Googles fejlfindingsværktøj til at tjekke tags på dit website, og ifølge Googles hjælpeside skal dit tag-id vises med et grønt eller blåt statusikon der. Send derefter en testhenvendelse fra din telefon, og tjek, at den tælles én gang, sådan som vi beskriver det for Google Ads, der giver klik, men ingen henvendelser. I vores styring af Google Ads tjekker vi sporingen, før vi ændrer bud.
  6. Sammenlign tallene med din indbakke eller dit CRM. Stil henvendelserne i din indbakke eller dit CRM op ved siden af de konverteringer, Google rapporterer for de samme dage, før og efter 8. oktober. Vi bruger det samme tjek i vores CRM- og analyseprojekter, og hvis tallene ikke længere stemmer, er tags det første sted at kigge.
Beslutningstræ: hvad Tag Manager-kodestykket i din sides kildekode viser, og hvilken løsning Google tilbyder i hvert tilfælde
Start med sidens kildekode. ID'et i kodestykket viser, hvilken løsning der gælder, og test derefter i Tag Assistant.

Ofte stillede spørgsmål

Påvirker gtag config-ændringen mit website, hvis jeg kun bruger Google Tag Manager?
Hvis din side indlæser containeren med et ID, der starter med GTM-, og ikke har en separat gtag('config')-linje, kalder Google ikke din opsætning ikke-understøttet. Ifølge Googles produktnote kan tags på triggere for tilpasset hændelse med jokertegn stadig blive aktiveret af den nye gtag.config-hændelse, så tjek de triggere.
Hvornår træder gtag config-ændringen i kraft?
Googles produktnote er dateret 8. oktober 2026. En mail fra Google til et berørt website, som blev lagt ud på WordPress.org den 20. august, nævnte 2. oktober 2026. Googles hjælpeside siger stadig, at opdateringen kommer snart. Google har ikke sagt, om den rulles ud til alle containere på én gang.
Hvad er gtag.config-hændelsen i dataLayer?
Det er den måde, en gtag('config')-kommando nu viser sig på for Google Tag Manager. Ifølge Googles produktnote vises config-kommandoer i dataLayer som synlige gtag.config-hændelser, så en trigger, der matcher alle hændelser, matcher også denne.
Hvordan retter jeg en Google tag-opsætning, der ikke understøttes?
Google tilbyder to veje. Brug Google tag-kodestykket (gtag.js) på alle sider, eller behold Google Tag Manager-kodestykket med dit GTM-ID, og opsæt Google tagget inde i containeren. Tjek derefter resultatet i Tag Assistant.

← Alle artikler