Gå til hovedindhold

Google Ads-konverteringer dubleres ved både browser- og server-side tagging

Hvad betyder dublerede Google Ads-konverteringer?

En dubleret konvertering opstår, når det samme forretningsmæssige udfald, for eksempel et køb eller en indsendt formular, registreres mere end én gang i Google Ads. I praksis ser man ofte, at ét reelt køb bliver talt som to konverteringer, fordi der både sendes en browserbaseret Google Ads-konvertering og en server-side Google Ads-konvertering, uden at Google kan genkende dem som den samme hændelse.

Problemet er ikke kun kosmetisk i rapporterne. Hvis Google Ads modtager dublerede konverteringer, kan automatiske budstrategier optimere efter oppustede signaler. Det kan påvirke evalueringen af kampagner som Search Ads og Performance Max, fordi platformen får et skævt billede af, hvilke klik og søgninger der skaber værdi.

Typiske årsager til dublering

  • Samme konverteringshandling findes i både browser og server som to uafhængige tags
  • Et purchase-event i GA4 importeres som Google Ads-konvertering, samtidig med at et direkte Google Ads-tag også sender købet
  • Manglende eller inkonsistent transaction_id eller order_id mellem forskellige måleveje
  • Takke- eller ordrebekræftelsessiden kan genindlæses, så browser-tagget affyres igen
  • Servercontaineren videresender events til Google Ads uden korrekt kontrol af, om browseren allerede har sendt samme konvertering
  • Flere GTM-containere eller plugins sender samme event parallelt
  • Enhanced Conversions for leads forveksles med en ekstra konvertering, selv om funktionen kun bør berige den samme konvertering
  • Consent Mode eller timeout-problemer skaber forsinkede eller gentagne kald i en fejlbehæftet implementering

Et typisk fejlscenarie

Et almindeligt setup er, at webshoppen sender et purchase-event til datalayeren på takkesiden. Browsercontaineren i GTM bruger dette event til både at sende køb til GA4 og til et Google Ads-konverteringstag. Samtidig sendes det samme purchase-event til en servercontainer, som også videresender købet til Google Ads. Hvis de to veje ikke er designet til at blive deduplikeret, kan Google Ads registrere begge som separate konverteringer.

En anden variant er, at virksomheden importerer køb fra GA4 til Google Ads, men samtidig har beholdt et ældre Google Ads conversion tracking-tag i browseren. Dermed findes der to datakilder til samme køb: den importerede GA4-konvertering og den direkte Google Ads-konvertering. Det er ikke nødvendigvis en teknisk dublet i samme konverteringshandling, men det giver stadig dobbelt optælling i Google Ads-rapporteringen, hvis begge er inkluderet i kolonnen Konverteringer.

Sådan identificerer du, hvor dubleringen sker

Fejlfinding bør starte med at kortlægge hele målekæden fra brugerhandling til rapport. Mange går direkte til Google Ads, men fejlen opstår ofte tidligere i flowet. Lav derfor en systematisk gennemgang af, hvad der sker i browseren, i datalayeren, i GTM web, i GTM server og i de platforme, der modtager data.

  • Bekræft hvor mange gange purchase- eller lead-eventet pushes til datalayeren
  • Kontrollér om både GA4-tag og Google Ads-tag affyres i browseren
  • Kontrollér om servercontaineren også sender samme event til Google Ads
  • Undersøg om GA4-konverteringer importeres til Google Ads parallelt med direkte Google Ads-tracking
  • Sammenlign transaction_id eller lead-id på tværs af browser, server og rapporter
  • Test om takkesiden kan genindlæses eller besøges igen uden nyt køb
  • Gennemgå om plugins, CMS-moduler eller tredjepartsværktøjer også sender køb automatisk

Datalayeren er ofte det første sted at kigge

Hvis samme køb optræder to gange i datalayeren, vil resten af opsætningen sjældent kunne redde datakvaliteten. Derfor bør du kontrollere, om purchase-eventet kun push’es én gang, og om det indeholder en stabil transaction_id. Især på e-commerce-sites er transaction_id central, fordi den bruges til at skelne ét køb fra et andet.

dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'ORDER-12345',
    value: 1299.00,
    currency: 'DKK',
    items: [
      {
        item_id: 'SKU-1001',
        item_name: 'Produkt A',
        price: 1299.00,
        quantity: 1
      }
    ]
  }
});

Hvis transaction_id mangler, ændrer format mellem systemer eller genereres forskelligt i browser og server, bliver det væsentligt sværere at afvise dubletter og lave pålidelig afstemning mod backend-ordrer.

Skeln mellem tre forskellige konverteringsveje

I praksis bør du altid skelne mellem mindst tre måder, Google Ads kan få konverteringsdata på. For det første direkte Google Ads conversion tracking fra browseren. For det andet Google Ads-data sendt via server-side tagging. For det tredje importerede konverteringer fra GA4. Mange dubletproblemer skyldes ikke én fejl, men at to eller tre af disse veje er aktive samtidig for det samme forretningsmål.

  • Direkte browser-tagging: hurtigt at validere, men følsomt over for browserbegrænsninger og sidegenindlæsning
  • Server-side tagging: giver mere kontrol over routing og databehandling, men kræver stram styring af eventidentitet
  • GA4-import til Google Ads: nyttig til analyse og visse konverteringsflows, men kan skabe overlap med direkte Ads-tags

Praktisk regel: vælg en primær kilde pr. konverteringstype

En robust opsætning bygger ofte på princippet om én primær metode til indrapportering af hver konverteringstype til Google Ads. Hvis køb spores direkte til Google Ads via browser eller server, bør samme køb normalt ikke også tælle som en separat GA4-importeret Ads-konvertering. Tilsvarende bør et lead ikke både oprettes via et gammelt hardcoded script, et GTM-tag og en offlineimport, medmindre de har klart adskilte formål og ikke alle er inkluderet i optimeringen.

Hvordan server-side tagging kan udløse dubletter

Server-side tracking reducerer ikke automatisk dubletter. Det flytter blot en del af logikken fra browseren til servercontaineren. Hvis browseren stadig sender direkte til Google Ads, og serveren også sender videre til Google Ads, har du to afsendere. Uden en bevidst strategi for deduplikering er dubletter derfor et forventeligt udfald og ikke en undtagelse.

Derudover kan servercontainere modtage events fra flere kilder, for eksempel GA4-klienter, Measurement Protocol eller backend-kald. Hvis samme ordre kommer ind både fra browserens GA4-request og et separat backend-kald, kan servercontaineren selv skabe dobbelt videresendelse til Google Ads.

Løsningsmodeller

1. Fjern overlap mellem målekilder

Den mest enkle løsning er ofte at reducere antallet af aktive måleveje. Hvis du bruger Google Ads-konverteringstag i browseren for køb, så undgå samtidig at sende samme køb til Google Ads fra serveren, medmindre implementeringen er dokumenteret til at fungere som samme konvertering og ikke som to separate. Hvis du importerer køb fra GA4 til Google Ads, så revurder om et direkte Ads-købtag stadig skal være aktivt.

2. Brug stabile id’er til afstemning

For e-commerce bør transaction_id være konsekvent på tværs af webshop, datalayer, GA4 og eventuelle serverkald. For leads kan et internt lead-id eller CRM-id være nødvendigt. Det gør det muligt at opdage dubletter i test og ved løbende datakontrol.

3. Begræns affyring på takkesiden

Konverteringstags bør kun affyres, når et ægte køb eller lead er bekræftet. Hvis takkesiden kan genbesøges, bør der indbygges logik, som forhindrer gentagen affyring, for eksempel via backend-markering, sessionkontrol eller kontrol af om den konkrete transaction_id allerede er brugt i browseren. Browserbaserede spærrer alene er dog ikke altid tilstrækkelige.

4. Gennemgå inkluderede konverteringer i Google Ads

Nogle konti har flere konverteringshandlinger, hvor kun én burde bruges til budoptimering. Selvom du bevidst måler samme hændelse i flere systemer til analyseformål, bør du være varsom med at inkludere alle i kolonnen Konverteringer. Ellers kan kampagner optimere efter overlappende signaler.

Enhanced Conversions er ikke en ekstra konvertering

Enhanced Conversions bliver nogle gange fejlagtigt mistænkt for at skabe dubletter. Funktionen er dog tænkt som et supplement til en eksisterende Google Ads-konvertering, hvor førstepartsdata som e-mail kan bruges til bedre matchning. Den bør ikke opsættes som en separat konverteringshandling for samme hændelse. Hvis der opstår dobbeltregistrering i et setup med Enhanced Conversions, skyldes det ofte overlap mellem tags eller konverteringskilder snarere end funktionen i sig selv.

Consent Mode kan komplicere fejlsøgningen

Consent Mode ændrer, hvilke signaler der kan sendes, og hvornår de sendes. Det kan gøre fejlsøgning vanskeligere, fordi konverteringsforløb kan se forskellige ud afhængigt af samtykkestatus. En fejlbehæftet consent-implementering kan også få tags til at affyre under uventede betingelser. Derfor bør du teste både med og uden samtykke og kontrollere rækkefølgen mellem consent-signaler, datalayer-events og tag-affyring.

En praktisk tjekliste til fejlfinding

  • Lav et testkøb og noter præcis transaction_id
  • Bekræft at purchase kun forekommer én gang i datalayeren
  • Kontrollér i GTM preview hvilke tags der affyres på purchase
  • Undersøg om både webcontainer og servercontainer sender til Google Ads
  • Kontrollér om GA4-purchase importeres som separat Ads-konvertering
  • Sammenlign antal køb i backend med antal Google Ads-konverteringer over samme periode
  • Tjek om gamle plugins eller hardcoded scripts stadig er aktive
  • Test genindlæsning af takkesiden og direkte adgang til ordre-URL’en

Forretningsmæssige konsekvenser af dublerede konverteringer

Når Google Ads-konverteringer dubleres, bliver problemet ofte undervurderet som en ren trackingfejl. I virkeligheden kan det påvirke budgetprioritering, evaluering af kampagnetyper og dialogen mellem marketing og ledelse. Hvis annonceplatformen viser markant bedre performance end virksomhedens ordre- eller CRM-data, svækkes tilliden til målingen. Derfor bør den tekniske løsning altid suppleres med løbende afstemning mod faktiske forretningsdata.

Konklusion

Dublede Google Ads-konverteringer efter både browser- og server-side tagging skyldes som regel overlap mellem målekilder, ikke at server-side tracking i sig selv er forkert. Den mest effektive vej til en stabil opsætning er at kortlægge hele event-flowet, vælge en primær konverteringskilde pr. forretningsmål, bruge stabile id’er som transaction_id og teste systematisk i både browser og server. Målet er ikke flest mulige registrerede konverteringer, men den mest pålidelige måling af reelle resultater.

Kategorier

Denne side er skrevet af

Simon B. H. Christensen
Tlf: 6168 3536