- TCF v2.1: Vi fortsätter att ta emot TCF v2.1-strängar, men uppmuntrar CMP:er att följa IAB-vägledning om implementeringsmilstolpar när branschen går över till TCF v2.2.
- Googles lösningar för samtyckeshantering: Googles lösningar för samtyckeshantering, som finns på fliken Integritet och meddelanden i Ad Manager, AdSense och AdMob, planerar att stödja TCF v2.2 för samtyckesmeddelanden för GDPR senast i början av november, i enlighet med IAB:s uppdaterade slutdatum för implementering av CMP:er den 20 november 2023.
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 denna artikel hittar du mer information om hur du åtgärdar fel i implementeringen av TCF v2.2. Den omfattar bland annat:
Uppdaterade riktlinjer
Nyheter
- Påminnelse om TCF-kravet att inhämta nytt samtycke var 13:e månad:
You are required by IAB TCF policy to remind users about their consent choices at least once every 13 months. If the consent decision is more than 13 months old, the TC string will no longer be considered valid by Google and Google will not serve ads to that user. We suggest that you work with your CMP to remind users about their consent choices before the 13-month limit is reached.
- Feltypen 3.2 har tagits bort. TC-strängar som har uppdaterats under de senaste 13 månaderna förblir giltiga.
Åtgärder av 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 nytt samtycke från användare med TC-strängar som inte genererar intäkter(Fel 1.1, 3.1, 4.1, 5.1, 5.2 och 6.1)
Relaterade fel
Uppdaterade riktlinjer
Överväg att inhämta nytt samtycke från användare.
Förklaring
Utgivare gynnas av att inhämta nytt samtycke om de tidigare har använt ”out-of-band”-omfattning i strängar med global räckvidd, ogiltiga CMP-id:n (från testning), ogiltiga GVL-id:n (från testning) eller har saknat Google som leverantör med korrekt samtycke vid något tillfälle under implementeringen.
Fel 1.1, 1.2, 1.3: Det är viktigt att kontrollera om dessa fel 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 får CMP:er cachelagra samtyckessträngar i 13 månader.
AddEventHandler inom 500 ms(Fel 2.1a, 2.1b, 2.0a, 2.0b och 2.0c)
Relaterade fel
Fel 2.1a. Denna riktlinje kan även tillämpas på fel 2.1b, 2.0a, 2.0b och 2.0c.
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.
CMP-svar utgör dessutom en del av den händelsekedja som påverkar hur snabbt en annonsbegäran kan göras. Kortare tid mellan sidhämtning 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-bör anropas omedelbart vid registreringen med aktuell TC-data, även om CMP-statusen är loading 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 ändring av TC-strängen måste återanropsfunktionen anropas om den inte tas bort med RemoveEventListener.Policycenter
I policycentret meddelas utgivare om en app eller webbplats inte följer Googles krav på samtyckeshantering.
Felrapport
Vi meddelar utgivarna via 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.
- Ad Manager: Klicka på Administratör
Användarsamtycke i EU.
- AdMob och AdSense: Klicka på Blockeringskontroller
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: senaste datumet då felet identifierades
Utgivare kan använda felkoderna i rapporten för att hitta förslag på åtgärder i följande felsökningstabeller och korrigera felen.
Felsökning
För att hjälpa utgivare att åtgärda felkonfigurerade IAB TCF v2.2-integreringar har vi sammanställt följande tabeller över de vanligaste feltyperna för TC-strängar och motsvarande felsökningsrekommendationer.
Använd tabellerna för att se vilka problem som kan uppstå på annonsbegärannivå och motsvarande systembeteende.
Scenarier med begränsat samtycke
Alla dessa tre scenarier har alltid företräde framför fel som beror på felaktig konfiguration, även om en viss begäran innehåller flera fel.
| 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 syfte 1 för länder i EES och Förenade kungariket. |
Kontrollera om användaren avsiktligt har avvisat syfte 1 eller om det har inträffat problem med CMP-implementeringen. Utgivare i Schweiz bör kontrollera att de anger fälten
PublisherCC och PurposeOneTreatment på rätt sätt om de inte inhämtar samtycke från användare. Från och med december 2021 kontrollerar vi inte längre behandling enligt |
| 1.3 | Har gett samtycke till ändamål 1 men saknar rättslig grund för grundläggande annonser. |
Kontrollera om användaren avsiktligt har avvisat berättigade intressen för övriga syften eller om det är problem med CMP-implementeringen. |
Felaktig konfiguration
Annonsförfrågningar tillgodoses inte vid felaktig konfiguration.
| Fel | Beskrivning | Föreslagen åtgärd |
|---|---|---|
| 2.1a | Taggen eller SDK:et 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 Om du inte manuellt anropar funktionen för att begära annonser kan du samarbeta med CMP-leverantören för att säkerställa att de implementerar stöd för |
| 2.1b |
Båda villkoren är uppfyllda:
|
Be CMP-leverantören kontrollera att API:erna är korrekt implementerade baserat på IAB:s tekniska specifikation TCF. |
| 2.0a |
TC-strängen kan inte tolkas eftersom den inte är base64-kodad. Exempel: |
CMP:er (eller utgivare) ska endast skicka base64-kodad data i parametern gdpr_consent=. |
| 2.0b |
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.0c |
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. |
Problem med TC-strängen
Problem med TC-strängen som är kopplad till en annonsbegäran. Annonsförfrågningar avvisas och tillgodoses inte.
| 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 nytt samtycke via en giltig CMP. |
| 3.2 | Har fasats ut. | Ingen. Tidigare innebörd: Datumet då TC-strängen skapades inföll för mer än 13 månader sedan. |
Nytt samtycke måste inhämtas
Användarens samtycke måste inhämtas. Om en användare har gett sitt samtycke för mer än 13 månader sedan eller om du använde en version av GVL som inte inkluderade Google ännu måste du inhämta nytt samtycke från användaren. Annars avvisas annonsförfrågningar.
| Fel | Beskrivning | Föreslagen åtgärd |
|---|---|---|
| 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 nytt samtycke. Ett litet antal av dessa fel kan uppstå om annonsförfrågningar skickas med en TC-sträng som har upphört att gälla innan CMP:n har ogiltigförklarat och inhämtat användarens samtycke igen. Om du använder Googles verktyg för samtyckeshantering och UMP SDK i din app ska du kontrollera att UMP SDK har implementerats korrekt och att |
| 4.1 | TC-strängen genererades med en version av GVL som inte inkluderade Google ännu. | Inhämta samtycke igen med en aktuell version av GVL. |
Global omfattning och out-of-band-omfattning
Problem som rör global omfattning och out-of-band-omfattning (Ad Manager, AdMob, AdSense). Annonser visas inte 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. |
Annonsvisning med maxgräns
Begränsade annonser visas.
| 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.2-strängar. |
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 syften, funktioner och/eller leverantörer är utanför giltigt intervall (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 nytt samtycke med den senaste versionen av GVL. |
| 7.5 |
En begäran innehåller |
Inte tillämpligt |
| 7.6 | Ogiltig landskod för utgivare, men samtycke till syfte 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 åtgärda implementeringsfel i TC-strängen genom att begära nytt samtycke om en ogiltig TC-sträng upptäcks. Om du använder Googles verktyg för samtyckeshantering och UMP SDK i din app ska du kontrollera att UMP SDK har implementerats korrekt och att |
| 7.9 | AC-strängversionen är varken 1 eller 2. |
CMP:n bör ange AC-strängversionen till 1 eller 2. |
Problem med AC-strängen
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 har gett sitt samtycke. |
| 8.2 | AC-strängen innehåller en leverantörslista 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. |