Google Tag Manager fra tom container til styret måling

Hvad gør Google Tag Manager, som Analytics ikke gør?

Tag Manager måler ingenting. Det er en beholder, der afgør hvilke sporingskoder der kører på dit website, hvornår de kører, og hvad de får med. Google Analytics er derimod et af de værktøjer, containeren sender data til. Det ene styrer, det andet gemmer og rapporterer.

Forvirringen er helt forståelig. Begge hedder Google, begge har et ID der starter med G eller GTM, og begge bliver installeret med en kodestump i toppen af siden. Mange af de kunder jeg møder, tror at de har Tag Manager, fordi deres webudvikler engang satte Analytics på.

Forskellen bliver tydelig i det øjeblik du skal tilføje noget nyt. Har du kun Analytics, skal du i koden hver gang. Har du en container, logger du ind, laver ændringen, tester den og udgiver. Der går fem minutter i stedet for to uger i en udviklerkø.

Hvorfor ender så mange med syv sporingskoder i temaet?

Sidste år gennemgik jeg en webshop for en kunde i fødevarebranchen. Vi talte syv forskellige sporingskoder hardcodet direkte i WordPress-temaets header-fil. Analytics i både den gamle og den nye udgave, to Google Ads konverteringskoder, en Meta Pixel, en kode fra et affiliate-netværk de stoppede med at bruge i 2021, og en sidste som ingen kunne identificere.

Ingen turde fjerne noget. Markedsføringsansvarlige havde arvet siden fra sin forgænger. Udvikleren var skiftet to gange. Og argumentet var altid det samme: hvad nu hvis den der kode er den, der får annoncetallene til at virke?

Sådan opstår det. Ikke fordi nogen har sjusket, men fordi hver enkelt tilføjelse gav mening den dag den blev lavet. En kampagne skulle i luften, en leverandør bad om en kode, nogen sendte en mail med "kan du lige sætte den her ind?". Fem år senere har du et lag af koder, hvor halvdelen sender data til konti, ingen længere har adgang til.

Vi brugte en eftermiddag på at kortlægge hvilke koder der stadig havde en modtager i den anden ende. Tre kunne fjernes med det samme. To blev flyttet ind i containeren. To blev lukket ned, fordi kontoen de pegede på, var opsagt. Sidegevinsten var en side, der blev mærkbart hurtigere, fordi fire scripts ikke længere skulle hentes ved hvert sidevisning.

Hvad betyder det, at containeren samler det hele ét sted?

Når koderne ligger i containeren, kan du åbne den og se en liste. Hvert tag har et navn, en type, en trigger og et tidspunkt for hvornår det sidst blev ændret og af hvem. Det lyder banalt, men det er forskellen på at gætte og at vide.

Containeren gemmer ikke en eneste datapost. Den har ingen rapporter, ingen tal, ingen besøgsstatistik. Logger du ind og leder efter din trafik, finder du ingenting. Containerens eneste opgave er at udløse de rigtige koder på de rigtige tidspunkter og sende data videre til de systemer, der gemmer og rapporterer.

Forholdet mellem de fire ting, folk oftest blander sammen: containeren er rammen. GA4 er et tag inde i containeren, som sender sidevisninger og events til din Analytics-ejendom. Google Ads konverteringer er et andet tag, som fortæller annoncekontoen at nogen købte. Meta Pixel er et tredje tag, som sender det samme signal til Facebook og Instagram. Alle tre bor i containeren, men dataene lander tre forskellige steder, og du henter rapporterne i tre forskellige systemer.

Det forklarer også hvorfor tallene aldrig matcher helt. Hvert system tæller på sin egen måde, med sin egen tilskrivningsmodel og sit eget vindue. Containeren sender de samme hændelser afsted, men de tre modtagere er uenige om hvad de har modtaget. Mere om det et andet sted.

Tag Manager er gratis i standardudgaven, og det gælder også de fleste SMV'er med god margin. Grænserne og betingelserne står i Googles egen dokumentation til Tag Manager, som også er stedet jeg selv slår op, når en tagtype opfører sig underligt.

Hvordan sætter du containeren op uden at bryde noget?

Du opretter en gratis konto på tagmanager.google.com, laver en container til dit domæne, og sætter de to kodestumper ind på alle sider. Bagefter fjerner du de gamle sporingskoder fra temaet i samme arbejdsgang. Springer du det sidste trin over, tæller du alting to gange fra dag ét.

Selve opsætningen tager tyve minutter, hvis du har adgang til dit website og en Google-konto. Det der tager tid, er oprydningen bagefter. De fleste sider jeg kommer ud til, har allerede en Analytics-kode i temaet, et Facebook-pixel i en plugin og måske en Google Ads-konvertering et tredje sted. Alt det skal flyttes ind i containeren og slukkes der hvor det ligger nu.

Hvad er forskellen på en konto og en container?

En konto er virksomheden. En container er et website eller en app. Har du ét domæne, har du én konto med én container. Driver du tre webshops, laver du stadig kun én konto, men tre containere under den. Det er på kontoniveau du styrer, hvem der har adgang, og på containerniveau du styrer, hvad de må lave.

Containeren har et ID der starter med GTM og efterfølges af syv tegn. Det ID er det eneste der skal ind på dit website. Når du senere tilføjer et nyt tag, sker det inde i containeren, og det går live når du trykker udgiv. Websitet rører du ikke igen. Vælg typen Web når du opretter, medmindre du laver en app.

Hvordan får du koden ind på WordPress, Shopify eller et headless site?

Google giver dig to kodestumper. Den første skal så højt op i head som muligt, den anden lige efter det åbnende body-tag. Den anden er en fallback til browsere uden JavaScript og bliver glemt i måske hver tredje opsætning jeg ser. Det går sjældent galt, men tag den med, det koster ingenting.

På WordPress lægger du dem i temaets header.php, eller bruger en plugin som indsætter dem for dig. Bruger du et tema du har købt, har det ofte et felt til scripts i indstillingerne. På Shopify sætter du dem ind i theme.liquid, samme to steder. På et headless site, typisk Next.js eller lignende, lægger udvikleren dem i det fælles layout, så de indlæses på alle ruter og ikke kun på forsiden.

Test altid på en undersides adresse, ikke kun forsiden. Jeg har set opsætninger hvor containeren kun lå på forsiden, fordi den var sat ind i en forsideskabelon. Hele resten af sitet var usynligt i målingen i fire måneder. Den slags opdager du på to minutter ved at åbne en produktside og tjekke om containeren indlæses. Den officielle vejledning hos Google Tag Manager Hjælp viser præcis hvor kodestumperne hører hjemme.

Hvorfor skal de gamle hardcodede koder væk med det samme?

Fordi du ellers måler alt to gange. Dobbelttælling af konverteringer er den klart hyppigste fejl jeg finder, når nogen har sat Tag Manager op oven på en eksisterende opsætning. En kunde i Sydjylland rapporterede 180 leads på en måned til ledelsen. Det rigtige tal var 90. Både temaets gamle konverteringskode og det nye tag i containeren fyrede på samme takside, og ingen havde tjekket efter.

Konsekvensen er ikke bare et forkert tal i en rapport. Google Ads optimerer efter de konverteringer, så budgivningen bliver skæv, og prisen per lead ser ud til at være det halve af hvad den er. Derfor flytter jeg altid ét tag ad gangen: sæt det op i containeren, tjek at det virker, slet så det gamle, og tjek igen dagen efter. Rækkefølgen betyder noget. Hele grundlaget for at stole på tallene bagefter hænger sammen med, hvordan du griber webanalyse i en mindre virksomhed an fra start.

Få viden du kan bruge i din markedsføring

Du får konkrete erfaringer fra arbejdet med danske virksomheder, skrevet så du kan handle på det. Ingen reklame.

Tags, triggers og variabler forklaret på dansk

Et tag er den kode der sendes afsted, en trigger er reglen for hvornår det sker, og en variabel er den oplysning der følger med. Tre begreber, og de hænger sammen i den rækkefølge. Uden trigger fyrer tagget aldrig. Uden variabel ved du ikke hvad der skete.

Når jeg sidder sammen med en kunde første gang, tegner jeg det på et stykke papir. Tag er handlingen, trigger er kontakten på væggen, variabel er den besked der sidder på bagsiden af handlingen. Så snart den model sidder, bliver resten af Tag Manager overraskende logisk.

Hvordan ser et konkret opsæt ud, når nogen klikker på telefonnummeret?

Tag en håndværksvirksomhed jeg har arbejdet med i Esbjerg. De fik langt de fleste henvendelser på telefonen, og alligevel kunne de ikke se en eneste af dem i Analytics. Opsætningen tog tyve minutter.

Resultatet var at de på tre uger kunne se 180 klik på telefonnummeret, fordelt på to forskellige numre. Det ene nummer stod i footeren og fik næsten ingen klik. Det andet lå øverst på servicesiderne. Den viden flyttede nummeret op på forsiden også.

Lige den slags event bliver først brugbart, når det kommer ordentligt ind i rapporterne. Hvordan du bygger videre på det i Analytics, har jeg skrevet om i min gennemgang af Google Analytics 4.

Hvilke triggertyper har du brug for i starten?

Der findes en lang liste, men du kommer meget langt med seks. Sidevisning fyrer når siden indlæses, og den bruger du til Analytics-grundtagget. Klik findes i to varianter, alle elementer og kun links, hvor linkvarianten er den du skal bruge til telefon, mail og downloads.

Formularindsendelse lyder oplagt, men den virker kun hvis formularen sender en rigtig submit. Mange moderne formularer gør ikke det, og så skal du en anden vej. Elementsynlighed fyrer når noget kommer frem på skærmen, og den bruger jeg typisk til en tak-besked der dukker op uden sideskift.

Timer fyrer efter et antal sekunder og kan bruges til at skille reel læsning fra hurtige afvisninger. Brugerdefineret hændelse fanger det, en udvikler har lagt ud på siden. Det er den mest holdbare af dem alle, og den vender jeg tilbage til senere i artiklen.

Hvorfor er undtagelser det værktøj flest overser?

Hver trigger kan få en undtagelse, altså en regel for hvornår tagget alligevel ikke skal fyre. Feltet ligger nederst i tagget og hedder Undtagelser. Jeg vil tro at ni ud af ti containere jeg åbner hos nye kunder, har feltet stående helt tomt.

Den klassiske brug er at holde eget personale ude af tallene. En undtagelse på IP-adresse eller på en bestemt cookie fjerner kontorets egne besøg. Hos en webshop med fem ansatte stod personalet for omkring en ottendedel af sessionerne, fordi de tjekkede deres egne produktsider dagligt.

Den anden brug er at undgå dobbelttælling. Har du et tag der fyrer på alle sidevisninger, og et særskilt tag på tak-siden, kan undtagelsen sørge for at den ene ikke tæller med i den anden. Google beskriver opsætningen i deres egen hjælp til Tag Manager, hvis du vil se felterne beskrevet trin for trin.

Hvad er dataLayer, og hvornår har du brug for det?

dataLayer er en liste med data, som dit website sender til Google Tag Manager, før Tag Manager gør noget som helst. I stedet for at Tag Manager skal gætte sig til ordrevaerdien ved at kigge på teksten i en boks på siden, får den tallet leveret direkte fra systemet.

Forskellen lyder teknisk, men den har en meget jordnær konsekvens. Måling bygget på CSS-selectors læser af designet. Måling bygget på dataLayer læser af dataene. Designet ændrer sig hver gang nogen rører ved temaet. Dataene gør ikke.

Jeg har en webshop i Sydjylland, hvor purchase-værdien blev hentet ud af prisfeltet på kvitteringssiden. Det virkede fint i to år. Så skiftede de tema en fredag eftermiddag, og klassen på det felt skiftede navn. Mandag morgen målte Analytics stadig ordrer, men alle sammen til 0 kroner. Ingen fejlbesked, ingen advarsel. Tags fyrede pænt, de fandt bare ikke noget tal og sendte nul af sted.

Det tog tre uger, før nogen opdagede det, fordi antallet af ordrer så helt normalt ud. Kun omsætningen var væk. Tre ugers ROAS-tal i Google Ads var ubrugelige, og budoptimeringen havde kørt videre på dem.

Hvad betyder dataLayer.push, når man ikke er udvikler?

dataLayer.push er den kommando, dit website bruger til at lægge en oplysning i køen, som Tag Manager kan hente. Den ser sådan her ud i al sin enkelhed: websitet skubber en besked af sted med et navn og nogle felter, og Tag Manager står klar og lytter efter netop det navn.

Beskeden har typisk et event-navn, for eksempel purchase, og derefter de data der hører til. Ordrenummer, beløb, valuta. Tag Manager opfanger event-navnet som en trigger, og felterne hentes ind som variabler af typen Data Layer Variable. Derfra kan de sendes videre til GA4, Google Ads eller hvad du nu har brug for.

Du behøver ikke kunne skrive koden selv. Men du skal kunne se, om den er der. Åbn din kvitteringsside, højreklik, vælg Inspicér, gå til fanen Console og skriv dataLayer efterfulgt af Enter. Du får en liste frem. Hvis du kan se et objekt med event purchase og et beløb i, så har du det, du skal bruge. Hvis listen kun indeholder gtm.js og gtm.dom, så har du ingenting, og så skal der en udvikler ind over.

Den test tager halvandet minut og er den eneste tekniske ting, jeg beder mine kunder gøre selv. De fleste bliver overraskede over, hvor meget deres platform allerede sender. Googles egen dokumentation for dataLayer viser opbygningen, hvis du vil give den videre til jeres udvikler.

Hvornår skal du have fat i en udvikler, og hvad kan du klare selv?

Kører du Shopify, WooCommerce eller Magento, har du som regel allerede et dataLayer. Shopify sender ordredata med ud af boksen, og WooCommerce gør det, så snart du installerer et af de gængse GA4-plugins. Der skal du ikke bruge en udvikler. Du skal bare koble Tag Manager på det, der allerede ligger.

Har du et specialbygget website, eller har nogen bygget et tema fra bunden, er det en anden sag. Der skal dataLayer-koden skrives ind på kvitteringssiden manuelt, og det er en opgave på typisk to til fire timer for en udvikler, der har prøvet det før. Det er billigere end tre uger med forkerte tal.

Det du selv kan klare uden hjælp: formularindsendelser, klik på telefonnumre og mailadresser, scroll-dybde, videoafspilninger og sidevisninger af bestemte sider. Alt det kan Tag Manager måle med sine indbyggede triggers uden en eneste linje ny kode på websitet.

Det du ikke skal løse med CSS-selectors: alt hvad der involverer et beløb. Priser, ordreværdier, kurvens indhold. Hver gang jeg har set nogen genveje dér, er det gået galt ved næste designopdatering. Beløb skal komme fra dataLayer, punktum.

Vil du have mere i indbakken?

Du får konkrete erfaringer fra arbejdet med danske virksomheder, skrevet så du kan handle på det. Ingen reklame.

Hvordan tester du at det måler rigtigt?

Du tester i Preview-tilstand før du publicerer. Tag Manager åbner en parallel session af dit website, hvor du kan se præcis hvilke tags der fyrer, hvornår de fyrer, og hvilke værdier de sender med. Derefter sammenholder du tallene i GA4 DebugView og realtidsrapporten med det containeren siger.

Preview-tilstanden hedder Tag Assistant og starter fra knappen Preview oppe i højre hjørne. Du indtaster din adresse, et nyt vindue åbner, og i bunden eller i et separat faneblad kører et debug-panel parallelt med siden. Alt hvad du klikker på i det vindue, bliver logget i panelet.

Det her er den eneste måde at vide om en opsætning virker, inden den rammer rigtige besøgende. Jeg har haft kunder der publicerede direkte og først opdagede fejlen tre uger senere, da tallene i rapporterne så mærkelige ud. Tre uger med ubrugelige data koster mere end de ti minutter en test tager.

Hvad kigger du efter i Tags Fired og Variables?

Debug-panelet har en tidslinje i venstre side med hver hændelse på siden. Klik på en hændelse, og du ser fire faner. De to vigtigste er Tags og Variables.

Under Tags står alle tags delt i to grupper. Tags Fired er dem der blev sendt. Tags Not Fired er dem der ikke blev. Begge lister er interessante. Et tag der mangler i Fired, har en trigger der ikke matcher. Et tag der optræder to gange på samme hændelse, sender dobbelte data, og så er dine konverteringer pustet op med 100 procent.

Klik på selve tag-navnet, og du ser hvilke værdier der blev sendt. Her fanger jeg oftest fejlene. Værdien står som 0, eller valutaen mangler, eller transaction_id er tom. Alt sammen ting der ser fint ud i opsætningen og først viser sig når du ser det rigtige kald.

Fanen Variables viser hvad hver variabel indeholdt lige i det øjeblik. Står der undefined ud for den variabel dit tag bygger på, så er problemet fundet. Enten blev værdien aldrig skubbet i dataLayer, eller også fyrer dit tag før værdien er der.

Hvorfor passer tallene i Ads og GA4 ikke sammen?

GA4 har sin egen debug-visning. Under Admin og DebugView ser du hændelserne komme ind live fra din testsession, med alle parametre udfoldet. Det er her du kontrollerer at GA4 modtog det Tag Manager sendte. Preview viser afsenderen, DebugView viser modtageren, og de to er ikke altid enige.

Realtidsrapporten er det næste skridt. Den viser trafik fra alle besøgende, ikke kun dig, og den er god til at opdage om noget fyrer langt oftere end det burde. Ser du 40 køb på en time på et website der sælger fem ting om dagen, så har du en trigger der rammer for bredt.

Den afvigelse jeg bruger mest tid på, er mellem Google Ads og GA4. Når forskellen er over 10 procent, skyldes det næsten altid en af to ting. Enten samtykke, hvor Ads tæller modellerede konverteringer som GA4 ikke har, eller dobbelttagging, hvor konverteringssporingen både ligger hårdkodet i temaet og som tag i containeren. Jeg havde en webshop i Kolding hvor Ads meldte 214 konverteringer på en måned og GA4 meldte 118. Hele forskellen lå i et konverteringsscript udvikleren havde lagt ind to år tidligere og glemt igen.

Under 10 procent er normalt og skyldes forskellig tilskrivning. Ads tæller konverteringen på klikdagen, GA4 på konverteringsdagen, og de to datoer er sjældent den samme. Den forskel jagter jeg ikke. Vil du have hjælp til at få tallene til at hænge sammen på tværs af systemerne, er det præcis det jeg laver i min rådgivning om data og måling.

Googles egen gennemgang af Preview-tilstanden ligger i Tag Manager Hjælp, hvis du vil have skærmbillederne med.

Otte punkter inden du publicerer

Kør listen igennem hver gang, også når ændringen virker lille. Det tager under ti minutter, og det er den eneste grund til at jeg sjældent får en opringning om at tallene er forsvundet.

Samtykke, Consent Mode og hvad du må måle

Samtykke styres i Tag Manager via Consent Mode og consent-indstillinger på hvert enkelt tag. Siger den besøgende nej til statistik, sender GA4-tagget ikke cookies, men et anonymt signal uden ID. Du mister dermed sporing på de besøgende, og tallene falder typisk mærkbart fra dag et.

Det her er den del af Tag Manager, hvor jeg oftest møder virksomheder der har gjort noget forkert uden at vide det. Ikke af ond vilje, men fordi cookiebanneret blev sat op af én leverandør og målingen af en anden, og ingen af dem tjekkede om de to snakkede sammen.

Resultatet er enten at alt fyrer med det samme uanset hvad folk klikker, eller at intet fyrer overhovedet, fordi nogen blev nervøs og slukkede for det hele. Begge dele koster. Den første koster juridisk, den anden koster indsigt.

Hvad gør Consent Mode v2 ved dine tags?

Consent Mode er Googles måde at lade et tag vide, hvad den besøgende har sagt ja og nej til. Der er to signaler der betyder noget for de fleste: analytics_storage og ad_storage. Det første styrer om GA4 må sætte cookies, det andet om Google Ads må det. I version 2 kom der to mere til, ad_user_data og ad_personalization, som handler om hvad data må bruges til, ikke om de må gemmes.

Før samtykke sættes alle fire til denied. Klikker besøgende accepter, opdateres de til granted, og tags begynder at opføre sig normalt. Siger de nej, fyrer GA4-tagget stadig, men uden cookie og uden bruger-ID. Google kalder det cookieless pings. Du får en registrering af at nogen var der, men ikke hvem, og ikke om det var samme person der kom tilbage i morgen.

Det tekniske setup er to ting. Cookiebanneret skal sende et consent-signal ind i Tag Manager, og det skal ske før alt andet. De fleste danske bannerløsninger har en færdig skabelon i Tag Managers galleri, så du slipper for at bygge det selv. Derudover har hvert tag et felt under avancerede indstillinger, hvor du kan kræve bestemte samtykker før det må fyre.

Et tag der fyrer før samtykke er ikke en skønhedsfejl. Datatilsynet har gentagne gange slået fast, at cookies til statistik og markedsføring kræver aktivt samtykke, og reglerne står beskrevet på Datatilsynets hjemmeside. Jeg plejer at sige til kunder, at det er den eneste del af en Tag Manager-opsætning, hvor en fejl kan ende som et tilsynsbrev og ikke bare som et skævt tal i en rapport.

Hvordan forklarer du et fald på 30 procent til din ledelse?

Du forklarer det ved at vise det gamle tal var forkert, ikke at det nye er dårligt. Hos en kunde i Sydjylland gik vi fra et banner der i realiteten ikke blokerede noget, til en korrekt opsætning. Sessionerne faldt fra cirka 14.000 til 9.800 på en måned. Omsætningen i webshoppen var den samme. Vi havde bare talt 4.200 besøg, vi ikke havde lov til at tælle.

Den samtale tager fem minutter, hvis du forbereder den. Den tager tre måneder, hvis du venter til direktøren selv opdager faldet i en månedsrapport. Jeg laver altid et skærmbillede af tallene ugen før omlægningen og ugen efter, og sender dem sammen med en sætning om hvad der er sket.

Det næste spørgsmål kommer altid: hvad gør vi så ved det? Svaret er at hæve accept-raten og lære at arbejde med modellerede data. Et banner med en tydelig accept-knap og en kort forklaring får i min erfaring 20 til 30 procentpoint flere accepter end et banner med fire ens grå knapper og et juridisk afsnit på 200 ord.

Samtidig bruger Google Ads de anonyme signaler til at modellere konverteringer, så du stadig kan optimere, selv om du ikke har fuld sporing på alle. Det kræver at Consent Mode er sat rigtigt op, ellers modellerer Google ingenting. Jeg gennemgår altid den del, når jeg arbejder med annoncering i Google Ads for en kunde, fordi en forkert samtykkeopsætning æder budoptimeringen indefra uden at nogen opdager det.

Sidste ting: sammenlign aldrig tal på tværs af en samtykkeomlægning uden at skrive datoen ned. Sæt en annotation i GA4 samme dag. Et år senere står du ellers og undrer dig over et fald, ingen kan huske årsagen til.

Skal vi tage en snak?

Tag en uforpligtende snak om hvor du står. Du går fra samtalen med mindst tre konkrete ting du kan gøre.

Ofte stillede spørgsmål

Relaterede artikler