Consent Mode: vad det är och hur du använder det i GA4

Consent Mode v2

Uppdatering oktober 2024:

Verkligt kundexperiment: effekten av Consent Mode i Google Analytics.

Uppdatering april 2024:

Om din webbplats och trafik är från Spanien och du inte använder Google Ads kan du installera GA4 lagligt utan cookie-banner.

Uppdatering februari 2024:

Den första delen av artikeln är en uppdatering med en allmän sammanfattning och nyheterna i version 2 av Googles Consent Mode. Om du inte känner till systemet alls eller vill fördjupa dig mer i det, här nedanför hittar du originalartikeln där jag förklarar grunderna i Consent Mode.

Det verkar som att Consent Mode nu, i slutet av januari 2024, är på allas läppar.

Att det är helt nödvändigt att känna till och använda det i alla webbprojekt, för annars går världen under i mars 2024.

Och ja, det är viktigt, men inte för alla. Och ditt onlineföretag behöver inte gå under bara för att du inte använder det efter det datumet.

Därför vill jag uppdatera min ursprungliga artikel om ämnet, med version 2 av protokollet och de nyheter som väntar framöver, så att du vet om du behöver (oroa dig för) ämnet. Och hur mycket det påverkar dig.

Men innan vi börjar vill jag varna dig för att:

• Om du inte använder display- och remarketingkampanjer i Google Ads.
• Du bryr dig inte om siffrorna i Google Analytics eller har lite trafik på webbplatsen.

Consent Mode (version 1 eller 2) kommer att spela liten eller ingen roll för dig.

Sammanfattning av Consent Mode och version 2

Det räcker att du vet att det är ett Google-protokoll som fungerar som en brygga mellan taggarna och pixlarna du vanligtvis implementerar på webbplatsen via Tag Manager och CDP:erna (Consent Data Platforms), systemen som registrerar vilka cookies användarna har godkänt.

Med andra ord är Consent Mode ett protokoll som ligger mellan båda systemen och definierar och ändrar deras beteende.

I grunden gör Consent Mode följande: det talar om för GTM vilka cookies en användare har godkänt eller nekat, så att taggarna agerar därefter och lägger till cookies eller inte.

Vill du ha mer detaljer förklarar jag det djupare i originalartikeln. Om du redan känner till det kan vi prata lite om cookies…

Så fungerar cookies

Vi börjar med att reda ut en viktig nyans: cookie är inte samma sak som information.

En cookie är en liten fil som lagras i webbläsaren och innehåller information, som kan handla om användaren som besöker en webbplats eller inte.

När en användare nekar cookies förhindrar hen att din webbplats och de taggar du har implementerat (GA4, Facebook, Google Ads) sparar dessa cookies i användarens webbläsare.

Men de här verktygen kan fortsätta samla in information om användaren, bara inte i form av en cookie. Och de lagrar informationen i sina system.

Och det gör de. Självklart gör de det. De fortsätter samla in information på andra sätt som, i dag, är lagliga.

Den här informationen – återigen, i dag – är inte lika komplett som den som samlas in via cookies. Men jag tvivlar knappast på att den förr eller senare når samma nivå.

Utöver hur de fungerar behöver du veta att cookies huvudsakligen är av två typer:

1. First-party: de skapas av den egna domänen för olika syften, bland annat analys och annonsering. Cookies från GA4 och Google Ads hör hit.
2. Third-party: de berömda "tredjepartscookies". I praktiken följer de användaren när hen navigerar mellan olika webbplatser, vilket möjliggör personanpassad annonsering och remarketing. Har du gått in på AliExpress och sedan sett produkter du tittade på annonseras på Marca? Det är tack vare tredjepartscookies.

På grund av missbruket av dessa tredjepartscookies lagstiftade Europa om användningen och tvingade oss att lägga till de underbara bannrarna. Och tvingade medier att ta betalt av den som inte vill acceptera dem.

Betydelsen av tredjepartscookies och Consent Mode v2

Bra, då har vi de två delarna som berörs av förändringen:

1. Consent Mode talar om för GTM-taggarna om de får implementera cookies eller inte.
2. Tredjepartscookies möjliggör personanpassad annonsering och remarketing.

Så Google har kopplat ihop de båda punkterna och sagt att från mars 2024 kan du inte använda display- och remarketingkampanjer i Google Ads om Consent Mode inte är aktiverat på din webbplats.

Det här är nyckeln till hela uppståndelsen kring Consent Mode. Google kommer helt enkelt att inaktivera de här kampanjerna om du inte uppfyller kraven.

Och hur relevant är det här för dig?

För att ta reda på det går vi igenom varje del av meningen:

1. Mars 2024: det är tidsfristen du har för att implementera Consent Mode på webbplatsen om du inte vill påverkas.
2. Consent Mode aktiverat: det innebär ändringar i GTM och CDP. Beroende på hur du har implementerat CDP kan det räcka att uppdatera pluginversionen, eftersom utvecklaren kan ha tagit hand om resten. I GTM behöver du däremot ändra saker själv, även om det kanske bara handlar om att uppdatera CDP-taggen.
3. Display- och remarketingkampanjer: endast dessa. Det vill säga, det påverkar INTE övriga kampanjer (sök, shopping, Pmax). Har du inga Display- eller remarketingkampanjer påverkar det här INTE dig.
4. I Google Ads: ännu en viktig punkt. Det påverkar bara Google Ads. Om du använder remarketingkampanjer med Criteo – för att ta ett exempel – påverkas du inte (åtminstone inte än). Vi får se om övriga displaynätverk följer efter.

Tydligt, eller hur?

Med de här fyra punkterna vet du om ditt projekt påverkas eller inte.

En sak till: här pratar jag om orsaken till den nuvarande uppståndelsen kring version 2, nämligen att vissa typer av Google Ads-kampanjer pausas.

Men Consent Mode (v1 och v2) har konsekvenser för analysen i Google Analytics, som jag återigen förklarar i originalartikeln.

Så om du inte har implementerat det eftersom du saknar display- och remarketingkampanjer kanske vetskapen om hur det påverkar GA4 får dig att ändra dig. Men jag varnar dig: du behöver en rejäl trafikvolym för att få ut något av det…

Consent Mode v2: förändringar jämfört med version 1

Som jag sa i början försöker Google, sedan Consent Mode v1 lanserades, samla in information om användaren även om hen har nekat cookies.

Det görs genom det som Google kallade " pings ", vilket i princip innebar att anonym information om vad användaren gjorde på webbplatsen skickades till Googles servrar.

Eftersom cookies inte ingår tas den del bort som identifierar användaren, och uppgifterna används för att " modellera ". Det vill säga för att komplettera uppgifterna från användare som accepterade cookies, så att vi får mindre ofullständiga data som ligger närmare verkligheten.

GSC: parametern i version 1

För att veta vilken information som kunde skickas och hur lade Google i Consent Mode v1 till en parameter i spårningen av sina pixlar, nämligen GSC ( Google Consent Status).

Den här parametern kunde alltså ha 4 olika värden:

• G100: Google-taggen (som GA4-taggen) laddas, men utan cookiebehörighet. Det är vad Google nu kallar "Avancerat" läge i v2. Jag förklarar mer strax.
• G110: användaren har accepterat annonscookies men inte analyscookies.
• G101: användaren accepterar analyscookies men inte annonscookies.
• G111: användaren har gett samtycke till båda.

Om du gillar teknisk analys kan du se parametern på fliken Network, i Chromes elementinspektör, filtrerat på "collect":

På bilden ovan ser du att:

• Cookies har inte accepterats på webbplatsen.
• Google Analytics laddas ändå (men utan cookies).
• Värdet för parametern GSC är G100, alltså "utan cookie-samtycke", precis som det ska.

Bra, det här hör till version 1 och finns kvar i version 2. Det har inte ändrats.

Det som däremot har hänt är att en ny parameter har lagts till.

GCD: parametern i version 2

Utöver GSC har vi nu en ny parameter i Googles taggar, nämligen GCD, som, som du ser, består av en längre sträng än den tidigare:

Man har ännu inte helt lyckats tyda vad varje siffra och bokstav betyder, men strukturen är känd och ser ut så här:

11<ad_storage>1<analytics_storage>1<ad_user_data>1<ad_personalization>5

Där:

• "11" markerar början på parametern.
• "1" skiljer värdena åt.
• Bokstäverna är värdena för vart och ett av dessa samtycken. Tillsammans bildar de en matris med två koordinater: den ena avgör om samtycke finns eller inte, den andra om samtycket är standardvärdet (nästan aldrig) eller en uppdatering (att användaren har accepterat eller avvisat det).
• Ad_storage och analytics_storage fanns redan tidigare (det är samma information som i parametern GSC).
• Ad_user_data och ad_personalization är det nya, och det är viktigt. Det första gäller annonssamtycke och det andra remarketing. De här två värdena har INGEN påverkan på GTM-taggar och är tänkta för Googles interna information. Min uppfattning är att de förbereder sig för den dag då lagstiftningen inte riktas mot cookies utan mot användningen av användarinformation för de här ändamålen. Som jag sa ovan färdas information inte alltid inuti en cookie.

Terminologi: på väg mot standardisering

Utöver de tekniska förändringarna har Google velat "normalisera" situationen och förtydliga begreppen, så att vi vet vilka termer som används.

Det gäller framför allt de två sätten att implementera samtycke korrekt: grundläggande och avancerat.

Grundläggande läge

Det enklaste sättet att uppfylla kraven, men sämre.

Det innebär att ingen tagg eller pixel utlöses förrän användaren accepterar cookie-bannern.

Det var mycket enkelt att implementera: det räcker att koppla laddningen av GTM-containern till det ögonblick då användaren accepterar cookies.

Men då förlorade man förstås ganska mycket data, till exempel sessionens källa och medium eller landningssidan, om användaren accepterade cookies på en annan sida än landningssidan.

Avancerat läge

Det bra.

Vi måste aktivera Consent Mode i vår GTM-container och använda kompatibla taggar, bland annat samtliga från Google.

Det vill säga: om du vill implementera GA4 med Consent Mode är det normala att göra det via GTM och inte genom att lägga in det i webbplatsens kod.

När vi gör det via GTM utlöser vi Analytics-taggen varje gång GTM körs (normalt när sidan laddas), men den sätter INGA cookies förrän användaren accepterar bannern. Under tiden skickar den informations-"pings" till sina servrar.

När användaren har accepterat bannern sätter den däremot Analytics-cookien och samlar in maximal information.

Typer av implementation av Consent Mode

Med allt detta kan vi i praktiken välja mellan tre angreppssätt på webbplatsen när det gäller samtyckesläget:

• Utan Consent Mode.
• Med Grundläggande Consent Mode.
• Med Avancerat Consent Mode.

#1. Utan Consent Mode

Vi struntar i vad Google säger.

Fördelar:

Vi behöver inte göra något annat än att se till att vi följer GRDP.

Vi kan använda GA4 utan cookie-banner under vissa omständigheter.

Nackdelar:

Vi kan inte köra remarketing- och displaykampanjer i Google Ads.

Våra data i GA4 kommer sannolikt att ha lägre kvalitet, beroende på implementationen.

Lämpligt för webbplatser:

Små, som använder Analytics på en grundläggande nivå och utan annonsering. Vanligtvis utan något monetariseringsmål.

Och sannolikt inte GTM heller.

#2. Med Grundläggande Consent Mode

Vi tillämpar samtycket på ett enkelt sätt och följer GDPR.

Fördelar:

Just det: enkelt att implementera. Till och med självadministrerat.

Nackdelar:

Datakvaliteten blir inte den bästa.

Lämpligt för webbplatser:

Små eller medelstora, som annonserar lite eller inte alls, men ändå vill samla in och analysera viss data. Och som använder GTM och GA4 för det.

De behöver egentligen ingen CDP för att följa GDPR, eller så räcker en mycket grundläggande.

Tänk till exempel på icke-transaktionella företagswebbplatser.

#3. Med Avancerat Consent Mode

Vi skärper oss eftersom vi vill åt fördelarna eller behöver dem. Och implementerar hela systemet.

Fördelar:

Möjlighet att använda alla typer av Google Ads-kampanjer.

På stora webbplatser förbättras datakvaliteten – samtidigt som GRDP följs.

Nackdelar:

Det är ganska krångligt om du vill göra det själv och inte vill betala för en CDP.

Du måste kunna hantera GTM och ibland ha en teknisk profil eller någon som hjälper dig.

Lämpligt för webbplatser:

Medelstora eller stora som investerar i annonsering eller arbetar avancerat med Google Analytics.

Projekt som monetariseras.

Slutsatser

Sammanfattningsvis har Google med version 2 av Consent Mode utökat den information som systemet använder och gjort den mer detaljerad . Det innebär att det tidigare (version 1) inte ogiltigförklaras utan byggs ut.

Dessutom håller Google på att standardisera systemet genom att namnge de olika typerna av samtycke.

Det är ytterligare ett steg i teknifieringen av digital analys och digital marknadsföring. Branschen verkar bli allt mognare och kommer att kräva större resursinvesteringar om du vill nå nivåer som för bara några månader / år sedan var enklare att uppnå.

Hur det påverkar dig beror på hur mycket du använder Googles plattformar: är användningen liten påverkas du ganska lite, men är beroendet stort får du jobba.

Det minsta du behöver göra i det här fallet är, uppdatera din CDP-tagg i GTM, om du använder någon alls, vilket du kanske inte gör.

Jag kanske utökar den här artikeln framöver eller skriver en ny om konfigureringen av Consent Mode v2 i några av de vanligaste CDP:erna.

Tills vidare, om ämnet intresserar dig och du vill ha mer information, fortsätt läsa precis nedanför, eftersom du dessutom får en medelavancerad men kostnadsfri implementation av version 1 av Consent Mode. v2 kommer nog inte att skilja sig särskilt mycket.

När jag tar tag i den säger jag till.

Innan du fortsätter tror jag att det här kan intressera dig

Registrera dig och få min 66-sidiga guide med de  Bästa kostnadsfria digitala verktygen  för:

• Marknadsföring
• Analys
• UX
• Projektledning…

Dessutom får du varje dag ett knep eller råd (ett bra sådant) i inkorgen för att förbättra ditt företag eller digitala projekt.

Consent Mode v1: originalartikeln

Sedan det lanserades har det pratats en hel del om ämnet, men till min förvåning mindre än det kanske förtjänar. Utan att vara ett paradigmskifte påverkar det ändå två grundläggande delar av analysen:

• Implementation (som blir mer komplex).
• Rapportering (som förmodligen får bättre datakvalitet).

Därför vill jag berätta om systemet och hur det kan gynna oss i utbyte mot att den tekniska utvecklingen som krävs för att sätta det i drift ökar.

Är det värt det?

Det får du själv avgöra när du har läst artikeln.

Vad är Consent Mode?

Consent Mode är Googles svar på GDPR: ett system som använder GTM och gör det möjligt att följa integritetslagen och ändå låta vissa taggar – som Google Analytics och Google Ads – samla in vissa uppgifter om användarna som besöker våra webbplatser.

I grund och botten är det ett mätsystem cookieless, som visserligen inte är lika exakt som om vi alltid lade in Google Analytics-snippet direkt när sidan laddas (som vi gjorde före GDPR), men ändå är ett steg framåt jämfört med att ladda taggen först efter att användaren har accepterat cookies.

För att göra det tydligare har vi, beroende på vilka data som samlas in, tre alternativ för implementation av Google Analytics:

1. Ladda taggen först när användaren accepterar cookies: vi förlorar mycket data, framför allt om användaren inte accepterar cookies på landningssidan utan flera sidor senare. Uppfyller GDPR till 100%.
2. Ladda alltid taggen utan cookies via Consent Mode: vi förlorar data, men mindre än tidigare (det kommer vi till strax). När användaren accepterar laddar vi den vanliga taggen med dess cookies. Uppfyller också GDPR till 100%.
3. Ladda den vanliga taggen utan att vänta på att användaren accepterar cookies: vi samlar in maximalt med data. Synd bara att det är olagligt eftersom det inte följer GDPR.

När de tre möjliga scenarierna är tydliga fokuserar jag i den här artikeln på det andra, som kommer att bli – om det inte redan är det – standardimplementationen i analysprojekt för företag.

Innan vi går in på datadetaljerna vill jag säga att Consent Mode också försöker göra det enklare att utlösa andra taggar eller pixlar (Facebook, affiliatenätverk) beroende på vilka behörigheter användaren ger oss.

Det lämnar vi till senare eftersom jag, som sagt, i den här artikeln fokuserar på fördelen för mätningen med Google Analytics, och där finns en hel del att ta upp.

Fördelar med Consent Mode i GA4

Den största fördelen med att använda det här systemet när GA4 implementeras är att Google Analytics, med den extra data vi samlar in, kommer att kunna härleda en del av de data som inte har samlats in, genom att modellera den information som finns med sina egna algoritmer.

På så sätt kommer mätvärden som antalet dagliga användare och deras egenskaper (land, kampanj) att ligga mycket närmare verkligheten. Även härledda mätvärden, som konverteringsgraden, påverkas.

Google kallar dessa data "modellerade", i motsats till de data som samlas in normalt (de "observerade").

Och om vi uppfyller kraven som vi strax går igenom kan vi i GA4-administrationen välja om vi vill använda båda typerna av data ("blandat", som Google kallar det) eller bara de observerade (det vi har sett hittills):

Förutsättningar

När vi går in på själva kraven har vi två typer, de tekniska -som rör implementationen av systemet- och volymkrav -som rör den datamängd som krävs för att GA4 ska kunna uppskatta korrekt och systemet bli robust-.

Vi börjar med de senare.

Nödvändiga volymer

Om vi går till Analytics-dokumentationen, kan vi läsa att:

“Egendomen samlar in minst 1000 händelser per dag med analytics_storage='denied' under minst 7 dagar.

Egendomen har minst 1000 dagliga användare som skickar händelser med analytics_storage='granted' under minst 7 av de senaste 28 dagarna.

Modellen kan behöva mer än 7 dagar för att nå datatröskeln under den perioden på 28 dagar. Det är dock möjligt att inte ens den extra datan räcker för att Analytics ska kunna träna modellen.

Beteendemodellerna börjar fungera från det datum då en viss egendom uppfyller kraven.

I det ovanliga fall där en egendom som tidigare uppfyllde kraven slutar göra det blir de uppskattade uppgifterna inte längre tillgängliga. Om egendomen åter uppfyller kraven blir de uppskattade uppgifterna tillgängliga igen. De uppskattade uppgifterna är endast tillgängliga från det datum då egendomen åter började uppfylla kraven.”

Okej, om du undrar vad analytics_storage är kan jag säga att det handlar om användarens godkännande av analyscookies. “denied” innebär att hen INTE har accepterat dem ännu.

För full funktionalitet (framför allt kopplat till aktiveringen av Signals) kräver GA4 dessutom att annonscookies accepteras, alltså ad_storage.

Tekniska krav

Utöver dessa datavolymer behöver vi uppfylla en rad saker innan vi börjar:

• Vi behöver ha GTM implementerat på webbplatsen på något av följande sätt:
• Infogat i koden.
• Via plugin (så har jag det).
• Via temats alternativ.
• Ett webbdataflöde för GA4 implementerat via GTM.
• En cookie-banner som gör det möjligt att acceptera eller neka analys- och annonscookies (åtminstone). Den kan vara implementerad:
  • Med specialskriven kod.
• Plugin i CMS:et (så har jag det).

När allt detta är implementerat kan vi börja konfigurera hela systemet.

Processen

Men innan vi konfigurerar något måste vi först förstå hur systemet ska fungera, eftersom ordningen på elementen spelar roll.

När en ny användare kommer in på webbplatsen ska följande hända:

1. Den initiala Consent Mode-status-taggen i GTM laddas. Vid den här punkten är värdena för analytics_storage och ad_storage “denied”, eftersom användaren ännu inte har accepterat något.
2. Från GTM laddas GA4-taggen utan cookies, eftersom Consent Mode är aktivt.
3. Det visas en cookie-banner. Här har användaren tre alternativ:
   1. Om användaren inte accepterar cookies: fortsätter den cookieless GA4-taggen att laddas på varje sida, med partiell information som GA4 modellerar.
   2. Si acepta solo algunas cookies: en este caso, GA4 recogerá los datos correspondientes a analytics_storage (los principales) o a ad_storage (secundarios) en función de lo que haya aceptado el usuario.
   3. Si acepta todas las cookies: se mandará la aceptación a GA4 y se empezará a recoger la información completa.

Viktigt: oavsett vilket alternativ användaren väljer kommer värdet för analytics_storage och ad_storage på varje sida att först laddas i GTM och skickas till GA4. Det här är den mest komplexa / tekniska delen av implementationen.

Så konfigurerar du Consent Mode i WordPress

När vi väl förstår hur allt ska fungera kan vi sätta igång.

Ett förtydligande: beroende på din webbplats kan ett system passa bättre än ett annat. Därför lämnar jag här ett par guider som visar hela processen med WordPress-plugins:

• Med Cookiebot: kanske det enklaste, eftersom det finns en specialanpassad mall i GTM. Problemet är att gratisversionen av den här CMP:n bara tillåter upp till 50 URL:er på webbplatsen, vilket blir för lite för de flesta. Har ditt projekt färre än 50, börja här (metod 3).
• GDPR Cookie Compliance: så har jag implementerat det, eftersom jag har fler än 50 URL:er på min webbplats. Jag har dock gjort några ändringar när GA4-taggen aktiveras, och det är den lösningen jag utgår från när jag förklarar steg för steg, med några extra kommentarer.

Nu kör vi, steg för steg.

#1. Installera pluginet

Vi installerar det här pluginet i WordPress:

https://es.wordpress.org/plugins/gdpr-cookie-compliance/

Om vi använder något annat för cookies inaktiverar vi det när det nya systemet fungerar.

Texter och knappar kan du konfigurera som du vill, men avsnittet “Tredjepartscookies” konfigurerar vi så här:

Och “Ytterligare cookies” så här:

Spara allt.

#2. Identifiera status för båda typerna av cookies och skicka den till DataLayer

Om du minns sa jag att vi på varje sida måste skicka statusen för användarens samtycken till GA4, så att systemet vet vilka data som ska sparas och hur (analytics_storage och ad_storage, minns du).

Här lägger vi till kod i WordPress som läser pluginets samtyckesstatus vid varje sidladdning och skickar två variabler med motsvarande värden till DataLayer:

1. Som standard måste den initiala samtyckesstatusen vara “denied” (nekad) för båda.
2. När användaren accepterar någon typ av cookies registrerar pluginet ändringen, och vid nästa sidladdning läser vi in det ändrade värdet med den här koden (på sidan där användaren accepterar har ändringen redan skickats till GTM).

Det här ska läggas till i filen functions.php i vårt child theme:

/*Función GDPR*/
if (!is_admin()){
if ( function_exists( 'gdpr_cookie_is_accepted' ) ) {
/* supported types: 'strict', 'thirdparty', 'advanced' */

/*Analítica*/
if ( gdpr_cookie_is_accepted( 'thirdparty' ) ) {
?>
<script>
dataLayer = [{
'cookies_analitica': 'granted'
}];
</script>
<?php
} else {
?>
<script>
dataLayer = [{
'cookies_analitica': 'denied'
}];
</script>
<?php
}

/*Marketing*/
if ( gdpr_cookie_is_accepted( 'advanced' ) ) {
?>
<script>
dataLayer.push({
'cookies_marketing': 'granted'
});
</script>
<?php
} else {
?>
<script>
dataLayer.push({
'cookies_marketing': 'denied'
});
</script>
<?php
}
}
}

Jag påminner om att jag hämtade koden härifrån.

Vi kan lägga till den via FTP eller från WordPress-administrationen, men var försiktig med vad du ändrar här om du inte är van:

På så sätt hämtar vi rätt värde vid varje sidladdning via GTM:s datalager-variabler och skickar det vidare till GA4.

#3. Skicka rätt samtyckesvärden till DataLayer

För att skicka värdena för analytics_storage och ad_storage till GA4 använder vi två DataLayer-variabler: en med användarens samtyckesstatus för analyscookies och en för annonscookies.

Vi behöver skapa båda som jag visar här.

Analyscookies

Det viktigaste är variabelns namn: cookies_analitica.

Annonscookies

Det viktiga är återigen variabelns namn: cookies_marketing.

#4. Aktivera Consent Mode

Det här är enkelt. Det görs i containerinställningarna:

#5. Importera Simo Ahavas mall

Om du har läst någon annan av mina artiklar om GTM vore det märkligt om jag inte hade nämnt världens största expert på GTM-implementationer: Simo Ahava.

Simo tillhandahåller en mall som kommer att göra livet mycket enklare när vi konfigurerar beteendet för de behörigheter användaren har gett när det gäller cookies.

För att importera den går du till avsnittet Mallar, söker efter “consent” och klickar på den jag markerar:

#6. Skapa Consent Mode-taggarna

När mallen är importerad skapar vi de två samtyckestaggar som behövs: den initiala, som laddas på alla sidor före resten av taggarna, och uppdateringstaggen, som laddas när användaren ändrar sitt samtycke för någon typ av cookies.

Den initiala

När vi importerar Simo-mallen får vi en ny typ av Consent Mode-tagg:

Vi skapar en ny av den här typen med följande konfiguration:

Här finns flera saker att kommentera:

Det första är att förstå vad den här taggen används till.

Det är den här taggen som talar om för övriga taggar som använder Consent Mode (som GA4-taggen) vilka cookies användaren har accepterat.

Därför laddas den här taggen i GTM före alla andra och dess kommando är Default.

Precis nedanför ser vi att taggen hanterar 5 typer av cookies:

• Analys: avser analytics_storage.
• Annonsering: avser ad_storage.
• Personalisering.
• Funktionalitet.
• Säkerhet.

De två sista får enligt GDPR läggas till för användaren som standard.

Personaliseringscookies används för att rekommendera videor på YouTube, låtar på Spotify eller produkter på Amazon. De är inte relevanta för GA4.

De andra två, som är de viktiga här, har vi redan förklarat vad de innebär.

Med det här klarlagt förstår du varför vi lämnar säkerhet och funktionalitet som “granted” (det vill säga att användaren ger oss tillåtelse att installera dem).

Vi laddar värdet för analys- och annonscookies beroende på vad användaren har gjort tidigare (om hen har accepterat eller inte).

Det värdet är det vi får fram med koden som lagts till i filen functions.php och det finns i de två DataLayer-variabler vi skapade tidigare. Därför använder vi dessa variabler som standardstatus för samtycket.

Kom ihåg att när en användare kommer in på webbplatsen är de “denied” vid den första sidladdningen, men på följande sidor kan värdet ha ändrats om användaren har accepterat någon typ av cookies.

Som sagt finns allt detta i koden i functions.php, så om det känns komplicerat och du bara vill att det ska fungera kan du kopiera den och konfigurera den exakt så.

Till sist kan vi sätta personaliseringscookies till “denied” för GA4, men om du samlar in samtycke för den typen av cookies på webbplatsen eftersom du använder dem kan du använda en datalager-variabel precis som för de två tidigare (då måste du ändra koden i functions.php, förstås).

När det gäller de markerade alternativen under Other Settings ska du veta att de hjälper oss att fånga kampanjen mer korrekt i utbyte mot att parametrar läggs till i URL:erna. Jag rekommenderar att du lämnar dem aktiverade.

Till sist har vi triggern. Här finns nyheter.

Om du tittar ser du att det är Consent Initialization – All Pages.

Den här triggern finns som standard i GTM och är en av de nya som Google lade till i verktyget i samband med Consent Mode.

Det här är triggern som gör att den här taggen laddas före alla andra i GTM, så att resten av taggarna kan läsa dess värden och agera därefter.

Som information kan jag säga att om Consent Mode är aktiverat samlar GA4 in värdet för en ny parameter (“gcs”) i sina anrop. Den här parametern kan ha fyra värden:

• G100: initial status, varken analys- eller annonscookies accepterade.
• G101: analyscookies accepterade.
• G110: annonscookies accepterade.
• G111: båda typerna av cookies accepterade.

Det är värdet på den här parametern som gör att GA4 samlar in olika användardata och avgör hur de sedan behandlas.

När användaren accepterar något

Bra, då går vi vidare till den andra Consent Mode-taggen, den som uppdaterar användarens samtycken (och samtidigt ändrar värdet på parametern GCS).

Det här steget har lite mer substans eftersom vi, utöver själva Consent Mode-taggen, måste skapa andra taggar först som uppdaterar värdena i de DataLayer-variabler vi skapade tidigare.

Taggar för att skicka samtyckesuppdateringen till DataLayer

Beroende på om användaren accepterar alla cookies eller bara vissa blir skickningen till DataLayer olika.

Vi börjar med det vanligaste fallet.

Användaren accepterar alla cookies

På webbplatsen har pluginet lagt in den här knappen:

Den gör att användaren accepterar alla cookies.

När hen gör det skickar vi en anpassad HTML-tagg till GTM med den här koden:

<script>
dataLayer.push({
  'event': 'guardar_cookies',
  'cookies_analitica': 'granted',
  'cookies_marketing': 'granted'
})
</script>

Det den gör är att ändra värdet på våra DataLayer-variabler cookies_analitica och cookies_marketing.

Taggens konfiguration ser ut så här:

Där ser vi koden ovan och en klicktrigger på knappen vi nämnde, med den här konfigurationen:

Knappens klass matchar det reguljära uttrycket: (moove-gdpr-infobar-allow-all)|(moove-gdpr-modal-allow-all).

 Det var allt.

Användaren uppdaterar vissa cookies

Nu går vi till fallet där användaren inte accepterar alla utan bara vissa.

Det är när hen går in i bannerns inställningar och sparar härifrån:

Koden ser ut så här:

<script>
var check_marketing = document.querySelector('#advanced-cookies .cookie-switch input').checked;
if(check_marketing){
  var cookies_marketing = 'granted';
} else{
  var cookies_marketing = 'denied';
}
var check_analitica = document.querySelector('#third_party_cookies .cookie-switch input').checked;
if(check_analitica){
  var cookies_analitica = 'granted';
} else{
  var cookies_analitica = 'denied';
} 
dataLayer.push({
  'event': 'guardar_cookies',
  'cookies_analitica': cookies_analitica,
  'cookies_marketing': cookies_marketing
})
</script>

Vi gör samma sak: skapar en anpassad HTML-tagg med den här konfigurationen:

Där den nya triggern måste se ut så här:

Där klickklassen är: moove-gdpr-modal-save-settings.

Anpassad händelse för att spara cookies

Om du tittar på de två kodblocken ovan ser du att vi i båda fallen skickar en anpassad händelse till DataLayer: guardar_cookies.

Jag förklarar strax varför, men först skapar vi en trigger med den här händelsen:

Uppdateringstaggen för Consent Mode

När allt detta är skapat går vi vidare till den andra Consent Mode-taggen, den som uppdaterar användarens samtycken.

Konfigurationen ser ut så här:

Där:

• Kommandot är Update, eftersom det är den som uppdaterar värden.
• Värdet på DataLayer-variablerna har uppdaterats och det nya värdet hämtas här.
• Triggern är den vi precis skapade, som utlöser taggen så snart användarens samtycken uppdateras.

Därmed är konfigurationen klar. Som du ser har vi inte rört GA4-konfigurationen alls, vars trigger fortfarande är All pages:

Tester

Dags att testa.

Det första vi gör är att installera det här tillägget om vi inte redan har det, för att radera cookies.

Sedan installerar vi det här andra för att se Googles taggar.

Därefter gör vi följande:

#1. Radera cookies för vår webbplats

För att efterlikna beteendet hos en ny användare raderar vi dem genom att klicka på tillägget och papperskorgsikonen:

#2. Ladda om sidan

På så sätt kontrollerar vi att det faktiskt inte finns några Analytics-cookies kvar efter raderingen:

#3. Öppna förhandsgranskning i GTM

Sidan laddas om och vi kontrollerar att:

• GTM och GA4-taggen laddas (de flera jag har installerade):

• Ingen Analytics-cookie laddas:

Det betyder att GA4 tar emot data utan cookies. Vi är på rätt väg.

#4. Acceptera cookies

Vi klickar på knappen för att acceptera alla cookies eller bara vissa.

Vi kontrollerar att GA4-cookies har lagts till:

Som ett tillägg och en liten kuriositet kan vi i konsolen se att värdet på parametern GCS har ändrats:

Det betyder att allt har fungerat som det ska och från och med nu kan vi, så snart vi uppfyller volymkraven som förklarades tidigare, dra nytta av GA4:s datamodellering.

Frågor

Den viktigaste frågan som kanske dyker upp är vad som händer om en användare accepterar cookies på en annan sida än landningssidan.

I de tester jag har gjort har jag inte kunnat se hur GA4 behandlar den här förändringen. I BigQuery leder den däremot till att förfrågningarna i användarens session med parametern gcs=G100 före cookie-godkännandet ändras till förfrågningar med gcs=G111, vilket gör att datan kan behandlas fullständigt (viktigt för exakta data om källa eller landningssida).

Därför lutar jag åt att behandlingen i GA4 är liknande, även om jag som sagt inte har kunnat bekräfta det.

Den näst vanligaste frågan är hur mycket precision vi vinner.

Och där har jag inte heller något svar, eftersom man för att kontrollera det skulle behöva jämföra en GA4-implementation med en annan som alltid laddas direkt på webbplatsen (utan GTM), som vi gjorde förr.

Och det strider mot GDPR.

Dessutom är jag inte alls säker på att ett aktiverat Consent Mode i GTM-containern, där den initiala taggen laddas före resten, inte påverkar GA4-taggen som laddas utanför containern. Det borde den inte göra, men mina tester har inte gett ett helt tydligt svar.

Slutsatser

Jag hoppas att jag har gjort det lite tydligare vad Consent Mode är, hur det kan gynna dig och hur du kan implementera det på en webbplats med WordPress.

Med det sagt, efter att ha lagt en bra stund på ämnet drar jag några slutsatser som sammanfattning:

Den första är att Consent Mode är här för att stanna, eftersom allt som innebär att samla in data som hjälper till att optimera kampanjer är välkommet.

Den andra är att dess implementation inte är helt enkel. Är du utvecklare får du visserligen allt konfigurerat ganska snabbt, men om du inte är det är det inte omedelbart att hantera samtyckesvärdet hela tiden.

Det här förstärker teknifieringen av digital analys, och dessutom ser det ut som att det blir mer användbart i integrationer med BigQuery.

Med den massiva implementationen av GA4 just nu kanske det ändå är ett bra tillfälle att ta tag i frågan i stället för att skjuta upp den för alltid.

Det finns fortfarande frågor kring den svarta låda som datamodelleringen hos Google utgör, där företaget är både domare och part (kommer det att gynna sin egen trafik?), även om jag i det här fallet väljer att lita på dem.

Kort sagt: ett nytt sätt att förstå analys, efter det första “allt är tillåtet” och det senare “nästan inget är tillåtet” under GDPR. Det behövs mer tid och mer data för att se om det är värt det i enklare implementationer.