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
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.
(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.
- 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: 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.
| 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:
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 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 |
| 2.1b |
Båda villkoren är uppfyllda:
|
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: |
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 |
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. |
