Google Consent Mode: Fra samtykkebanner til testet signal

Google Consent Mode forbinder brugerens samtykkevalg med den måde, Google-tags opfører sig på. Det er ikke et samtykkebanner og heller ikke dokumentation for, at jeres opsætning er lovlig. Se det som et teknisk signallag, der skal passe til både banner, tags og måling. Start med sammenhængen mellem trafik og henvendelser.

Google Consent Mode er et signallag – ikke selve samtykket

Google beskriver Consent Mode som en mekanisme, der lader websites og apps justere Google-tags og SDK'er efter brugerens valg om lagring og brug af data. Banneret indhenter valget. Consent Mode oversætter valget til tekniske tilstande. Tags reagerer derefter på de tilstande, de er bygget til at forstå.

Det er nyttigt at holde fire ansvar adskilt:

• Banneret præsenterer valgmuligheder og registrerer brugerens handling
• Consent Mode sender tilstanden som granted eller denied
• Google-tags ændrer lagring, dataoverførsel og funktion efter signalet
• Virksomheden dokumenterer formål, hjemmel, leverandører og kontrol

Den danske fællesvejledning fra Digitaliseringsstyrelsen og Datatilsynet beskriver kravene til cookies og lignende teknologier. Google bestemmer derimod, hvordan Googles egne tags reagerer på et signal. En korrekt parameter kan derfor ikke i sig selv vise, om bannerets tekst, kategorier eller valg er tilstrækkelige. Den juridiske vurdering og den tekniske implementering skal mødes, men de er ikke den samme opgave.

Det skel beskytter også beslutningen mod to modsatrettede fejl. Nogle installerer et banner og antager, at alle tags nu respekterer valget. Andre blokerer alt uden at undersøge, hvilken måling virksomheden faktisk har brug for. Begynd med formål og brugerens reelle valg, og kontrollér derefter den konkrete tagadfærd.

Consent Mode reparerer ikke et uklart banner

Hvis afvisning er sværere end accept, formålene er uklare, eller et tidligere valg ikke kan ændres, løser et korrekt denied-signal ikke brugeroplevelsen. Den fælles danske vejledning lægger vægt på et frivilligt, specifikt, informeret og utvetydigt samtykke, før ikke-nødvendige teknologier anvendes. Brug derfor ikke Consent Mode som juridisk mærkat. Få først valget og formålene vurderet, og brug derefter teknikken til at håndhæve den besluttede adfærd.

Fire signaler styrer de vigtigste Google-formål

Consent Mode v2 tilføjede ad_user_data og ad_personalization til de allerede anvendte signaler ad_storage og analytics_storage. De fire værdier beskriver forskellige formål. De bør derfor ikke automatisk ændres samlet, hvis banneret giver brugeren mere detaljerede valg mellem analyse, annoncering og personalisering.

De centrale signaler dækker følgende områder:

• analytics_storage styrer lagring relateret til analyse, eksempelvis analysecookies
• ad_storage styrer lagring relateret til annoncering
• ad_user_data angiver samtykke til at sende brugerdata til Google til onlineannoncering
• ad_personalization angiver samtykke til personaliseret annoncering

Google opdaterede Consent Mode i november 2023 med de to sidstnævnte signaler. Derfor er det ikke nok at finde en gammel container, hvor kun analytics_storage og ad_storage skifter. Kontroller alle fire signaler og deres forbindelse til bannerets kategorier. Et grønt ikon i en CMP er ikke bevis på, at den publicerede container sender de rigtige tilstande.

Skriv en enkel mapping mellem brugerens ord og systemets parametre. Hvis banneret eksempelvis skelner mellem statistik og marketing, skal teamet kunne forklare, hvilke signaler hver kategori påvirker, hvilke tags der lytter, og hvad der sker ved både accept, afvisning og ændring. Uden den mapping bliver fejlsøgning afhængig af leverandørnavne og hukommelse.

Ét valg kan påvirke flere tekniske kontroller

Et markedsføringsvalg kan berøre lagring, afsendelse af brugerdata og personalisering samtidig. Det betyder ikke, at de tre signaler er ens. De udtrykker forskellige formål, og Google-tags har indbyggede kontroller for bestemte typer. Tredjepartstags har ikke nødvendigvis samme adfærd. Dokumentér derfor både Consent Mode-signalet og eventuelle ekstra udløserregler i Tag Manager. Ellers kan Googles tag reagere korrekt, mens et andet script fortsætter uændret.

Basic og advanced løser forskellige målevalg

Google beskriver to implementeringsmodeller. I basic Consent Mode blokeres Google-tags indtil brugerens handling, og der sendes ikke data til Google før samtykke. I advanced indlæses tags med standardtilstanden denied; uden samtykke kan de sende målinger uden cookies, som blandt andet kan bruges til modellering.

Forskellen skal vurderes åbent før implementering:

• Basic begrænser dataoverførsel før samtykke mest direkte
• Advanced giver Google flere signaler til annoncørspecifik modellering
• Begge kræver et reelt banner eller en anden samtykkeløsning
• Begge kræver korrekte defaults, updates og test på de relevante sider

Advanced er ikke automatisk det rigtige valg, fordi rapporterne kan blive mere komplette. Det indebærer dataoverførsel uden cookies, mens samtykket er afvist. Virksomheden skal vurdere, om implementeringen passer til dens politikker, leverandøraftaler og gældende krav. Google anbefaler selv, at organisationens retningslinjer afgør valg af model og standardtilstande.

Basic er heller ikke bare en knap med mindre risiko. Hvis tagget blokeres helt, skal det efter accept kunne indlæses, modtage tilstanden og registrere de efterfølgende hændelser korrekt. En løsning kan respektere afvisning og stadig have ødelagt måling efter accept. Derfor skal begge grene testes som funktionelle brugerrejser.

Modellering kræver volumen og løser ikke alt

Google offentliggør forskellige krav til modellering i sine produkter. GA4's eksterne forudsætninger omfatter blandt andet mindst 1.000 daglige events med analytics_storage='denied' i mindst syv dage; Google Ads bruger egne kvalitets- og volumengrenser og dokumenterer dem separat. Mindre websites kan derfor implementere korrekt uden at blive kvalificeret. Planlæg beslutningen efter samtykke og datakvalitet – ikke et løfte om automatisk genskabte tal.

Implementeringen begynder med rækkefølgen på siden

Consent Mode fejler ofte i timing frem for i stavning. Standardtilstanden skal sættes, før tags eller anden kode bruger samtykket, og ændringen skal sendes, når brugeren handler. Google understreger, at opdateringen skal registreres på samme side før en eventuel navigation, så efterfølgende events får den valgte tilstand.

Brug en fast implementeringsrækkefølge:

• Kortlæg bannerets kategorier til de fire relevante signaler
• Sæt standardtilstande før måle- og annoncetags kan køre
• Send en update ved accept, afvisning og senere ændring
• Gem valget, så næste sideindlæsning får en konsistent tilstand
• Kontrollér Google-tags og tredjepartstags hver for sig

I gtag.js skal default-kommandoen ligge før kommandoer, der sender måledata. I Google Tag Manager anbefaler Google de særlige consent-API'er og en template frem for et tilfældigt Custom HTML-tag. Det skyldes eksekveringsrækkefølgen: en tilsyneladende korrekt update kan komme efter den event, den skulle have styret.

Hvis CMP'en indlæses asynkront, kan wait_for_update give den et kort vindue til at levere valget, før data sendes. Værdien er ikke en universel opskrift. En lang ventetid kan forsinke måling, mens en kort ventetid kan udløbe før banneret er klar. Mål den faktiske indlæsning og test langsomme forbindelser frem for at kopiere et tal fra et kodeeksempel.

Lav også en tydelig vej til at ændre valget. Google beskriver, at en update kan gå fra både denied til granted og tilbage igen. Hvis hjemmesiden kun håndterer første accept, er implementeringen ufuldstændig. Test tilbagekaldelse uden gemt session, med eksisterende samtykke og på næste sidevisning.

Test hele kæden fra valg til tagadfærd

En kontrol skal vise mere end, at banneret åbner. Den skal følge valget gennem signal, tag og netværksadfærd. Google Tag Assistant kan vise den tidligste consent-event, den seneste update og hvilke tags der blev udløst eller blokeret. Gentag testen for afvisning, accept og ændrede præferencer.

Gem mindst disse beviser fra produktionen:

• De fire defaults før andre relevante tags kører
• Den seneste update efter hvert muligt brugervalg
• Taggenes faktiske udløsning eller blokering i hver tilstand
• Netværkskald og cookies før og efter valget
• Samme resultat på centrale skabeloner, enheder og navigationer

Tag Assistant kan advare om manglende defaults, defaults sat for sent og tilstande, der ikke opdateres. Brug advarslen som indgang til mekanismen. Hvis et tag allerede har skrevet en cookie, før denied sættes, er en senere korrekt status ikke nok. Flyt initialiseringen og test på ny fra en ren browsersession.

Gå derefter uden for Google-værktøjet. Kontroller browserens storage og netværk, fordi CMP, hjemmesidens kode og tredjepartsscripts kan skabe adfærd, som Consent Mode ikke styrer. Gennemfør også den forretningskritiske handling: formular, booking eller køb. En teknisk ren forside er ikke tilstrækkelig, hvis samtykket nulstilles i checkout eller tracking forsvinder ved navigation. En SEO-analyse med observation, årsag og prioritet giver en nyttig struktur til dokumentationen.

Test både afvisning, accept og tilbagekaldelse

Start hver gren i en ren session, og gem den konkrete hændelsesrækkefølge. Ved afvisning skal defaults og tags følge den besluttede model. Ved accept skal update komme før de events, I vil måle. Ved tilbagekaldelse skal nye events respektere den ændrede tilstand, og det gemte valg skal være konsistent på næste side. Fejl findes ofte i overgangene, ikke i det første skærmbillede.

Vælg løsning efter risiko, databehov og ejerskab

Den bedste opsætning er ikke den med flest funktioner, men den teamet kan forklare, vedligeholde og kontrollere. En CMP-integration kan reducere specialkode, mens en egen løsning kan give mere styring. Begge skaber afhængigheder. Beslutningen bør derfor bygge på samtykkemodel, databehov, platform og internt ansvar.

Vurder løsningen på disse spørgsmål:

• Kan ansvarlige forklare forskellen mellem banner, signal og tag?
• Passer basic eller advanced til den godkendte dataadfærd?
• Understøtter CMP og templates de fire aktuelle signaler?
• Kan teamet gentage testen efter en container- eller bannerændring?
• Er der en ejer, som reagerer på fejl og produktændringer?

En Google-certificeret CMP kan være påkrævet for bestemte Google-annonceprodukter og brugssituationer, men certificering er ikke det samme som en færdig lokal implementering. Kategorier, templates, container-versioner og egen kode kan stadig være forkerte. Afgræns derfor leverandørens ansvar og jeres eget, før en indstilling bliver behandlet som et samlet kvalitetsstempel.

Læg kontrollen ind i releaseprocessen. Nye marketingtags, CMP-opdateringer og redesign kan ændre rækkefølgen uden at nogen redigerer Consent Mode direkte. Gem et kort testscript med forventet resultat for hver gren, og kør det på de vigtigste brugerrejser efter ændringer. Så bliver samtykke en vedligeholdt systemadfærd frem for et projekt, der var grønt på lanceringsdagen.

Når banner, Google Tag Manager, Analytics og kritiske flows skal rettes samlet, er et afgrænset SEO- og websprint med implementering og test mere passende end endnu en generel rapport. Scope bør navngive signaler, tags, skabeloner og acceptkriterier. Hvis teamet allerede kan dokumentere hele kæden, er det legitimt at stoppe og blot overvåge ændringer.