Illustration af en strøm af ens datapakker, hvor en enkelt ekstra pakke er sluppet med ubemærket

Kort fortalt

Googles release note for Tag Manager af 8. oktober 2026 standardiserer snippet-adfærden: alle gtm.js-containere initialiserer nu ved container-load uanset gtag('config'), og config-kommandoer dukker op i dataLayer som synlige gtag.config-events. Google har mailet ejerne af de installationer, der kan knække — et gtm.js-snippet med et G-, AW- eller DC-ID eller en løs config-linje — men oplyser ikke hvor mange. Den anden gruppe får ingen mail: enhver container med en custom event-trigger på .* fyrer nu de tags én gang ekstra pr. sidevisning, og det gælder også sites på Googles egen gtag.js-snippet, fordi den selv indeholder en config-kommando. Release noten angiver intet antal berørte containere og ingen udrulningsdato ud over datoen selv. Hjælpesiden fra 20. august 2026 peger på gtm init-triggeren som vejen til at bevare den gamle rækkefølge; release noten peger på at flytte til gtag.js.

Den dyre halvdel af Googles gtag-ændring er ikke de installationer, der knækker — det er dem, hvor intet knækker. En hybridopsætning, der mister sine parametre, efterlader et hul i en rapport, som nogen før eller siden finder. En container med en wildcard-trigger tæller bare én hændelse mere pr. sidevisning, og den forskel ligner almindelig variation.

Hvad der står i release noten

Google offentliggjorde 8. oktober 2026 en post i Tag Managers release notes under overskriften om standardisering af gtag('config')-adfærden. Den indeholder to sætninger, der betyder noget. Den første: alle gtm.js-containersnippets initialiserer nu ved container-load — uanset om siden kalder gtag('config') eller ikke. Den anden: config-kommandoer dukker fra nu af op i dataLayer som synlige gtag.config-events.

Google beskriver selv formålet som standardisering af tagging-snippets for at sikre konsistens, pålidelighed og performance. Det er en rimelig beskrivelse. Konsekvenserne fordeler sig bare ikke jævnt.

Første sætning fjerner en skjult afhængighed: containeren ventede før på et signal, som en del installationer i praksis brugte som startskud. Anden sætning gør det modsatte — den lægger noget i dataLayer, der ikke lå der før. Og dataLayer er netop det sted, triggere lytter.

To grupper, kun den ene fik en mail

Fire opsætninger og hvad der sker med dem efter 8. oktober 2026 Tidslinje over Googles to dokumenter, 20. august og 8. oktober 2026, og en oversigt over fire Tag Manager-opsætninger, hvor to er uændrede og to ændrer adfærd. 20. august 2026 Hjælpeside: nye snippets uden config-kommando 8. oktober 2026 Release note: config bliver et synligt gtag.config-event OPSÆTNING EFTER ÆNDRINGEN Kun gtag.js-snippet, ingen wildcard-trigger Uændret gtag.js-snippet plus en custom event-trigger på .* Tagget fyrer én gang ekstra pr. sidevisning. Ingen fejl. GTM-container med Google tag inde i containeren Uændret gtm.js-snippet med G-, AW- eller DC-ID, eller løs config Parametre kan falde ud Google har mailet ejerne Googles egen gtag.js-snippet indeholder selv en config-kommando. Derfor rammer anden linje også installationer, der følger dokumentationen — og de får ingen mail, fordi intet er sat forkert op.
Kilder: Googles release note af 8. oktober 2026 og hjælpesiden af 20. august 2026. Google har ikke oplyst, hvor mange containere der er berørt.

Den første gruppe er den, al dækningen handler om: hybridinstallationerne. Det er et gtm.js-snippet, hvor der står et G-, AW- eller DC-ID i stedet for et GTM-ID, eller et gtm.js-snippet ved siden af en løs gtag('config')-linje uden en gtag.js-loader. Google skriver, at de kan opleve uventede ændringer i tag-adfærden, og har ifølge PPC Lands gennemgang mailet ejerne af berørte containere. Hvor mange, oplyser Google ikke.

Den gruppe har et problem, der kan ses. De parametre, config-linjen bar — konverteringsindstillinger, analytics-felter — holder op med at komme med. Nogen opdager et tomt felt i en rapport, og så bliver det rettet.

Den gruppe, der bare tæller forkert

Den anden gruppe får ingen mail, fordi der ikke er noget i vejen med installationen. Har containeren en custom event-trigger med mønsteret .*, matcher den alt, hvad der kommer i dataLayer — og nu kommer der et gtag.config-event mere pr. sidevisning. Hvert tag på den trigger fyrer én gang ekstra.

Det rammer også sites, der gjorde præcis som dokumentationen siger. Googles egen gtag.js-snippet indeholder selv en config-kommando. Den korrekte, understøttede installation producerer altså selv det event, der udløser den ekstra firing. Mest udsat er de tags, der skriver videre: logning, debug-tags, og alt der sender hændelser til en tredjepart, hvor du ikke selv kan rydde op bagefter.

Forskellen mellem de to grupper er ikke, hvor alvorligt det er. Det er, om det kan ses. En måling, der knækker, bliver rettet. En måling, der er forurenet, bliver rapporteret.

Datoen gør det værre

8. oktober 2026 er også dagen, hvor Google meldte september 2026-spamopdateringen færdigudrullet. Den startede 24. september. Alle, der i disse uger sidder og regner på, hvad opdateringen gjorde ved deres trafik, gør det altså oven på et eventstream, der ændrede sig samme dag.

Og de tal var skrøbelige i forvejen. I samme periode serverede Google afkortede resultatsider til rank trackere, så synligheden i tredjepartsværktøjerne faldt uden at rangeringerne gjorde det. Når to målefejl og en rigtig rangeringsændring overlapper i kalenderen, bliver attribution gætværk — og gætværket bliver til beslutninger om indhold og budget.

Det kedelige modtræk virker: sæt en annotering på 8. oktober 2026 i den rapportering, du faktisk træffer beslutninger ud fra, og skriv hvad der skete. Et datapunkt, du ved er urent, er stadig brugbart. Et du har glemt er urent, er værre end ingenting.

Rækkefølgen jeg tjekker i

Strukturen, ikke koden. Fire trin, i den rækkefølge, fordi hvert trin afgør, om det næste er relevant.

  1. Find ud af, hvilket snippet der faktisk ligger på siderne. Netværksfanen svarer på det: en forespørgsel til gtag/js eller til gtm.js, og hvilket ID der står i den. Det afgør, hvilken af de to grupper du er i — og opsætningen er overraskende ofte ikke den, firmaets egen dokumentation påstår.
  2. Lav en liste over alle triggere med et wildcard-mønster. Sortér den efter, hvad tagget gør bagefter, ikke efter hvor tit det fyrer. Et tag, der sender en konvertering eller remarketing-data videre, er en anden sag end et, der sætter en variabel.
  3. Erstat mønsteret med de hændelsesnavne, tagget reelt skal reagere på — eller udeluk config-eventet eksplicit. Wildcard-triggeren var aldrig en specifikation. Den var en antagelse om, at dataLayer ikke ændrer sig, og den antagelse holdt til 8. oktober.
  4. Verificér i preview, og dokumentér datoen. Preview viser, hvilke tags der fyrer på det nye event. Annoteringen sikrer, at den, der læser tallene om et halvt år, ved hvorfor der er et knæk.

Beslutningen om at flytte til gtag.js eller blive i Tag Manager kommer sidst, og de to dokumenter svarer forskelligt. Hjælpesiden fra 20. august 2026 peger på gtm init-triggeren, der kan få et tag til at vente på config-kommandoen og dermed bevare en gammel opsætning. Release noten fra 8. oktober peger på at køre gtag.js på alle sider. Hvilket svar der er rigtigt, afhænger af, om du vil beholde opsætningen eller af med den — ikke af hvilket dokument du fandt først.

Standardisering har altid en modtager

Google kalder det standardisering, og set fra deres side er det præcis det: én adfærd i stedet for flere, og en skjult afhængighed mindre at vedligeholde. Prisen betales af dem, der byggede oven på den gamle adfærd, og den fordeles ikke efter, hvem der gjorde noget forkert.

De installationer, der knækker, får en mail og en fejl, man kan se. De, der fulgte dokumentationen og har en wildcard-trigger, får ingen mail og et tal, der er en smule for højt. Det er den gruppe, jeg ville tjekke først.