Consent Mode v2: avanceret eller basis, og hvad modelleringen kræver

Consent Mode er et API i Google-tagget. Det indhenter ikke samtykke. Det tager imod det valg, brugeren har truffet i jeres banner, og fortæller Googles tags, hvordan de skal opføre sig: om de må sætte cookies, om de må sende brugerdata til annoncering, og om data må bruges til personaliserede annoncer.

Tags fra Google Analytics, Google Ads (konvertering og remarketing), Floodlight og Conversion Linker har indbyggede consent-tjek. Andre tags, fx Metas pixel eller et heatmap-script, har ikke. Dem skal I selv styre med consent-indstillingerne i Tag Manager eller med triggere, ellers fyrer de uanset hvad brugeren har svaret.

Version 2 kom i november 2023 og tilføjede to parametre, ad_user_data og ad_personalization. Google håndhæver dem gennem sin EU user consent policy: har I trafik fra EØS og vil bruge målgrupper, personalisering eller måling fra Google-tags, skal samtykkesignalerne sendes med, enten via Consent Mode eller via IAB's TCF.

Vi skrev vores første gennemgang fra 2021, dengang der kun var to parametre. Påstanden dengang om at kunne måle "helt uden at overskride GDPR" holder ikke i den form, og det kommer vi tilbage til.

Der er syv consent-typer i alt. De fire første er dem, Googles tags reagerer på. De tre sidste bruges primært som betingelser for andre tags i Tag Manager.

De to nye parametre handler ikke om lagring. ad_storage kan være granted, mens ad_personalization er denied. Så må Ads-tagget sætte sine cookies og måle konverteringer, men brugeren må ikke komme på en remarketingliste. Et banner med kategorier skal derfor mappe hver kategori til de rigtige parametre. Den almindelige mapping er, at "marketing" sætter ad_storage, ad_user_data og ad_personalization, og "statistik" sætter analytics_storage. Tjek den i jeres CMP, især om ad_user_data overhovedet bliver opdateret.

To indstillinger ændrer, hvad der sker, når ad_storage eller analytics_storage er denied. Begge sættes med gtag('set', ...) før config, eller i Tag Manager via CMP-skabelonen eller Conversion Linker.

url_passthrough løser et konkret problem. Når nogen lander fra en annonce, ligger klik-id'et (gclid, wbraid, dclid) i URL'en og gemmes normalt i en førstepartscookie. Er ad_storage denied, bliver det ikke gemt, og når brugeren klikker videre til næste side, er id'et væk. Med url_passthrough slået til føjer tagget parametrene til interne links, så de følger med gennem sitet. Det virker kun til links på samme domæne, og kun hvis der er et klik-id i URL'en. Google nævner selv, at I skal tjekke, at jeres redirects bevarer parametrene, at analyseværktøjer ignorerer dem, og at de ikke ødelægger sider, der bruger query-parametre til filtre eller navigation.

ads_data_redaction går den anden vej. Når ad_storage er denied, sender Ads-tags normalt stadig den fulde side-URL med klik-id. Sætter I ads_data_redaction til true, fjernes klik-id'erne fra consent- og konverteringspings, og side-URL'er med klik-id redigeres ud. Indstillingen har ingen effekt, når ad_storage er granted.

De to trækker i hver sin retning: den ene bevarer mere måling, den anden sender mindre. Valget hører hjemme hos den, der ejer jeres privatlivspolitik.

Consent Mode har to kommandoer. default sætter tilstanden, før brugeren har valgt. update ændrer den, når brugeren vælger. Google skriver det ret direkte i dokumentationen: hvis koden kaldes i forkert rækkefølge, virker defaults ikke.

Rækkefølgen på siden skal være sådan her:

1. dataLayer og gtag-funktionen defineres.
2. gtag('consent', 'default', ...) kaldes synkront.
3. Google-tagget eller Tag Manager-containeren indlæses.
4. Banneret indlæses og kalder update, når brugeren vælger, og på hver efterfølgende side ud fra det gemte valg.

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'region': ['DK', 'SE', 'NO', 'DE'],
  'wait_for_update': 500
});
gtag('consent', 'default', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});
gtag('set', 'url_passthrough', true);

Eksemplet sætter denied for de nævnte lande og granted for resten. Regionslisten er kun et eksempel. Skal default være denied i hele EØS, i UK og Schweiz, skal alle landekoder med, og det er en beslutning om jeres samtykkepolitik, ikke om teknik. Når to defaults rammer samme bruger, vinder den mest specifikke region, så en kode som US-CA slår US.

wait_for_update er antal millisekunder, tagget venter på en update, før det sender data. Det er til CMP'er, der indlæses asynkront. Det er ikke en erstatning for at default kommer først, og en stor værdi forsinker al måling for alle.

I Tag Manager gælder tre regler. CMP-skabelonen skal fyre på triggeren Consent Initialization - All Pages, før alt andet. Alle andre tags skal fyre senere, fx på Initialization eller Page View. Og I må ikke kalde gtag('consent', ...) fra et Custom HTML-tag. Google advarer imod det, fordi gtag-kommandoer lægges i kø efter andre beskeder i dataLayer og kan blive behandlet efter det næste event. Skabeloner bruger setDefaultConsentState og updateConsentState, som ikke har det problem.

Google nævner to timing-fejl mere: kør update på den side, hvor brugeren vælger, ikke efter et reload, ellers kan GA4 miste session_start. Og kald den ikke, mens siden forlades, for så kan browseren afbryde kaldet.

Forskellen mellem de to opsætninger er ikke en indstilling i Google. Den afgøres af, om tagget indlæses før brugeren har svaret.

En cookieless ping indeholder ifølge Google tidsstempel, user agent, referrer, boolske værdier om consent-tilstanden, et tilfældigt tal genereret ved hver sidevisning, information om CMP'en (fx Developer ID) og en angivelse af, om den aktuelle eller en tidligere side havde et annonceklik-id i URL'en. GA4-pings sendes ved sideindlæsning og ved hvert event. Som en del af almindelig HTTP-kommunikation følger IP-adressen med. Google oplyser, at Ads og Floodlight kun bruger den til at udlede land, og at GA4 ikke logger IP-adresser.

En detalje, der ofte overses: sætter I selv felter som user_id eller custom dimensions, bliver de ifølge Google sendt normalt, også når analytics_storage er denied. Ligger et kunde-id på hvert event, er pingen ikke cookieless i nogen meningsfuld forstand.

Det her er ikke juridisk rådgivning, og fagfolk er uenige. Men I bør kende argumenterne, før I vælger avanceret.

Googles position er, at pings uden cookies respekterer brugerens valg, fordi der ikke læses eller skrives cookies, og fordi data ikke bruges til at følge den enkelte bruger på tværs af sider eller til remarketing.

Den anden side af sagen står i de europæiske regler. Det danske krav om samtykke kommer fra cookiebekendtgørelsen, som gennemfører ePrivacy-direktivets artikel 5, stk. 3. Datatilsynet og Digitaliseringsstyrelsen skriver i deres fælles vejledning fra maj 2025, at reglerne er teknologineutrale, at de gælder pixels og fingerprinting og ikke kun cookies, og at cookiebekendtgørelsen gælder, uanset hvilke oplysninger der indsamles. EDPB's retningslinjer 2/2023, endeligt vedtaget 7. oktober 2024, går et skridt videre: JavaScript, der instruerer browseren i at sende forespørgsler med de oplysninger, man vil have, er efter EDPB's opfattelse "gaining access" i direktivets forstand, og det samme gælder dynamisk opbyggede tracking-pixels.

Hverken Datatilsynet eller Digitaliseringsstyrelsen har i den fælles vejledning taget specifikt stilling til Consent Mode. Vi kan derfor ikke sige, at avanceret Consent Mode er ulovligt i Danmark, og vi kan heller ikke sige, at det er sikkert. Det, vi kan sige, er:

• Google pålægger jer selv ansvaret. Både Google-dokumentationen og EU user consent policy siger, at det er annoncørens opgave at indhente gyldigt samtykke, hvor det kræves.
• Pings sendt før og efter et nej er en del af det, en tilsynsmyndighed vil kunne se på, og argumentet om at "der ikke sættes cookies" er ikke afgørende efter EDPB's læsning.
• Valget mellem basis og avanceret bør dokumenteres som en bevidst beslutning med en begrundelse, og jeres cookiepolitik bør beskrive, hvad der sendes ved afvisning.

Er jeres risikovillighed lav, eller har I følsomme data, er basis det forsvarlige udgangspunkt.

Den mest udbredte misforståelse om Consent Mode er, at det "genvinder" de tabte data. Det gør det ikke. Det giver Google grundlag for at estimere dem, og kun hvis der er nok data.

GA4's adfærdsmodellering estimerer brugere og sessioner for dem, der har afvist analysecookies. Kravene er ifølge Googles hjælpeside:

• Consent Mode er aktiveret på alle sider, og i den avancerede version, så tags indlæses før banneret og i alle tilfælde.
• Mindst 1.000 events om dagen med analytics_storage denied i mindst 7 dage.
• Mindst 1.000 daglige brugere, der sender events med analytics_storage granted, i mindst 7 af de seneste 28 dage.

Selv når tærsklerne er nået, er det ikke en garanti. Modellen kigger også på forholdet mellem nye og tilbagevendende brugere og på brugere i forhold til sessioner. Modellerede data vises kun, hvis rapporteringsidentiteten står til Blended under Admin, Data display, Reporting identity. Bruger I TCF i stedet for Consent Mode, skriver Google, at GA4 ikke kan modellere data for brugere, der afviser.

En webshop med 300 besøgende om dagen kommer aldrig over tærsklen, så for de fleste mindre danske sites er adfærdsmodellering i GA4 teoretisk.

Modellerede konverteringer i GA4 er noget andet. De estimerer konverteringer, der ikke kan tilskrives direkte, og kan opdateres i op til 12 dage efter, de er registreret. Se derfor ikke på den seneste uge, når I sammenligner kanaler. Er der ikke trafik nok til modellen, havner konverteringerne i kanalen Direct.

Google Ads' konverteringsmodellering kræver, at Consent Mode eller TCF er korrekt implementeret, og at kontoen når Googles tærskel: 700 annonceklik over en periode på 7 dage pr. land og domænegruppering. Derefter følger en træningsperiode. Modellerede konverteringer lægges i kolonnen Konverteringer og bruges af budstrategierne. Med basis bruges en generel model. Med avanceret bruges en model kalibreret på jeres egen konto, og Google skriver, at cookieless pings er afgørende for den kalibrering.

Google oplyser selv, at brugere med samtykke typisk er 2 til 5 gange mere tilbøjelige til at konvertere end brugere uden. En samtykkerate på 50 procent betyder altså ikke, at halvdelen af konverteringerne mangler. Tallet er Googles eget, og vi har ikke uafhængige data, der be- eller afkræfter det.

ad_personalization er den parameter, der rammer målgrupperne. Når den er denied, får remarketing i Google Ads, Display & Video 360 og Search Ads 360 ikke data fra den bruger, og de bruges ikke til personaliserede annoncer.

Det har tre praktiske konsekvenser.

Jeres remarketinglister vokser kun med brugere, der har sagt ja til personalisering. Er listen under minimumsstørrelsen for et netværk, kan den ikke bruges der, og det rammer mindre sites hårdest.

GA4-målgrupper, der deles med Google Ads, er underlagt det samme. Google skriver, at personaliseret annoncering og remarketing kræver bekræftende samtykkesignaler, og GA4 viser under Admin, Consent settings, om ejendommen modtager ad_user_data og ad_personalization for EØS-trafik.

Cookieless pings bliver ifølge Google aldrig brugt til at bygge remarketinglister. Avanceret Consent Mode giver altså ikke flere personer på listerne. Det giver bedre modellering af konverteringer, ikke af målgrupper.

Hviler jeres strategi tungt på remarketing, skal den tåle mindre lister.

Kravet om en Google-certificeret CMP gælder udgivere, ikke annoncører. Bruger I AdSense, Ad Manager eller AdMob til at vise annoncer for brugere i EØS, UK og Schweiz, skal I bruge en certificeret CMP, der er integreret med TCF.

Er I annoncør, der bruger Google Ads og GA4, kræver Google, at I sender samtykkesignaler via Consent Mode eller TCF. Google anbefaler CMP'er fra sit CMP Partner Program, men skriver også, at listen ikke er udtømmende, at annoncører ikke er forpligtet til at bruge en partner, og at en partner-CMP ikke i sig selv garanterer, at I overholder politikken. Det afhænger af opsætningen og af teksten i jeres banner.

I praksis skal CMP'en understøtte alle fire v2-parametre, have en Tag Manager-skabelon, så I undgår Custom HTML, og kunne sætte defaults pr. region. Politikken kræver desuden, at I gemmer dokumentation for samtykker og gør det let at trække dem tilbage.

Start i Tag Assistant: indtast URL'en og gå igennem banneret. Vælg det tidligste Consent-event i oversigten og tjek, at alle fire parametre er sat i API Call. Under Consent-fanen kan I se kolonnerne On-page Default og On-page Update side om side. Vælg derefter det seneste Consent-event og tjek, at update har ændret værdierne. Under Tags kan I se, om hvert tag fyrede eller blev blokeret, og hvilke consent-krav det havde.

Har I region-specifikke defaults, skal I gentage testen med en anden simuleret placering i Chrome. Tester I kun fra Danmark, ser I aldrig, om resten af verden får den default, I tror.

Bagefter skal I ned i netværkskaldene. Filtrér i DevTools på collect for GA4 eller pagead for Ads, og kig på to parametre.

gcs viser ad_storage og analytics_storage som et ciffer hver efter præfikset G1. 0 er denied, 1 er granted.

gcd sendes med i alle kald til Google, også når Consent Mode ikke er implementeret. Google beskriver den som en kodning af alle consent-typer og skriver, at formatet kan ændre sig. Selve bogstaverne er ikke dokumenteret officielt. Den læsning, der bruges i branchen, kommer fra Simo Ahava og andre, der har afkodet den: strengen ser ud som 11p1p1p1p5, hvor de fire bogstaver står for ad_storage, analytics_storage, ad_user_data og ad_personalization i den rækkefølge. Tallene imellem kan variere, så læs bogstaverne.

Det er gcd, der afslører de fleste fejl. Et l betyder, at parameteren aldrig blev sat, typisk fordi CMP'en kører v1. Et m eller n betyder update uden default, altså at default mangler eller kom for sent. Et t på en dansk bruger før valget betyder, at tagget sætter cookies, før nogen har sagt ja. Et r efter accept er det, I vil se.

I Google Ads kan I desuden se Consent Mode-status under konverteringsdiagnostik, og i GA4 under Admin, Consent settings.

De fleste stammer fra, at banner, tema og Tag Manager er sat op af forskellige folk på forskellige tidspunkter.

• Default kommer efter tagget. Default-koden ligger i bunden af siden, eller CMP-skabelonen fyrer på All Pages i stedet for Consent Initialization. Tags når at sætte cookies, før default er sat.
• Hardcodede gtag-kald i temaet. En gammel gtag.js-snippet i headeren fra et Shopify-tema, et WordPress-plugin eller en tidligere udvikler, som kører ved siden af Tag Manager. Den fyrer uden om consent-logikken og giver tit dobbelt måling.
• Update kommer for sent. Banneret gemmer valget og genindlæser siden, i stedet for at kalde update med det samme. Den første side i sessionen bliver målt som denied.
• CMP'en kører stadig v1. ad_storage og analytics_storage sættes, men ad_user_data og ad_personalization står som l i gcd. Konverteringer måles, men remarketing og Enhanced Conversions får ikke signal.
• Global default i stedet for regional. Default er denied for alle i verden, så I mister måling på markeder, hvor der ikke vises et banner. Eller omvendt: default er granted globalt, og EØS er glemt.
• Tredjeparts-tags uden consent-tjek. Meta, TikTok, Hotjar og lignende fyrer på Page View uden betingelse, fordi kun Google-tags har indbygget tjek.
• Datalaget sender id'er ved afvisning. Kunde-id, e-mail eller user_id ligger på hvert event og sendes med i cookieless pings.

Har I flyttet målingen til en server-container, gælder alle de samme regler stadig i browseren, og der kommer et par nye til i containeren. Det gennemgår vi i server-side tracking i praksis.

Vi bruger fire spørgsmål, i den her rækkefølge.

1. Har jeres jurist eller DPO accepteret, at der sendes pings før og efter et nej? Hvis ikke, er svaret basis, og resten er irrelevant.
2. Når I tærsklerne? Under 700 annonceklik om ugen pr. land og et par hundrede besøgende om dagen får I hverken adfærdsmodellering i GA4 eller en kontospecifik model i Ads, der flytter noget mærkbart.
3. Kører I automatisk budgivning på konverteringer, hvor et stort hul i data rammer budene? Så er den annoncør-specifikke model det stærkeste argument for avanceret.
4. Kan I holde opsætningen ren? Avanceret kræver, at default, region og datalag er korrekte på alle sider, hele tiden. En halvt korrekt avanceret opsætning er værre end en korrekt basis.

Uanset valget er der to ting, der giver mere end skiftet mellem basis og avanceret: et banner, hvor afvis og accepter er lige lette at vælge, så de svar I får, er gyldige, og Enhanced Conversions med ad_user_data granted for dem, der siger ja. Begge dele er en del af en almindelig opsætning af tracking og konverteringer.

• Default kaldes synkront, før Google-tag eller Tag Manager indlæses, på alle sider.
• Alle fire v2-parametre har en default og en update.
• Default er regionsstyret, og alle EØS-lande, UK og Schweiz er med, hvis det er jeres politik.
• CMP-skabelonen fyrer på Consent Initialization - All Pages.
• Ingen Custom HTML-tags kalder gtag('consent', ...).
• Der er ingen hardcodet gtag.js i temaet ud over den, I styrer.
• Update kaldes på den side, hvor brugeren vælger, uden reload.
• Ikke-Google-tags har consent-betingelser i Tag Manager.
• url_passthrough eller ads_data_redaction er et bevidst valg, ikke en standardindstilling.
• user_id og andre id'er sendes ikke, når samtykke er afvist.
• Tag Assistant viser korrekt On-page Default og On-page Update, testet fra mindst to regioner.
• gcd viser p før valg og r efter accept for en EØS-bruger, og aldrig l.
• Google Ads konverteringsdiagnostik og GA4 Consent settings viser ingen advarsler.
• Valget mellem basis og avanceret er dokumenteret med begrundelse.

Vil I have en anden til at gå opsætningen igennem, er det en del af det, vi laver under analytics, eller I kan skrive til os.

• Google for Developers: Consent mode overview
• Google for Developers: Set up consent mode on websites
• Google for Developers: Verify and troubleshoot consent mode
• Google Analytics Help: Behavioral modeling for consent mode
• Google Analytics Help: About modeled key events
• Google Analytics Help: Consent mode on websites and mobile apps
• Google Analytics Help: Verify and update consent settings
• Google Analytics Help: Introduction to user consent management
• Google Ads Help: About consent mode modeling
• Google Ads Help: Updates to consent mode for traffic in the EEA
• Google: EU user consent policy
• Google: Help with the EU user consent policy
• EDPB: Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive, version 2
• Datatilsynet og Digitaliseringsstyrelsen: Brug af cookies og lignende teknologier, maj 2025
• Simo Ahava: Consent Mode V2 For Google Tags

Kilderne er tjekket 1. oktober 2026. Google ændrer tærskler og parametre uden varsel, så tjek dokumentationen, hvis noget her ikke længere passer. Artiklen er ikke juridisk rådgivning.