Policy för användarmedgivande inom EU

Felsökning av implementering av TCF v2.0

Respitperioder och felsökningsförslag

IAB Europe har lanserat version 2.0 av Transparency and Consent Framework som har utvecklats av IAB Tech Lab och några av dess medlemsföretag. Google har nu fullt stöd för TCF v2.0.

För att ge utgivarna tid att hantera fel och felkonfigurationer med anledning av IAB Europes Transparency & Consent Framework v2.0 förser Google sina utgivare med en rapport över fel som vi har upptäckt. De får också en respitperiod på 150 dagar så att de har tid att åtgärda eventuella fel.


I den här artikeln hittar du mer information om hur du åtgärdar implementeringsfel från TCF v2.0. Den omfattar bland annat:


Uppdaterade riktlinjer

Uppdateringar

  • 500 ms svarstid för CMP:er: Från och med 9 november 2020 behöver TCF v2.0-CMP:er inte längre svara på Ad Manager-, AdSense- och AdMob-förfrågningar inom 500 ms. Ad Manager, AdSense och AdMob inväntar nu svar på obestämd tid från den CMP du väljer att implementera.

Åtgärder för vanliga fel

Felsök några av de vanligaste felen i Ad Manager, AdSense och AdMob genom att göra följande:

Överväg att inhämta samtycke från användare igen för TC-strängar som inte genererar intäkter
(Fel 1.1, 3.1, 4.1, 5.1, 5.2 och 6.1)

Relaterade fel

Fel 1.1.Denna riktlinje kan även tillämpas på fel3.1.4.1.5.1.5.2 och 6.1.

Uppdaterade riktlinjer

Överväg att inhämta samtycke från användarna igen.

Förklaring

Utgivare gynnas av att inhämta samtycke igen om de tidigare använt ”out-of-band”-omfattning i hela världen, ogiltiga CMP-id:n (från testning), ogiltiga GVL-id:n (från testning) eller om de tidigare saknade Google som leverantör med korrekt samtycke vid implementeringen.

Fel 1.1, 1.2, 1.3: Det är viktigt att kontrollera om de här felen utgör en betydande trafikvolym. I så fall kan problemet finnas på CMP-sidan. Se till att Google beviljas åtkomst för de syften som krävs och anges som leverantör av samtycke OCH berättigat intresse (leverantörs-id 755).

IAB-specifikation

Enligt IAB:s specifikationer kan CMP:er cachelagra samtyckessträngar i 13 månader.

Vissa CMP:er har felaktigt behållit det första samtyckesdatumet och utökat det. Samtyckesdatumet ska alltid vara det nya datumet för en samtyckessträng.
Förslag: Se till att din CMP returnerar anrop från AddEventHandler inom 500 ms
(Fel 2.1a, 2.1b, 2.2a, 2.2b och 2.2c)

Relaterade fel

Fel 2.1a. Denna riktlinje kan även tillämpas på fel 2.1b, 2.2a, 2.2b och 2.2c.

Uppdaterade riktlinjer

Även om det inte längre finns något krav på tidsgräns rekommenderar vi att du noga granskar CMP:ns implementeringar för att säkerställa att den omedelbart returnerar anrop till AddEventListener getTCData.

Om en CMP inte svarar kan det leda till att intäkter från begäran uteblir.

Förklaring

Google följer IAB-specifikationen som anger att en CMP ska svara omedelbart på funktionen AddEventListener. Om en CMP inte svarar omedelbart kan det leda till att intäkter från begäran uteblir.

Dessutom är CMP-svar en del av den händelsekedja som påverkar hur snabbt en annonsbegäran kan göras. Kortare tid mellan sidhämtningen och annonsbegäran resulterar i färre förlorade exponeringar för utgivaren.

IAB-specifikation

Tillämpliga IAB-specifikationer: IAB AddEventListener-specifikationen (på GitHub)

AddEventListener-återanropet bör göras omedelbart vid registreringen med aktuell TC-data, även om CMP-statusen läses in och CMP:n har ofullständig TC-data. Detta gör att anropsskriptet får åtkomst till det registrerade lyssnar-id:t (listenerId). För varje ändrad TC-sträng måste återanropen ske med RemoveEventListener, om inte strängen tas bort.

Felrapport

Vi meddelar utgivarna i produktgränssnittet om vi upptäcker problem i den TC-sträng som är kopplad till en eller flera av deras webbplatser eller appar. Utgivare med fel kan klicka på Ladda ned TCF-felrapport på sidan Användarsamtycke i EU i sitt konto för att ladda ned en detaljerad rapport över de fel som har identifierats under de senaste sju dagarna.

Rapporten är bara tillgänglig om fel upptäckts under de senaste sju dagarna.
Så här öppnar du sidan Användarsamtycke i EU och TCF-felrapporten:
  • Ad Manager: Klicka på Administratör and then Användarsamtycke i EU.
  • AdMob och AdSense: Klicka på Blockeringskontroller and then Användarsamtycke i EU.

Rapporten innehåller följande information om varje enskilt identifierat fel: 

  • Domän/MobileAppID: den felkonfigurerade webbplatsen eller appen
  • Sökväg till annonsenhet: annonsenheten som är kopplad till felet.
  • Felkod: koden för felet.
  • Antal fel: antalet sökfrågor som innehåller felet som observerades under föregående vecka
  • Datum för senaste identifiering: det senaste datum då felet identifierades 

Utgivarna kan använda felkoderna i rapporten för att hitta förslag på åtgärder i följande felsökningstabeller och korrigera felen.

Respitperiod

Respitperioden varierar något beroende på vilken typ av fel som åtgärdas. Följande tabell definierar de olika respitperioderna och när de tillämpas.

Respitperioden har förlängts med ytterligare 60 dagar och upphör nu i mitten av januari 2021.
Behandling vid respitperiod Översikt
Respitperiod 0: Felkonfiguration

Avsedd att lösa vanliga situationer där utgivare har felkonfigurerat sina CMP:er och inte lyckats skicka en giltig TC-sträng. Utgivarna har 60 dagar på sig att använda GDPR-kontrollerna för annonsteknikleverantörer för att åtgärda felkonfigurationer utan att det påverkar intäktsgenereringen. Efter 60 dagar visar Google icke-anpassade annonser under resten av respitperioden.

Dessa fel har alltid företräde framför andra typer av fel, även om en viss begäran innehåller flera fel.

Respitperiod 0 tillämpas i följande situationer:

  • Under de första 60 dagarna av respitperioden kan utgivarna åtgärda problem med felkonfigurationer utan att det påverkar intäktsgenereringen.
  • Under resten av respitperioden visas icke-anpassade annonser oavsett befintliga inställningar för anpassade annonser och icke-anpassade annonser.

När respitperioden har löpt ut tillgodoses inga annonsförfrågningar.

Respitperiod 1: Problem med TC-strängen

Avsedd att åtgärda stora brister i TC-strängen. Google visar bara icke-anpassade annonser (IAA) under respitperioden.

Respitperiod 1 tillämpas på denna kategori när det finns problem med den TC-sträng som är kopplad till en annonsbegäran. Annonsförfrågningar tillgodoses med icke-anpassade annonser under respitperioden. När respitperioden har löpt ut tillgodoses inga annonsförfrågningar.

Respitperiod 2: Samtycke måste inhämtas igen

Avsedd för utgivare som integrerar med TCF v2.0 innan Google har lagts till på IAB:s lista över globala leverantörer (GVL). Utgivarna har inhämtat samtycke för Google från användare utanför TCF v2.0 före Googles integrering. Nu när Google har lanserat integreringen officiellt måste samtycke inhämtas igen från dessa användare i enlighet med TCF v2.0. Utgivarna kan välja när de ska göra detta under respitperioden.

Respitperiod 2 tillämpas när samtycke måste inhämtas från användaren. Om en användare har gett sitt samtycke för mer än 13 månader sedan bör du använda denna respitperiod för att inhämta användarens samtycke igen.

Under denna respitperiod visas befintliga anpassade och icke-anpassade annonser med befintliga inställningar utan att det påverkar intäktsgenereringen, inklusive kontroller för annonsteknikleverantörer för anpassade annonser. När respitperioden har löpt ut tillgodoses inga annonsförfrågningar.

Respitperiod 3: Global omfattning eller out-of-band-omfattning

Avsedd att korrigera TC-strängar med global omfattning eller out-of-band-omfattning (Ad Manager, AdMob, AdSense). Google visar annonser för dessa annonsförfrågningar i enlighet med TC-strängen och Googles policyer, men utgivarna bör utnyttja respitperioden för att åtgärda problemet.

Under respitperioden visas annonser för dessa annonsförfrågningar i enlighet med TC-strängen och Googles policyer. Efter respitperioden på 150 dagar visar vi inte en annons om TC-strängen indikerar out-of-band-omfattning eller global omfattning.

 

Felsökning

För att hjälpa utgivarna att åtgärda felkonfigurerade IAB TCF v2.0-integreringar har vi sammanställt följande tabeller över de vanligaste feltyperna för TC-strängar och motsvarande rekommendationer för felsökning. Du bör även använda tabellerna för att avgöra vilken respitperiodsvariant (om tillämpligt) som gäller för ett fel.

Använd följande tabeller för att se vilka problem som kan uppstå på annonsbegärannivå och motsvarande systembeteende.

Ingen respitperiod, annonser visas inte

Dessa scenarier leder alltid till förlorade och icke tillgodosedda annonsförfrågningar. De har heller inte någon respitperiod. De har alltid företräde framför andra typer av fel, även om det finns flera fel i en viss begäran.

Scenario Beskrivning Föreslagen åtgärd
1.1 Google tillåts inte som leverantör enligt samtycke eller berättigat intresse. Bekräfta om användaren har avvisat Google som leverantör avsiktligt, om det har inträffat problem med CMP-implementeringen eller om det förekommer begränsningar för utgivare.
1.2 Inget samtycke för ändamål 1 för länder i EES och Storbritannien.

Bekräfta om användaren har avvisat ändamål 1 avsiktligt eller om det beror på fel med CMP-implementeringen.

Utgivare i Tyskland ska säkerställa att de ställer in fälten PublisherCC och PurposeOneTreatment på rätt sätt om de inte inhämtar samtycke från användarna.
1.3 Har gett samtycke till ändamål 1 men saknar rättslig grund för grundläggande annonser.

Bekräfta om användaren har avvisat berättigade intressen avsiktligt för övriga ändamål eller om det beror på fel med CMP-implementeringen.

Respitperiod 0: Felkonfiguration

Följande gäller när respitperiod 0 tillämpas:

  • Under de första 60 dagarna av respitperioden kan utgivarna åtgärda problem med felkonfigurationer utan att det påverkar intäktsgenereringen.
  • Under resten av respitperioden visas icke-anpassade annonser oavsett befintliga inställningar för anpassade och icke-anpassade annonser.

När respitperioden har löpt ut tillgodoses inga annonsförfrågningar.

Fel Beskrivning Föreslagen åtgärd
2.1a Taggen eller SDK:t tar inte emot en TC-sträng på grund av att CMP-statusen är stub, loading eller error.

Om du manuellt anropar funktionen för att begära annonser måste getTCData TCData.eventStatus = 'tcloaded ELLER 'cmpuishows' + 'useractioncomplete' returneras. Dessa anger att CMP:n är redo att tillhandahålla en mekanism för användarsamtycke.

Om du inte anropar funktionen för att begära annonser manuellt kan du samarbeta med CMP-leverantören för att säkerställa att de implementerar stöd för getTCData. De måste även returnera TCData.eventStatus = 'tcloaded' ELLER 'cmpuishows' + ' useractioncomplete för att indikera att mekanismen för användarsamtycke är tillgänglig via API:et.

2.1b

Båda villkoren är uppfyllda:

  • CMP:er har angetts till &gdpr=1.
  • &gdpr_consent= finns i begäran men TC-strängen är tom.
Be CMP-leverantören kontrollera att API:erna är korrekt implementerade baserat på IAB TCF:s tekniska specifikationer.
2.2a

TC-strängen kan inte tolkas eftersom den inte är base64-kodad.

Exempel: “2”

CMP:er (eller utgivare) ska endast skicka base64-kodad data i gdpr_consent=-parametrar.
2.2b

TC-strängen kan inte tolkas på grund av ett avkodningsfel.

Exempel: Innehåller ett felaktigt antal bitar

CMP:n bör åtgärda implementeringsfelen i TC-strängen.
2.2c

TC-strängen kan inte tolkas på grund av ett datafel.

Exempel: Felaktig tidsstämpel, leverantörs-id är för stort
 

CMP:n bör åtgärda implementeringsfelen i TC-strängen.

Respitperiod 1: Problem med TC-strängen

Respitperiod 1 tillämpas på denna kategori när det finns problem med den TC-sträng som är kopplad till en annonsbegäran. Annonsförfrågningar tillgodoses fortsättningsvis med icke-anpassade annonser med befintliga inställningar under respitperioden. När respitperioden på 150 dagar är över avvisas annonsförfrågningar och tillgodoses inte längre.

Fel Beskrivning Föreslagen åtgärd
3.1 Ogiltigt CMP-id

Kontrollera att en IAB-verifierad CMP används och att id:t är korrekt angivet i TC-strängarna.

Om en CMP var giltig när TC-strängen genererades men senare raderades av IAB måste du inhämta samtycke igen via en giltig CMP.

3.2 Datumet då TC-strängen skapades inföll för mer än 13 månader sedan. CMP:n bör radera den gamla TC-strängen och inhämta samtycke igen.
3.3 Datumet då TC-strängen senast uppdaterades inföll för mer än 13 månader sedan. CMP:n bör radera den gamla TC-strängen och inhämta samtycke igen.

Respitperiod 2: Samtycke måste inhämtas igen

Respitperiod 2 tillämpas när samtycke måste inhämtas från användaren. Om en användare gav sitt samtycke för mer än 13 månader sedan eller innan Google kom med på GVL bör du utnyttja denna respitperiod för att inhämta användarens samtycke igen.

Under denna respitperiod visas befintliga anpassade och icke-anpassade annonser med befintliga inställningar utan att det påverkar intäktsgenereringen, inklusive kontroller för annonsteknikleverantörer för anpassade annonser. När respitperioden på 150 dagar är över avvisas annonsförfrågningar och tillgodoses inte längre.

Fel Beskrivning Föreslagen åtgärd
4.1 TC-strängen genererades med en version av GVL som inte inkluderat Google ännu. Inhämta samtycke igen med den uppdaterade versionen av GVL som nu inkluderar Google.

Respitperiod 3: Global omfattning och out-of-band-omfattning

Respitperiod 3 tillämpas när det finns problem som rör den globala omfattningen och out-of-band-omfattningen (Ad Manager, AdMob, AdSense).

Under respitperioden visas annonser för dessa annonsförfrågningar i enlighet med TC-strängen och Googles policyer. Efter respitperioden på 150 dagar visar vi inte en annons om TC-strängen indikerar out-of-band-omfattning eller global omfattning.

Fel Beskrivning Föreslagen åtgärd
5.1 TC-strängen tillåter out-of-band-samtycke. Instruera CMP:n att ta bort out-of-band-signaler från TC-strängarna.
5.2 TC-sträng med global omfattning. Instruera CMP:n att uppdatera TC-strängarna så att de är tjänstspecifika.

Ingen respitperiod, annonser fortsätter visas

Ingen respitperiod tillämpas. Anpassade och icke-anpassade annonser fortsätter visas med befintliga inställningar utan att det påverkar intäktsgenereringen.

Fel Beskrivning Föreslagen åtgärd
6.1 TC-strängversionen är 1 eller 1.1 (v1.0-sträng). CMP:n bör skicka TCF v2.0-strängar.

Ingen respitperiod, Google hanterar problem

När dessa problem uppstår korrigerar Google effekten av problemet vid behov och fortsätter med normal TCF-hantering.

Fel Beskrivning Föreslagen åtgärd
7.1 gdprApplies är odefinierat eller inställt på ett ogiltigt eller ej tolkningsbart värde, men det finns en giltig TC-sträng. Inte tillämpligt
7.2 TC-strängen genererades med en GVL-version som är senare än den nuvarande versionen som Googles annonsvisningsteknik kan identifiera. Inte tillämpligt
7.3 Vissa ändamål, funktioner och/eller leverantörer är utanför intervallet (okända). Inte tillämpligt
7.4 TC-strängen har en äldre tcf_policy_version än den senaste versionen av GVL. CMP:n bör radera den äldre TC-strängen och inhämta samtycke igen med den senaste versionen av GVL.
7.5

En begäran har &gdpr=1 men saknar parametern &gdpr_consent i webbadressen för begäran.

Inte tillämpligt
7.6 Ogiltig landskod för utgivare, men samtycke till ändamål 1 finns.  CMP:n bör åtgärda implementeringsfelen i TC-strängen.
7.7 Ogiltig språkkod. CMP:n bör åtgärda implementeringsfelen i TC-strängen.
7.8 Fältet för TC-strängversionen är varken 1 eller 2. CMP:n bör skicka TCF v2.0-strängar.
7.9 AC-strängversionen är inte 1. CMP:n bör ange AC-strängversionen till 1.

Ingen respitperiod, problem med AC-sträng

När dessa problem uppstår hanterar Google AC-strängen (Additional Consent) som ogiltig och inga ytterligare leverantörer övervägs efter TC-strängen.

Fel Beskrivning Föreslagen åtgärd
8.1 AC-strängen använder inte versionsavgränsaren (~). CMP:n bör använda ”~” som andra tecken i AC-strängen och avgränsa versionsnumret från listan över leverantörer som gett sitt samtycke.
8.2 AC-strängen innehåller en leverantörlista som inte följer förväntad formatering (listan över int64s avgränsas med ”. ”). CMP:n bör åtgärda implementeringsfel i AC-strängen.

 

Var det här till hjälp?
Hur kan vi förbättra den?

Behöver du mer hjälp?

Logga in för ytterligare supportalternativ så att du kan lösa problemet snabbt