Tracking for webshops: GA4, Meta Pixel og Consent Mode v2

Hvad sker der med dine tal, når kunden siger nej?

Det afhænger af, hvilket værktøj du spørger, og de tre store opfører sig ikke ens. Det er værd at vide, før du begynder at lede efter fejl i tal, der aldrig kommer til at stemme.

Google har bygget en mellemvej. Deres Consent Mode kan sættes op, så dine tags bliver ved med at loade, og så sender de det, Google kalder cookieløse pings, når kunden har sagt nej. Google beskriver selv, at der ved afvist samtykke sendes målinger uden tredjepartscookies til Analytics til brug for grundlæggende måling og modellering. Der bliver altså stadig sendt noget.

Butiksplatformen kan gå den modsatte vej og simpelthen lade være med at køre pixlen. Shopify skriver om deres egen pixel-manager, at web-pixels i markeder, der er sat op til at kræve samtykke, kun kører, når den besøgende har givet de tilladelser, pixlens opsætning kræver. Læg mærke til, at det gælder de markeder, der er sat op sådan, og ikke alle markeder.

Meta beskriver ikke noget tilsvarende. Til gengæld står kravet i deres vilkår: du skal på verificerbar måde sikre, at kunden har givet de nødvendige samtykker, før du bruger værktøjerne til at gemme noget på kundens enhed.

Tre værktøjer, tre svar. Det er derfor, en opsætning kan være rigtig ét sted og forkert et andet, og det er derfor, denne guide tager dem hver for sig.

Hvad er Consent Mode v2 egentlig?

Det korte svar er, at det ikke er et cookiebanner. Google skriver det lige ud: Consent Mode leverer ikke et banner eller en widget, den taler sammen med det, du har i forvejen. Banneret skal altså komme et andet sted fra. Consent Mode er den ledning, bannerets svar løber igennem, ind til Googles tags.

Google kalder dem samtykketyper. Fire er dem, du møder i praksis. ad_storage og analytics_storage er de oprindelige og handler om lagring til henholdsvis annoncering og statistik. ad_user_data og ad_personalization kom til, da Google opdaterede tilstanden i november 2023, og de handler om, hvorvidt der må sendes brugerdata til Google til annoncebrug, og om annoncerne må personaliseres. Det er den opdatering, der har givet navnet v2.

Google nævner syv samtykketyper. Deres egen formulering er, at samtykketyperne omfatter de syv, ikke at der kun findes syv. De tre sidste bruges ikke af alle, men de er værd at kende, hvis din samtykkeløsning viser dem frem.

Én ting er værd at vide, før du går i gang: sætter du ikke selv en standardværdi, er der ingen. Google skriver på deres udviklerside, at der som udgangspunkt ikke er sat nogen consent mode-værdier.

Grundlæggende eller avanceret: hvad koster hver af dem?

Google har to måder at sætte det op på, og forskellen er, hvad der sker, før kunden har trykket.

Vælger du den grundlæggende, bliver Googles tags holdt tilbage, indtil kunden rører banneret. Siger kunden nej, sker der ingenting. Google skriver, at der da slet ikke overføres data, ikke engang samtykkestatussen, og at deres tags er fuldstændig blokeret fra at fyre.

Vælger du den avancerede, loader dine tags med det samme. Siger kunden nej, sendes der cookieløse pings i stedet for, at der sættes cookies. Til gengæld er det den opsætning, der giver den mere detaljerede modellering, fordi Google så bygger en model på din butiks egne tal frem for en generel model.

Og så er der noget, der ikke kan afgøres her. Tre af Googles egne sider giver ikke samme svar på, hvad udgangspunktet er. To af dem skriver udtrykkeligt om den avancerede opsætning, mens den tredje skriver om consent mode i det hele taget. Deres vejledning til udviklere om at sætte consent mode op skriver, at der som udgangspunkt ikke er sat nogen consent mode-værdier. Deres oversigtsside om consent mode skriver i sin sammenligningstabel, at tags loader med standardværdier sat til afvist, medmindre andet er konfigureret. Og deres hjælpeside About consent mode skriver under overskriften om den avancerede opsætning, at systemet som udgangspunkt antager samtykke, indtil et konkret valg er truffet, men at der kan være regionale forskelle for områder som EØS, Schweiz og Storbritannien. De tre kan formentlig forenes, men ingen kilde gør det, og det skal ikke gættes på din regning. Det, der står fast, er udviklervejledningens praktiske konsekvens: sætter du ikke selv en standardværdi, har du ikke sat en.

Om den avancerede opsætning må bruges i Danmark, er der heller ikke svar på. Google beskriver selv, at der sendes data ved et nej. Hverken Google eller nogen dansk kilde forholder sig til, om det er foreneligt med de danske cookieregler. At Google anbefaler den avancerede, er ikke det samme som, at nogen har blåstemplet den. Er svaret afgørende for dig, er det et spørgsmål til en rådgiver og ikke til denne guide.

Hjælper Googles modellering en webshop som din?

Modelleringen udfylder hullerne efter dem, der har sagt nej, ved at regne baglæns fra dem, der har sagt ja. Den lyder derfor som løsningen på hele problemet. Tallene er værd at kende, før du bygger noget på den.

For at komme i betragtning skal din property opfylde fire ting. Google skriver property, ikke konto, og det er værd at holde fast i: en konto kan rumme flere properties, og tærsklen gælder for den enkelte. Consent Mode skal være slået til på alle sider. Tagsene skal loade, før samtykkedialogen vises, hvilket er den avancerede opsætning. Propertyen skal indsamle mindst 1.000 hændelser om dagen med analytics_storage sat til afvist i mindst 7 dage. Og den skal have mindst 1.000 daglige brugere, der sender hændelser med analytics_storage sat til givet, i mindst 7 af de seneste 28 dage.

Læg mærke til to ting i de tal. Det er 1.000 om dagen og ikke 1.000 i alt. Og kravet skal holde på de dage, der tæller, ikke på alle dage: 7 dage for de afviste hændelser, og 7 ud af de seneste 28 for de samtykkende brugere. Har din property ikke den trafik på nok dage, får du ingen modellerede tal, uanset hvor rigtigt alt andet er sat op. Du får stadig de tal, du faktisk har målt.

To forbehold mere, og de trækker samme vej. Google skriver, at det kan tage mere end 7 dage inden for de 28 at træne modellen, og at det er muligt, at selv de ekstra data ikke er nok. Og de skriver, at det at nå tærsklerne ikke i sig selv giver adgang, fordi modellen har sine egne kriterier, blandt andet forholdet mellem nye og tilbagevendende brugere og mellem brugere og sessioner.

Så er der en detalje, der får folk til at lede forgæves efter tal, de har krav på. Modellerede tal vises kun, hvis rapporteringsidentiteten står på Blended, og den indstilling kræver mindst Editor-adgang på kontoen.

Og til sidst en ting, der slår modelleringen helt fra. Bruger din samtykkeløsning IAB Europes rammeværk TCF, kan Analytics ifølge Google ikke modellere de manglende data, når brugeren siger nej. Det er værd at spørge din leverandør om, for flere løsninger på det nordiske marked bruger TCF til annoncedelen.

Hvad kræver Google af dig ud over loven?

Google har sin egen samtykkepolitik for slutbrugere i EØS, Storbritannien og Schweiz. Den gælder, hvis din aftale med Google indeholder politikken, eller du på anden måde bruger et Google-produkt, der gør. Den gælder i kraft af dit forhold til Google, ikke i kraft af en myndighed. Politikken er kort og nummererer ikke sine krav, men vi læser fem ting, du skal, ud af det afsnit, der handler om sites, som du selv, et selskab i din koncern eller en kunde, du driver site for, har kontrol over. Politikken findes kun på engelsk, så oversættelsen er vores.

Du skal hente gyldigt samtykke til to forskellige ting, og de to er ikke formuleret ens. Til brug af cookies og anden lagring gælder kravet, hvor det er retligt påkrævet. Til indsamling, deling og brug af persondata til personalisering af annoncer står der ikke noget tilsvarende forbehold. De to led skal derfor læses hver for sig, og forbeholdet på det første kan ikke løftes over på det andet.

Så er der tre til. Google skriver, at du skal gemme dokumentation for de samtykker, kunderne har givet, og at du skal give kunderne klar vejledning i, hvordan de trækker samtykket tilbage. Og du skal tydeligt oplyse, hvem der kan indsamle, modtage eller bruge kundernes persondata som følge af, at du bruger et Google-produkt.

Den femte er den, der oftest bliver væk, fordi den står i sætningen lige efter den fjerde og ligner en gentagelse. Det er den ikke. Ud over at navngive den part skal du ifølge Google også give kunderne fremtrædende og let tilgængelig information om den parts brug af deres persondata. Du er altså ikke færdig med at have skrevet Google på en liste i din privatlivspolitik; kunderne skal også nemt kunne finde ud af, hvad Google bruger oplysningerne til.

Politikken har en sjette pligt under sin næste overskrift, og den handler om andres sites. Deles persondata om deres brugere med Google, fordi du bruger eller integrerer med et Google-produkt, skal du gøre en kommercielt rimelig indsats for at sikre, at den, der driver sitet, lever op til de samme pligter. Læg mærke til, hvordan Google afgrænser det: et tredjeparts-site er efter deres definition et, som hverken du, et selskab i din koncern eller en kunde, du driver site for, kontrollerer, og hvis operatør ikke i forvejen selv bruger et Google-produkt, der indeholder politikken. Begge betingelser skal være opfyldt. Bruger den, der driver sitet, allerede selv et Google-produkt med politikken i, falder sitet uden for definitionen, og så gælder den sjette pligt ikke.

Sanktionen er ikke en bøde. Den er kontraktlig: Google skriver, at de kan begrænse eller suspendere din brug af produktet eller opsige aftalen med dig. Kravene om at gemme dokumentation og om at vejlede i tilbagetrækning ligner dem, du kender fra de danske regler, men de kommer fra en anden kilde og har en anden konsekvens. Hvad loven kræver, og hvordan du dokumenterer et samtykke, står i guiden om cookies og GDPR.

Hvad kræver Meta af dig ud over loven?

Metas vilkår for virksomhedsværktøjer dækker Meta-pixlen, Conversions API og deres øvrige måleværktøjer. Den danske udgave, Meta selv serverer, har ikrafttrædelsesdato 3. november 2025.

Samtykket først. Vilkårene siger, at du i jurisdiktioner, der kræver informeret samtykke til lagring på og adgang til en slutbrugers enhed, såsom, men ikke begrænset til, EU, på verificerbar måde skal sikre, at slutbrugeren giver de nødvendige samtykker, før du bruger værktøjerne. Forbeholdet om, at EU ikke er den eneste sådan jurisdiktion, er Metas eget.

Så er der en meddelelse, som mange overser, fordi den ikke ligner et cookiebanner. Meta skriver, at du skal have givet brugerne en meddelelse, der som minimum omfatter det følgende, så det er et gulv og ikke et loft. For websites kræver vilkårene en tydelig og klar meddelelse på hver eneste webside, hvor pixlen bruges, og den skal linke til en forklaring, der kan tre ting. Den skal fortælle, at du må bruge pixels, webbeacons og andre lagringsteknologier fra tredjeparter, inklusive Meta, til at indsamle eller modtage oplysninger fra dine websites, fra andre steder på internettet og fra tredjeparter, inklusive Meta, og at du bruger de oplysninger til at levere målingstjenester og til at målrette og levere annoncer. Den skal fortælle, hvordan brugerne kan fravælge indsamling og brug af oplysninger til annoncemålretning. Og den skal pege på det sted, hvor det valg rent faktisk kan træffes. Formålsleddet i det første punkt er det, en meddelelse uden værdi typisk mangler.

Tre kortere regler oven i. Du må ikke placere en pixel, der er knyttet til din annoncekonto, på websites, du ikke ejer. Meta forbeholder sig ret til at overvåge eller revidere, om du overholder vilkårene. Og Meta kan gemme hændelsesdata i op til to år. Bemærk, hvad det sidste tal er et tal for: det er Metas opbevaring af de data, du sender dem, og ikke en frist for, hvad du selv skal gemme eller slette. Reglerne for din egen opbevaring står i guiden om cookies og GDPR, og de ser helt anderledes ud.

Og så den regel, næsten ingen kender. Vilkårene forbyder dig at dele data med Meta, som du ved eller med rimelighed burde vide kommer fra eller handler om børn under 13 år, som indeholder ukrypterede kontaktoplysninger, som indeholder identifikatorer, Meta ikke tillader, for eksempel cpr-numre eller kreditkortnumre, eller som indeholder eller er baseret på, direkte eller på anden vis, oplysninger om blandt andet helbred og økonomi eller andre kategorier af følsomme oplysninger. Men de går et skridt videre: de navne og kriterier, du vælger til dine hændelser, konverteringer og målgrupper, må ikke afspejle, antyde eller være baseret på de kategorier. Sælger du for eksempel helbredsrelaterede varer, er det altså ikke nok at undlade at sende selve oplysningen. Navnet på hændelsen må heller ikke røbe den.

En sidste ting, når du leder efter vejledning hos Meta selv. Vilkårene henviser videre til Metas egen vejledning om cookie-samtykke. Den side er dateret 24. februar 2021, altså før Consent Mode v2 og før de vilkår, der peger på den, og dens eksempler på national vejledning nævner Irland, Frankrig, Spanien, Storbritannien og Belgien. Danmark er ikke blandt eksemplerne, men siden skriver selv, at listen ikke er udtømmende.

Er Meta din databehandler?

Ikke kun, og det er værd at vide, hvis du er ved at lave din liste over leverandører, der behandler personoplysninger for dig.

Den danske udgave af Metas vilkår deler rollerne i to. For matchning, måling og analyse skriver de, at du instruerer Meta Ireland om at behandle oplysningerne på dine vegne som din databehandler. Men for de hændelsesdata, der handler om, hvad folk gør på dit website, skriver de noget andet. Det gælder en række formål, som ud over at målrette og levere annoncer også omfatter kommercielle og transaktionsmæssige beskeder på Messenger og i andre Meta-produkter, tilpasning af funktioner og indhold, og forbedring og sikring af Metas egne produkter, og for dem at du og Meta Ireland anerkender og accepterer at være fælles dataansvarlige efter databeskyttelsesforordningen.

Fælles dataansvarlige er forordningens eget udtryk, og de to ord trækker en pligt med sig, som ikke står i Metas vilkår. Forordningen siger, at fælles dataansvarlige på en gennemsigtig måde skal fastlægge deres respektive ansvar ved hjælp af en ordning mellem sig, og at det væsentligste indhold af den ordning skal gøres tilgængeligt for de personer, oplysningerne handler om.1

Læg mærke til, at det er to forskellige kilder, der siger de to ting. Metas vilkår placerer rollen; forordningen bestemmer, hvad rollen indebærer. Om Metas eget tillæg opfylder kravet, er der ikke svar på, og ingen dansk myndighedskilde forholder sig til det. Læs mere om databehandleraftaler, og om hvornår du skal have dem, i guiden om cookies og GDPR.

Rækker dit cookiebanner så langt, som du tror?

Her er guidens vigtigste praktiske pointe, og den gælder uanset hvilken platform du kører på: et cookiebanner styrer det, det er koblet til, og ikke nødvendigvis alt det, der ligger på dit site. Butikken og banneret er to forskellige størrelser.

Shopify er et konkret eksempel på princippet, fordi de skriver det selv. Deres eget banner styrer, med deres ord, Shopify-specifikke værktøjer, herunder Shopifys cookies og Shopify-pixels, som hjælper Shopify med at levere tjenester til dig og dine kunder. Om alt det andet skriver de, at har du selv installeret tredjeparts-cookies eller pixels manuelt, eller integreret dem gennem apps, kan det være nødvendigt at bruge et tredjeparts-banner eller tilføje din egen logik, så de respekterer kundens valg. Deres formulering er, at det kan være nødvendigt, ikke at det altid er.

Det gør placeringen afgørende. En pixel, der er lagt ind gennem platformens pixel-manager, kører ifølge Shopify kun, når de nødvendige tilladelser er givet, men det gælder i de markeder, der er sat op til at kræve samtykke, og ikke alle steder. Nye pixels kræver som udgangspunkt tilladelse til både marketing og analytics. En pixel, du selv har klistret ind i temaets kode, ligger ikke det samme sted. Vores læsning af Shopifys formulering er, at den så ikke bliver holdt tilbage af banneret, men Shopify skriver det som noget, der kan være nødvendigt at løse selv, ikke som en konstatering.

Der er en grund til at tage det alvorligt ud over lovgivningen. Shopify skriver selv, at kodestumper kan bruges til at omgå samtykkekrav, at det er i strid med deres handelsbetingelser, og at det kan give dig et juridisk ansvar.

En sidste ting i samme skærmbillede, som er værd at kigge på, mens du er der. Shopify har en indstilling, de kalder Network Intelligence, hvor butikkens kundedata bruges sammen med andre butikkers til blandt andet bedre annoncemålretning. Den kan slås fra, men Shopify oplyser, at ni funktioner så afinstalleres, og at apps, der bliver afinstalleret, ikke kommer tilbage af sig selv, når du slår den til igen.

Hvad kan en pixel i en sandkasse ikke?

Shopify kører app-pixels og custom pixels i det, de kalder en sandkasse: et isoleret miljø, hvor scriptet kun kan se det, sandkassen stiller til rådighed. Det er en sikkerhedsgevinst, og det er samtidig forklaringen på, at et værktøj, du har betalt for, kan sidde og ikke måle noget.

Shopify opregner de begrænsninger, de kender. Sandkassen kan ikke tegne brugerfladeelementer, for eksempel knapper, formularer, bannere eller modaler. Og den kan ikke aflæse siden direkte, hvilket rammer seks ting, de nævner: hændelser aflæst fra siden, metadata aflæst fra siden, brugeroplysninger som mail og telefon aflæst fra siden, klik på udgående links, sidescroll, og klik og musebevægelser til heatmaps.

Der er en begrænsning mere på Shopifys liste over kendte begrænsninger, som rammer målingen hårdere end de andre, og som er nem at overse. Shopify skriver, at automatisk registrering af side-URL'er i den sandkasse, de kalder Lax, indeholder en sandkasse-version og ikke gengiver hovedvinduets adresse præcist. Du kan hente den rigtige adresse fra page_viewed-hændelsen i stedet. Sidder du med rapporter, hvor sidestierne ser forkerte ud, er det her, du skal kigge først.

Har du et heatmap-værktøj, eller et værktøj der plejer at opsnappe mailadresser fra en formular, er det altså ikke gået i stykker. Det får ikke adgang. Shopify skriver, at begrænsningerne kan gøre nogle tredjeparts-pixels uforenelige med sandkassen, og at du skal spørge udbyderen, om deres pixel er kompatibel.

Det gælder også, når du pakker noget ind i Google Tag Manager. Shopify skriver, at du godt kan køre Tag Manager som en custom pixel, men at de tags, den loader, stadig kører inde i Shopifys sandkasse, så de samme muligheder og begrænsninger gælder. Tag Manager er ikke en vej udenom.

Vejen frem er den, Shopify selv peger på, men den dækker kun fire af de seks. Hændelser, metadata, brugeroplysninger og udgående links kan du udgive som egne hændelser i stedet for at lade værktøjet aflæse dem. Sidescroll og klik til heatmaps står ikke på den liste, så heatmappet fra før bliver ikke reddet den vej. Shopify tilføjer, at det at udgive egne hændelser ikke nødvendigvis understøttes af alle app-pixels.

Hvilke hændelser skal du måle?

Google kræver ikke en bestemt liste, og Meta gør det heller ikke noget sted i dokumentationen. Google skriver om deres e-handelshændelser, at en typisk opsætning måler hvilke som helst af de nævnte handlinger. Det er ikke en tjekliste, du skal have flueben i hele vejen ned.

Der hvor der er krav, er de til gengæld skarpe. Hos Google er transaction_id påkrævet ved køb og returnering. Hos Meta findes der to slags påkrævede parametre, og forskellen er værd at kende. Purchase er den eneste standardhændelse med ubetinget påkrævede parametre, nemlig currency og value.

Den anden slags er betinget, og betingelsen er let at overse, fordi den står under et Optional. Meta skriver ved AddToCart, at contents er påkrævet for Advantage+ katalogannoncer, og ved ViewContent og Search, at enten contents eller content_ids er påkrævet til samme formål. Purchase har det samme krav oven i sit ubetingede. Advantage+ katalogannoncer er Metas eget navn for annoncer, der trækker på dit produktkatalog. Kører du den slags annoncer, er de felter ikke valgfri for dig, selv om der står Optional i oversigtens første linje.

Googles eget råd er værd at følge, også hvor feltet er valgfrit: sæt hver eneste parameter, du har data til, uanset om den er obligatorisk eller ej. Og sæt valutaen på selve hændelsen, når du sender et beløb.

De to ordforråd overlapper, men de er ikke oversættelser af hinanden. Tabellen viser, hvor de mødes, og hvor de ikke gør.

Et enkelt felt hos Meta er værd at kende, fordi det fejler stille. Sætter du ikke content_type til enten product eller product_group, matcher Meta ifølge deres dokumentation hændelsen mod alle varer, der har det samme id, uanset type.

Hvordan tjekker du, at det virker?

En opsætning, ingen har set efter i sømmene, er en formodning. Begge platforme har et værktøj til at kigge med, og de gør ikke det samme.

Googles hedder Tag Assistant. Fremgangsmåden, som Google selv beskriver den: åbn Tag Assistant, indtast din adresse, hvorefter der åbner en ny fane med butikken. Accepter alt i dit banner. Gå tilbage, find den tidligste consent-hændelse i oversigten, og kontroller i API Call-afsnittet, at alle fire parametre blev sat. Find så den seneste, og kontroller, at de blev opdateret. Alternativt kan du læse kolonnerne On-page Default og On-page Update under fanen Consent.

Der ligger et fingerpeg i selve fejlmeddelelsen. Siger Tag Assistant, at den ikke kunne forbinde, kan det ifølge Google betyde, at dit tag er blokeret fra at loade. Kommer forbindelsen først, når du har accepteret banneret, ved du samtidig noget om, hvordan din opsætning er skruet sammen.

Har du sat regionsspecifikke standardværdier eller bannere op, skal du gentage øvelsen med simuleret placering. Ellers har du kun testet den, du selv sidder i.

Én ting siger Google ikke, og det er værd at vide, før du leder efter en facitliste: hvad den rigtige standardværdi er. De skriver, at det afhænger af din organisations egne retningslinjer. Værktøjet kan altså vise dig, hvad der sker, men ikke afgøre, om det er det rigtige.

Metas værktøj har skiftet navn, og det er værd at vide, når du søger efter det. Det hed Meta Pixel Helper og hedder nu Meta Ads Data Advisor, og Meta skriver selv, at udvidelsen er gratis. Meta skriver, at udvidelsen opdaterer sig selv, og at de eksisterende diagnosefunktioner virker videre. Den kræver Google Chrome, og din annonceblokering skal være slået fra, for at den kan se pixels og hændelser. Du behøver ikke logge ind for at bruge den grundlæggende fejlsøgning; det er opsætnings- og automatiseringsdelen, der kræver login og administratoradgang.

Test en hændelse ved at gå til siden, slå annonceblokeringen fra, klikke på ikonet og derefter udføre selve handlingen, for eksempel lægge en vare i kurven. Punktet Show all events viser hændelser på tværs af hele browsersessionen og ikke kun den aktuelle side, hvilket er det, du skal bruge til at følge et køb over flere sider.

Vær opmærksom på, hvad du giver adgang til. Meta opregner selv de rettigheder, udvidelsen beder om, og en af dem beskriver de som at læse og ændre alle dine data på alle websites, så Meta kan handle på dine vegne på tredjeparts-sites. Beskrivelsen er Metas egen. Om du vil give den adgang, er dit valg.

Til sidst det problem, der opstår, netop når man gør det, Meta anbefaler. Meta anbefaler at køre Conversions API ved siden af pixlen, og så bliver det samme køb sendt to gange. I den situation skriver Meta, at du skal sætte deduplikering op. Den anbefalede måde er at give de to hændelser samme id: pixlens eventID skal matche serverens event_id, og navnene skal matche hinanden. Hos pixlen er eventID det fjerde argument i kaldet.

To tal og et forbehold er værd at kende. Vinduet er 48 timer: kommer den anden hændelse senere end det, bliver de to ifølge Meta ikke slået sammen. Sender du ikke den samme hændelse begge veje, behøver du ikke sætte deduplikering op for den. Og Meta skriver, at de som regel foretrækker den hændelse, der kom først, når de to ikke adskiller sig væsentligt. Som regel er ikke det samme som altid.

Hvilke råd er der ikke kilder til?

Fast afsnit i guiderne. Det er længere end sædvanligt her, fordi emnet er teknisk og fyldt med tal, ingen kan dokumentere.

Hvor stor en andel af danske kunder der siger ja til cookies. Det er formentlig det mest efterspurgte tal på hele området, og det står ikke i nogen kilde her. De tal, der cirkulerer, kommer typisk fra leverandører af samtykkeløsninger, og en leverandørs eget tal om sit eget marked er ikke belæg.

Om Googles avancerede opsætning må bruges i Danmark. Ingen dansk kilde forholder sig til, at der sendes cookieløse pings, når kunden har sagt nej. Her står altså, hvad der sker, men ikke om det er i orden.

Hvad der sker med data, når de forlader EU. Både Google og Meta behandler data uden for Danmark. Emnet er stort og rent juridisk og hører hjemme et andet sted end i en guide om måleopsætning. Det er ladt ligge frem for at blive nævnt i en halv sætning i forbifarten.

Hvordan platformenes samtykkebegreber oversættes til hinanden. Shopifys samtykke-API arbejder med fire formål: præferencer, analyse, marketing og salg eller deling af data. Googles Consent Mode arbejder med sine samtykketyper, hvoraf fire er dem, du møder i praksis. De to sæt ligner hinanden nok til, at det er fristende at parre dem, og ingen kilde gør det. Derfor står parringen heller ikke her.

Hvad der virker bedst. Ingen af dokumentationssiderne indeholder tal for, hvad en bestemt måleopsætning gør ved dine resultater. Møder du sådan et tal, så se efter, om det kommer fra leverandørens dokumentation eller fra deres markedsføringsmateriale. Det er sjældent det samme sted.