Test købssporing i GTM og GA4: trin for trin

Et køb i Google Analytics 4 er et purchase-event, som kundens browser sender, når købet er gennemført. Det er ikke ordren selv. Derfor kan tallet i GA4 være rigtigt opsat og alligevel afvige fra webshoppens ordreliste. Testen skal vise to ting: at hver gennemført testordre giver ét korrekt event, og at I forstår, hvorfor de to tal ikke bliver ens.

Guiden tager udgangspunkt i en webshop, hvor Google Tag Manager (GTM) er installeret på siderne som normalt, og hvor købet sendes til GA4 via datalaget. Den bygger på Googles dokumentation for e-handelsevents, GTM Preview og DebugView samt Shopifys vejledning om custom pixels, kontrolleret 26. september 2026. Kilderne står nederst i guiden. Kører jeres sporing på en anden måde, fx som custom pixel i Shopify, gælder principperne stadig, men fejlsøgningen er anderledes. Det beskrives i trin 3.

Før du tester

Få styr på fire ting, før den første testordre lægges:

1. Adgang. Du skal kunne starte Preview i GTM-containeren og se DebugView i GA4-ejendommen. Du behøver ikke publicere ændringer for at teste dem i Preview.
2. Testbetaling. Brug betalingsudbyderens testtilstand eller et testmiljø, hvis butikken har et. Notér ordrenummer og tidspunkt for hver testordre, så de kan genfindes i både ordresystem og GA4.
3. Samtykke. Accepter statistikcookies i testbrowseren. Bruger butikken consent mode, og har du afvist Analytics-cookies, vises dine events ikke i DebugView. Slå også browserudvidelser fra, der blokerer tracking.
4. Rapportdata. Beslut, hvor testordrerne skal ende. Den sikreste løsning er at sende testmiljøets data til en separat GA4-testejendom, hvis I har mulighed for det. Tester du i den rigtige ejendom, så læs trin 7 først.

1. Skriv det forventede purchase-event ned

Du kan ikke vurdere et testresultat uden et facit. Læg en testordre i kurven, og skriv ned, hvad GA4 bør modtage. Googles reference for purchase beskriver felterne sådan:

Et opdigtet eksempel: Kunden køber 2 stk. af en vare til 200 kr. og 1 stk. af en vare til 100 kr., begge priser uden moms. Fragten er 39 kr. uden moms. I eksemplet antager vi 25 % moms på både varer og fragt. Efter Googles definition er value 500 og currency DKK. Fragten sendes som shipping (39). tax er den samlede moms på transaktionen, altså moms af både varer og fragt: 25 % af 539 kr. = 134,75. Kunden betaler i alt 673,75 kr.

Følger jeres opsætning en anden beløbsdefinition, så skriv det ned. Det afgørende er, at alle ved, hvad tallet i GA4 betyder, når det sammenlignes med økonomitallene. Uden en beslutning kommer fejlsøgningen til at handle om definitioner i stedet for fejl.

2. Følg købet i GTM Preview

Start Preview fra GTM med butikkens adresse. Preview åbner butikken i din browser forbundet til Tag Assistant, som viser, hvilke tags der udløses, hvornår og med hvilke data. Kun din browser og dem, du deler forbindelsen med, ser testversionen. Almindelige besøgende påvirkes ikke.

Gennemfør testordren helt til kvitteringssiden. Kontrollér derefter:

1. Eventet kommer én gang. Der skal være præcis ét purchase i eventlisten for ordren.
2. GA4-tagget udløses på det event. Tagget skal være sat op til at sende e-handelsdata fra datalaget, som Googles GTM-vejledning beskriver, og det skal udløses én gang.
3. Data matcher facit fra trin 1. Sammenlign transaction_id, value, currency og hver vare i items.
4. Ingen gamle varer hænger ved. Googles eksempler rydder det forrige e-handelsobjekt i datalaget, før et nyt sendes. Ser du varer fra produktsiden eller kurven i købet, mangler den oprydning.
5. Kun én installation sender købet. Google fraråder at bruge både gtag.js og GTM til de samme events, fordi det giver dobbelttælling. Tjek, om et tema, en app eller et plugin også sender purchase direkte.

Hvis siden opfører sig forkert, når Preview er slået til, kan det skyldes den debugparameter, Preview føjer til adressen. Google beskriver, at signalet kan slås fra i Tag Assistant, før du forbinder.

3. Hvis GTM kører som custom pixel i Shopify

I Shopify kan GTM køre via en custom pixel. Så afvikles den i Shopifys sandkasse med de samme begrænsninger som andre pixels, og datalaget fungerer ikke som på en almindelig side. Shopify skriver selv, at custom pixels ikke understøttes af Shopify, og at du er ansvarlig for blandt andet samtykke, sikkerhed og fejlsøgning.

Fejlsøgningen følger derfor Shopifys anvisninger:

• Brug Shopify Pixel Helper til at kontrollere, at dine events når frem til sandkassen uden fejl. Pixel Helper er Shopifys værktøj og slår ikke GA4’s debugtilstand til.
• Regn ikke med Tag Assistants fejlsøgning af tags. Shopify oplyser, at den ikke virker på custom pixels og ikke kan se tags, der indlæses af GTM inde i pixelen.

Shopifys vejledning nævner hverken GTM Preview eller DebugView. Når Preview ikke kan forbinde, slås debugtilstand ikke til automatisk, og købet dukker derfor ikke op i DebugView. Google beskriver, at debugtilstand kan slås til ved at give GA4-event-tagget parameteren debug_mode med værdien true. Gør det kun i en isoleret testopsætning:

1. Isolér testen. Brug fx en testbutik med sin egen custom pixel, sin egen GTM-container og en GA4-testejendom. Kan I ikke isolere, så læg ikke debug_mode ind i den container, butikkens rigtige besøgende indlæser.
2. Slå debug til i testopsætningen. Tilføj debug_mode med værdien true på GA4-event-tagget for købet, og kontrollér eventet i DebugView som i trin 4.
3. Fjern feltet bagefter. Ifølge Google slår værdien false ikke debugtilstanden fra, så feltet skal fjernes helt.

Publicér aldrig debug_mode på købstagget til alle besøgende. Så bliver alle besøgendes køb debugevents, og et aktivt filter for udviklertrafik vil fjerne disse køb permanent fra rapporterne. Sættes feltet på Google-tagget, gælder debugtilstanden alle events fra det tag.

Kan testen ikke isoleres, kan Pixel Helper og GA4’s Realtime-rapport vise, at købet når frem. Det er en begrænset kontrol og ikke en fuld gennemgang af parametre og varer. Testordrer, der sendes uden debugtilstand, lander i de almindelige rapporter, så notér dem. Se trin 7.

Shopifys eksempelkode sender også kundeoplysninger som mail, telefon og adresse videre til datalaget. De felter må ikke ende i GA4. Se trin 7.

4. Bekræft modtagelsen i GA4 DebugView

Når du tester via GTM Preview eller Tag Assistant, sættes debugtilstand automatisk, og dine events vises i DebugView i GA4. Ved Shopify custom pixels gælder det kun, hvis debugtilstand er slået til i en isoleret testopsætning som i trin 3. Find din enhed, og klik på purchase-eventet.

1. Parametre: Kontrollér transaction_id, value og currency mod facit.
2. Varer: Når der er sendt et items-array, viser DebugView varerne på en separat fane. Kontrollér ID eller navn, pris og antal.
3. Tidsvindue: DebugView viser kun de seneste 30 minutter. Test med det samme, eller gentag med en ny ordre.

Sådan tolker du de mest almindelige resultater:

• Eventet vises i Preview, men ikke i DebugView: Kontrollér samtykke i testbrowseren, blokerende udvidelser og om tagget sender til den rigtige GA4-ejendom.
• Eventet vises, men mangler et krævet felt: GA4 registrerer det, men behandler det som et almindeligt brugerdefineret event og ikke som et e-handelskøb. Det tæller derfor ikke med i e-handelsrapporterne.
• Beløbet er forkert: Sammenlign med beløbsdefinitionen fra trin 1, før du ændrer koden.

5. Test genindlæsning og gentagne ordrer

Dobbelte køb opstår sjældent i den første test. De opstår, når kunden gør noget andet end forventet. Test derfor:

1. Genindlæs kvitteringssiden. Der må ikke komme et nyt purchase i Preview.
2. Gå tilbage og frem i browseren, og åbn kvitteringssiden igen, hvis butikken har et link til den.
3. Læg to forskellige testordrer. De skal have to forskellige transaction_id, og hver ordre skal beholde sit eget ID ved genindlæsning.

GA4 frasorterer køb med samme transaction_id for data fra webstreams og beholder det første. Men et dobbelt event skal stadig rettes. Beskyttelsen gælder kun GA4’s webstreams, og andre tags på samme trigger har ikke nødvendigvis samme beskyttelse. Omvendt gælder: Sendes samme ID for forskellige ordrer, eller sendes et tomt ID, bliver ordrerne slået sammen, og GA4 viser for få køb.

Læg en ny testordre for hver testrunde. Fordi GA4 kun beholder det første køb med et givet ID, dukker en gentaget test med samme ordre ikke op igen i rapporterne. Det er ikke en fejl, og løsningen er aldrig at ændre eller fjerne ID’et i den rigtige opsætning.

6. Sammenlign med ordresystemet efter behandlingstiden

DebugView viser, at eventet kom frem. Det viser ikke, hvordan rapporterne ender. Ifølge Google opdaterer Realtime typisk inden for få minutter. Den fulde behandling kan tage 24–48 timer, og noget data kan komme op til 7 dage for sent. Tildelingen af kilde til et køb kan ændre sig i op til 12 dage.

Sammenlign derfor først en afsluttet periode, fx en hel uge, når behandlingstiden er gået:

1. Antal gennemførte ordrer i ordresystemet mod antal køb i GA4.
2. Omsætning i ordresystemet efter samme beløbsdefinition som i trin 1, altså fx uden moms og fragt.
3. Ordrer, der ikke går gennem kundens browser, fx telefonordrer eller ordrer oprettet af kundeservice. De skal trækkes fra, før tallene sammenlignes.

Nogle forskelle er forventelige. Med consent mode i basistilstand indlæses tags ikke, før kunden har givet samtykke, og uden samtykke sendes der ingen data til Google. I avanceret tilstand sendes der cookieløse signaler, som Google kan bruge til modellering. Sidder triggeren på kvitteringssiden, tæller en kunde, der betaler men aldrig når frem til siden, heller ikke med. Klientside-sporing fanger derfor ikke alle ordrer.

Hold øje med udviklingen over tid frem for et enkelt tal. En forskel, der pludselig ændrer sig, er et tegn på en fejl. En stabil forskel kan skyldes samtykke og blokering.

7. Hold testdata og persondata ude

Testdata. DebugView frasorterer ikke testordrer fra rapporterne. Har I ikke en separat testejendom, kan Googles filter for udviklertrafik udelukke events sendt i debugtilstand. Start filteret i tilstanden Testing, hvor data kun markeres. Kontrollér markeringen i en udforskning, før du aktiverer filteret. Google oplyser, at et filter kan tage 24–36 timer om at slå igennem, og at data, der udelukkes af et aktivt filter, aldrig behandles og ikke kan hentes igen. Filteret rammer kun events sendt i debugtilstand. En testordre lagt uden debugtilstand, fx en Shopify-test kontrolleret med Pixel Helper, lander stadig i rapporterne, så notér den.

Persondata. Googles politik er, at der ikke må sendes oplysninger til Analytics, som kan identificere en person, fx navn, mailadresse eller telefonnummer. Kontrollér i DebugView, at:

• transaction_id er et ordrenummer uden kundeoplysninger.
• Kvitteringssidens adresse og sidetitel ikke indeholder mail eller navn.
• Ingen event-parametre eller brugerdefinerede felter indeholder kundedata, heller ikke hvis platformen stiller dem til rådighed.

8. Refunderinger, annulleringer og fejlede betalinger

GA4 har et refund-event, som sendes med det oprindelige transaction_id. Google anbefaler at medsende varerne, hvis refunderingen skal kunne ses på vareniveau. Refunderinger laves typisk i administrationen og ikke i kundens browser. Derfor kræver de som regel en integration eller en løsning på serversiden. Googles Measurement Protocol er beregnet til at supplere den almindelige tagging, ikke til at erstatte den.

Googles dokumentation beskriver ikke, hvordan annullerede eller afviste betalinger skal håndteres. Det er en forretningsbeslutning. Aftal, hvornår en ordre tæller som et køb, fx når betalingen er godkendt, og placér triggeren efter det. Test derefter det forventede resultat:

1. Afvis en betaling i betalingsudbyderens testtilstand. Forventet: intet purchase.
2. Afbryd betalingen og gå tilbage til butikken. Forventet: intet purchase.
3. Refundér en testordre, hvis refunderinger sendes til GA4. Forventet: ét refund med det oprindelige ID.

Kort tjekliste

1. Facit for transaction_id, value, currency, items, tax og shipping er skrevet ned.
2. Ét purchase pr. ordre i Preview, eller i Pixel Helper ved Shopify custom pixels.
3. Samme data i DebugView, inklusive varefanen. Ved Shopify custom pixels kun via en isoleret testopsætning med debug_mode, som er fjernet igen bagefter.
4. Intet nyt køb ved genindlæsning, og to ordrer giver to ID’er.
5. Afviste og afbrudte betalinger giver intet køb.
6. Ingen persondata i ID, adresse, titel eller parametre.
7. Testordrer er holdt ude af rapporterne eller noteret.
8. Ordresystem og GA4 er sammenlignet for en afsluttet periode efter behandlingstiden.

Baggrunden for de enkelte værktøjer finder du i ordbogen under Google Tag Manager, GA4, datalaget og konverteringssporing. Overvejer I at flytte dele af sporingen væk fra browseren, så læs om server-side tracking.

Vil du have et blik udefra på den offentlige del af webshoppen, kan du bestille en gratis webshop-audit. Den tager udgangspunkt i det, alle kan se i butikken, og kræver ikke login. Den omfatter derfor ikke en gennemgang af jeres GTM-container, GA4-ejendom eller ordredata.

Kilder

• Google: Reference for anbefalede events, bl.a. purchase og refund og validering af e-handelsdata.
• Google: E-handel med Google Tag Manager og Preview i Tag Manager.
• Google: DebugView og debugtilstand og filter for udviklertrafik.
• Google: Deduplikering af transaktions-ID og dataaktualitet.
• Google: Consent mode, persondata i Analytics og Measurement Protocol.
• Shopify: Custom pixel med Google Tag Manager.

Kilderne er kontrolleret 26. september 2026.