Du kan finne dusinvis av tagger i containeren. Noen utløses to ganger, andre brukes ikke lenger av noen, og en variabel kalt "test2-final" avgjør rapporterte inntekter. Så lenge ingenting endres, måler nettstedet. Ved den første endringen er det imidlertid ingen som ønsker å godkjenne publiseringen.
Den opprinnelige versjonen av denne artikkelen inneholdt 19 konkrete innstillinger for datidens Google Analytics, AdWords, Sklik, Facebook og andre nå nedlagte verktøy. Den var praktisk på sin tid. I dag vil kopiering av gamle tagger skape teknisk gjeld. Viktigere er et system som overlever et nytt grensesnitt og et plattformbytte.
GTM skaper ikke data – det styrer bare veien videre
Google Tag Manager fungerer med tre grunnleggende elementer:
- En tagg sender eller behandler data for en bestemt tjeneste.
- En utløser avgjør ved hvilken hendelse og under hvilke betingelser en tagg aktiveres.
- En variabel leverer en verdi, for eksempel en transaksjons-ID, pris eller sidetype.
GTM vet ikke selv at en ordre er betalt. Nettstedet eller backend-systemet må oppgi denne informasjonen. Hvis kildesignalet er feil, sender en perfekt konfigurert tagg bare feilen raskere til flere systemer.
Datalaget er en avtale mellom nettstedet og markedsføringen
Datalaget er et strukturert lag som nettstedet bruker til å sende hendelser og verdier til tagger. I stedet for å lese prisen fra et bestemt HTML-element sender applikasjonen en hendelse med stabile felt når et kjøp er fullført.
window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'purchase', ecommerce: { transaction_id: 'OBJ-12345', value: 2490, currency: 'CZK', items: [] } });Dette er et forenklet eksempel på prinsippet, ikke en komplett implementering av netthandel. Tilpass den konkrete strukturen til den gjeldende anbefalingen fra målplattformen. Det viktige er at navn, typer og tidspunktet for hendelsen er avklart og kan testes.
Jeg ville ikke basert meg på URL-en til en takkeside eller teksten på en knapp hvis nettstedet kan levere en faktisk forretningshendelse. Tekst og URL-er endres ved redesign. Avtalen for datalaget bør forbli stabil.
Først måleplanen, deretter containeren
For hvert forretningssteg skriver du ned:
- navnet på hendelsen,
- den nøyaktige betingelsen den oppstår under,
- obligatoriske parametere og formatet deres,
- fasiten,
- systemene den kan sendes til,
- påkrevd samtykkestatus,
- eier og testmetode.
For en forespørsel må du skille mellom et innsendt skjema og en kvalifisert lead. For en nettbutikk må du skille mellom start på en ordre og et bekreftet kjøp. Dette hindrer annonseringsalgoritmen i å optimalisere for en enkel, men kommersielt svak handling.
Navnene må fungere på tvers av flere verktøy
Bruk konsekvente hendelsesnavn med små bokstaver og tydelig beskrevne parametere. Når GA4 tilbyr en anbefalt hendelse, som generate_lead, add_to_cart eller purchase, er det fornuftig å følge det offisielle navnet og parameterne. Du får mer kompatible rapporter og mindre behov for oversettelseslag.
Andre plattformer kan kreve sitt eget navn. Gjør oversettelsen bare i taggen. Nettstedet bør sende én forståelig forretningshendelse, ikke fem nesten identiske signaler basert på leverandørens logo.
Samtykke må være en del av arkitekturen
Et cookie-banner og GTM må ikke fungere som to separate verdener. Standardsamtykket må være tilgjengelig før taggene, og det må oppdateres riktig etter brukerens valg. Google beskriver Consent Mode for taggene sine, inkludert grunnleggende og avansert modus.
Consent Mode er ikke et banner eller en juridisk vurdering. Selskapet må innhente samtykke der det kreves, videreformidle statusen og sørge for at alle tagger – også de utenfor Google – respekterer valget. Custom HTML er ingen egnet snarvei for å håndtere samtykke for Google-tagger; bruk støttede mekanismer og maler.
Foretrekk en innebygd mal fremfor et tilfeldig skript
For Google-taggen, Google Ads og andre støttede tjenester bør du bruke en innebygd eller godkjent, pålitelig mal. Reserver Custom HTML for situasjoner som ikke kan løses sikkert på annen måte. Hvert tredjepartsskript tilfører risiko for ytelse, sikkerhet og vedlikehold.
Gå gjennom containeren én gang i kvartalet og fjern tagger for tjenester selskapet ikke lenger bruker. Et inaktivt markedsføringsverktøy bør ikke ha tilgang til besøkende bare fordi det ble glemt.
Testing må kontrollere data, rekkefølge og at taggen ikke utløses
Preview og Tag Assistant viser hvilke tagger som ble utløst, i hvilken rekkefølge og med hvilke data. Det er ikke nok å se statusen Fired. Jeg kontrollerer også:
- om taggen ble utløst nøyaktig én gang,
- om den ikke ble utløst på feil steg,
- verdi, valuta, transaksjons-ID og varer,
- nettverksforespørselen og svaret fra mål-tjenesten,
- statusen i plattformens sanntids- eller testmodus,
- både gitt og avslått samtykke,
- mobil, omdirigeringer, mislykket betaling og gjentatt lasting.
Ved et kjøp sammenligner jeg resultatet med backend-systemet. Når GTM rapporterer én transaksjon og bestillingssystemet en annen, er det ikke Tag Assistant som avgjør regnskapsvirkeligheten.
Publisering krever en versjon og en vei tilbake
Før en endring bør du bruke et separat arbeidsområde hvis flere personer jobber med containeren. Navngi en publisering etter resultatet, ikke "versjon 37", og beskriv hvilke hendelser som er endret. Google Tag Manager lagrer en container-versjon ved publisering, slik at historikken kan spores og den forrige tilstanden gjenopprettes hvis det oppstår en feil.
Tilbakerulling erstatter likevel ikke testing. Hvis nettstedet og datalaget ble endret samtidig, er det ikke sikkert at den gamle containeren fungerer med den nåværende koden. Distribuer versjonene av nettstedet og målingen koordinert.
Tolv punkter for en sunn container
- Det finnes én riktig container på nettstedet, og plasseringen følger installasjonsinstruksjonene.
- Det finnes en måleplan og en eier for hver viktig hendelse.
- Nettstedet sender et stabilt datalag i stedet for sårbar sidelesing.
- Navn og parametere er konsekvente og dokumenterte.
- Personopplysninger sendes ikke til datalaget uten et lovlig og godkjent formål.
- Samtykke er konfigurert før relevante tagger utløses.
- Google- og annonseringstagger bruker støttede maler når slike finnes.
- Hver tagg har en begrenset og forståelig utløser.
- Et kjøp og en lead kan ikke sendes to ganger ved et uhell.
- Testingen omfattet også negative scenarier og avslått samtykke.
- Publiseringen har et navn, en beskrivelse og en kjent vei tilbake.
- Ubrukte tagger, variabler og tilganger fjernes regelmessig.
Hvor GA4, Meta og annonseringssystemene passer inn
GTM er et trafikk-knutepunkt. Google Analytics 4 håndterer betydningen av hendelser og rapporter. Artikkelen om Conversions API forklarer serverruten for hendelser til Meta. Direkte import av kostnader fra Meta til GA4 har et annet formål, som beskrives i veiledningen om å koble Meta Ads sammen med GA4.
Ikke prøv å løse hvert lag med én tagg. Definer først hendelsen, deretter samtykke, overføring og validering – og først til slutt rapporten.
Når GTM ikke er nødvendig
For et svært enkelt nettsted med én støttet analysetagg kan direkte implementering av Google-taggen være tydeligere. GTM gir mening når du trenger flere hendelser, tjenester, betingelser og en kontrollert endringsprosess. Det er ikke et obligatorisk bevis på moden markedsføring.
Hvis containeren din har vokst over flere år og ingen lenger tør å publisere den, ville jeg ikke startet med å legge til enda en tagg. Jeg ville startet med en oversikt og én testbane fra datalaget til rapporten. Du kan beskrive den nåværende situasjonen gjennom kontakt.