Ecommerce datalayer: de 7 events du skal måle først

Når en webshop siger, at den “måler GA4”, betyder det ofte bare, at sidevisninger og måske et køb bliver registreret. Det er for lidt, hvis målet er at forstå, hvor salget opstår, og hvor det falder fra.

En god ecommerce data layer gør det muligt at sende præcise hændelser til Google Tag Manager og GA4, så du kan følge kundens vej fra produktvisning til betaling. Det giver bedre rapportering, mere stabile annonceringsdata og et langt bedre grundlag for at forbedre konverteringsraten.

Hvad en ecommerce data layer gør i GA4 og Google Tag Manager

En data layer er i praksis et JavaScript-objekt, hvor webshoppen lægger information om brugerens handlinger. Google Tag Manager læser de data og bruger nøglen event til at udløse tags. Det betyder, at du ikke behøver gætte dig frem ud fra klik på knapper eller URL-skift alene. Du kan sende det, der faktisk er sket.

I ecommerce-sammenhæng er det vigtigt, fordi GA4’s anbefalede webshop-events ikke bliver sendt automatisk. Google anbefaler en række faste events til online salg, og det er dem, der fylder rapporterne for ecommerce i GA4. Hvis de ikke ligger korrekt i data layeren, får du enten tomme rapporter eller tal, der ikke kan bruges til noget.

Det afgørende er også strukturen i data. Ecommerce-events bruger både event-level parameters og ofte item-level parameters. Med andre ord: Der er både data om selve handlingen og data om de varer, handlingen handler om.

Efter det kommer selve implementeringen typisk ned til tre dele:

• data layer push fra webshoppen
• trigger i Google Tag Manager
• GA4 event tag med de rigtige parametre

De første 7 GA4 ecommerce-events du bør måle

Hvis du skal starte et sted, så start med de events, der dækker den vigtigste del af købsrejsen. Det er også dem, Google selv anbefaler til online salg.

Event	Hvornår det sendes	Hvorfor det er vigtigt	Vigtige parametre
view_item	Når en bruger ser en produktside	Viser hvilke produkter der får opmærksomhed	currency, value, items
add_to_cart	Når en vare lægges i kurven	Måler reel købsinteresse	currency, value, items
view_cart	Når kurven vises	Giver indblik i brugere tættere på køb	currency, value, items
begin_checkout	Når checkout startes	Viser overgangen fra kurv til betaling	currency, value, items
add_shipping_info	Når leveringsinfo er valgt eller sendt	Viser fremdrift i checkout	currency, value, shipping_tier, items
add_payment_info	Når betalingsinfo er valgt eller sendt	Viser et vigtigt trin lige før køb	currency, value, payment_type, items
purchase	Når ordren er gennemført	Det vigtigste salgs-event	transaction_id, currency, value, tax, shipping, items

Det er fristende at måle alt fra dag ét. Men for de fleste webshops er det mere fornuftigt at få de syv events her helt rigtige først. Når de virker, kan du udvide med remove_from_cart, view_item_list, select_item, refund og kampagneevents senere.

Produkt- og kurv-events i ecommerce data layer

view_item er ofte det første rigtige ecommerce-signal. Det fortæller, hvilke produkter der faktisk bliver set, og det gør det muligt at sammenholde produktinteresse med kurv og køb. Hvis dette event mangler, bliver det svært at se, om problemet ligger i produkttrafikken eller længere nede i flowet.

add_to_cart er næste skridt. Her er det vigtigt, at eventet kun affyres, når varen faktisk er lagt i kurven, ikke bare når brugeren klikker på knappen. Hvis knappen fejler, hvis varianten ikke er valgt, eller hvis produktet er udsolgt, bør eventet ikke sendes.

view_cart bliver nogle gange sprunget over, men det er et nyttigt event. Det hjælper med at måle, hvor mange der aktivt åbner kurven, og det kan bruges til at se forskellen mellem dem, der lægger noget i kurven, og dem, der faktisk går videre.

Checkout-events i GA4: begin_checkout, add_shipping_info og add_payment_info

begin_checkout markerer et vigtigt skifte i brugerens adfærd. Her går personen fra at overveje til at forsøge at købe. I mange shops er forskellen mellem view_cart og begin_checkout en af de mest interessante friktionsmålinger.

add_shipping_info og add_payment_info giver et mere præcist billede af, hvor langt kunden kommer i checkout. Hvis mange starter checkout, men få når leveringsinfo, kan problemet ligge tidligt i flowet. Hvis mange vælger levering, men færre indtaster betaling, er det ofte betalingsdelen, tillid eller teknisk friktion, der bremser.

De tre checkout-events gør det muligt at se frafald trin for trin i stedet for kun at se “kurv” og “køb”. Det er langt lettere at arbejde med i praksis.

Købseventet purchase og hvorfor transaction_id er obligatorisk

purchase er det vigtigste event i hele opsætningen. Det er her, omsætning, antal køb og produkter bliver registreret korrekt i GA4’s ecommerce-rapportering.

Det event skal have en transaction_id. Google anbefaler det, fordi det hjælper med at undgå dubletter. Hvis takkesiden reloades, eller brugeren vender tilbage til ordrebekræftelsen, risikerer du ellers at sende samme ordre flere gange.

Det er også her, mange webshops laver den dyreste fejl: de sender køb uden korrekt ordre-ID, uden varelinjer eller med forkert værdi.
Det er samme mønster, Morinexx beskriver i deres gennemgang af tracking setup for rene konverteringsdata, hvor små fejl i implementeringen hurtigt forplanter sig til både rapportering og annonceplatforme. Resultatet er, at både GA4, annonceringsplatforme og interne rapporter begynder at pege i hver sin retning.

Eksempler på ecommerce data layer-kode til GA4

Det behøver ikke være kompliceret, men strukturen skal være ensartet. Her er et simpelt eksempel på view_item:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "view_item",
  ecommerce: {
    currency: "DKK",
    value: 499.00,
    items: [{
      item_id: "SKU-123",
      item_name: "Sort hættetrøje",
      price: 499.00,
      item_brand: "Eksempelbrand",
      item_category: "Hoodies",
      quantity: 1
    }]
  }
});
</script>

Og her er et typisk purchase-event:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-100245",
    currency: "DKK",
    value: 998.00,
    tax: 199.60,
    shipping: 39.00,
    items: [
      {
        item_id: "SKU-123",
        item_name: "Sort hættetrøje",
        price: 499.00,
        quantity: 2
      }
    ]
  }
});
</script>

Pointen er ikke, at alle shops skal bruge præcis samme felter. Pointen er, at eventnavnet matcher GA4’s anbefalede ecommerce-events, og at de vigtigste parametre følger med hver gang.

Vigtige parametre i ecommerce data layer

Selv de rigtige events giver dårlige data, hvis parametrene er mangelfulde. Især ecommerce-opsætninger fejler ofte på vareniveau, fordi items enten mangler eller er inkonsistent mellem events.

Det er en fordel at aftale en fast struktur tidligt. Hvis et produkt hedder én ting på produktsiden, noget andet i kurven og noget tredje ved køb, bliver analyser hurtigt rodede. Det samme gælder SKU, kategori og pris.

De vigtigste felter at have styr på er typisk disse:

• event: Navnet på handlingen, fx add_to_cart eller purchase
• currency: Valutakode som DKK
• value: Samlet værdi for eventet
• items: En liste over de varer, handlingen gælder
• transaction_id: Unikt ordre-ID ved køb
• quantity: Antal pr. varelinje
• price: Pris pr. vare

På item-niveau er der især nogle felter, der går igen i analyser og feeds til annoncering:

• item_id
• item_name
• item_brand
• item_category
• price
• quantity

Typiske fejl i GA4 ecommerce tracking

Mange problemer starter ikke i GA4, men i selve webshop-logikken. Hvis data layeren bygger på frontend-tekster, DOM-elementer eller midlertidige JavaScript-værdier, bliver målingen sårbar. Det er bedre at hente data direkte fra platformens rigtige produkt- og ordredata, når det er muligt.

En anden klassiker er, at samme event affyres flere steder. Et add_to_cart kan blive sendt både ved klik på knappen og når minicart opdateres. Så stiger tallet kunstigt, og det ser ud som om marketing skaber mere købsintention end den faktisk gør.

Her er fejl, der går igen i mange opsætninger:

• Dobbelt affyring af purchase
• Manglende transaction_id
• value uden momslogik eller med forkert afrunding
• Tomt eller ustabilt items array
• Forskellige item_id på tværs af events
• Events sendt før data er klar i checkout

Hvis du kan nikke genkendende til bare to af dem, er det værd at gennemgå opsætningen grundigt.

Sådan tester du ecommerce-events i GTM og GA4

Test bør være en fast del af implementeringen, ikke noget man gør til sidst. Du skal kunne se, om eventet ligger korrekt i data layeren, om GTM trigger på det rigtige tidspunkt, og om GA4 modtager præcis de parametre, du forventer.

Start med preview mode i Google Tag Manager. Gå derefter gennem et helt købsløb i webshoppen. Kig på hvert data layer push og kontroller, at event, value, currency og items stemmer.

En enkel testproces ser ofte sådan ud:

1. Gennemfør flowet fra produktside til ordrebekræftelse
2. Tjek hvert dataLayer.push() i GTM Preview
3. Bekræft at de relevante GA4-tags affyres én gang
4. Valider events og parametre i GA4 DebugView

Når noget ikke stemmer, er det sjældent nok at “rette i GTM”. Hvis webshoppen sender forkerte data, kan Tag Manager kun viderebringe de samme fejl i pæn indpakning.

Hvornår du bør udvide ud over de første 7 events

Når de syv centrale events virker stabilt, giver det mening at bygge videre. Her er remove_from_cart ofte næste oplagte skridt, fordi det siger noget om tvivl eller prisfølsomhed. view_item_list og select_item er gode, hvis du vil forstå, hvilke kategorisider, lister eller anbefalingsmoduler der faktisk skaber klik videre til produkter.

For shops med aktive kampagner kan view_promotion og select_promotion også være relevante. De kan vise, om en intern bannerplacering faktisk skaber handling, eller bare bliver vist uden effekt.

Det vigtige er rækkefølgen. Først en stabil basis med produktvisning, kurv, checkout og køb. Derefter de mere detaljerede events, som gør analysen skarpere. Den prioritering sparer både udviklingstid og fejlretning, og den giver et datagrundlag, du faktisk kan bruge til at øge salg, ikke bare til at fylde rapporter.