Der IAB hat im September seinen neusten Standard vorgestellt: IAB GPP. Was sich dahinter verbirgt, wie er eingesetzt wird und warum GPP der Ersatz für IAB TCF v3 wird, erklären wir hier.
IAB TCF v2 als Grundlage
In Europa ist seit 2018 der IAB TCF v1 Standard das Maß der Dinge wenn es um die Übermittlung der Zustimmung von Webseite zu anderen Marktteilnehmern (üblicherweise Werbetreibende) geht. In 2020 wurde dann mit IAB TCF v2 eine neue Version verabschiedet, die diverse Verbesserungen mit sich brachte. Seitdem hat sich jedoch viel getan und es sind viele neue Anforderungen hinzu gekommen, die so vom TCF v2 nicht umgesetzt sind. U.a. gehört dazu:
- Das TCF ist in Belgien in der Kritik in Bezug auf diverse Faktoren. Technisch braucht es daher ein Update um die neuen Anforderungen der Behörden erfüllen zu können
- Seit TCF v2 hat sich einerseits die Nutzung des TCF geändert (wir sehen viel mehr Fälle von Publisher Restrictions), andererseits sind viele neue Vendoren in die GVL („Global Vendor List“) des IAB aufgenommen worden. Beides sorgt dafür, dass der Consent String wächst und damit zunehmend zu einem Problem wird.
Neben Europa sind mittlerweile zudem noch einige weitere Regionen so weit, dass der Bedarf nach einem einheitlichen Consent-Standard besteht. Nach Europa und Californien ist es ab 01.01.2023 auch nötig entsprechende Signale für Kanada, Virginia, Colorado, Utha und Connecticut zu verbreiten. Zudem ist davon auszugehen, dass in kurzer Zeit weitere Regionen folgen werden. Das TCF ist aber nur für Europa (DSGVO) ausgelegt und es einfach jeweils zu kopieren wird auf Dauer nicht tragbar für Anbieter. Daher bedarf es einer neuen Lösung, die einerseits die Probleme des TCF angeht und andererseits flexibel und breit genug ist, um für viele neue Regionen umsetzbar zu sein.
Global Privacy Platform
Die Antwort auf die oben genannten Probleme ist nun GPP oder Global Privacy Platform. GPP, Teil des IAB Tech Lab, ist in erster Linie eine technische Spezifikation und explizit keine „Policy“. Es regelt insbesondere wie der „Consent String“ aufgebaut wird, welche APIs zur Verfügung stehen und wie CMPs, Publisher und Vendoren miteinander agieren. Statt wie beim TCF jedoch eine feste Ordnung vorzugeben, definiert GPP nur einen „Baukasten“ an Elementen aus denen sich die Regionalen Spezifikationen dann bedienen können. Möchte morgen also eine Region eine neue technische Lösung anbieten, kann sie das auf Basis von GPP sehr einfach tun – ohne dazu riesige und umfangreiche eigene technische Spezifikationen schreiben zu müssen. Alles was die Region tun muss, ist eine Policy (die „Regeln“) zu erstellen und ist ein sogenanntes Manfist zu schreiben. Letzteres regelt den technischen Aufbau der Informationen und dient automatisch als Grundlage für alle GPP Funktionen.
Fibonacci zur Kompression
Eines der Haupt-Probleme des IAB TCF v2 (Europa) ist die wachsende Größe der Consent Strings, auch TCString genannt. Ist ein „Alles abgelehnt“ Consent String typischerweise nur um die 60 Zeichen lang, kann ein „Alles Akzeptiert“ Consent String gern mal 300 oder 500 Zeichen lang sein. Ist die Anbieterliste der Webseite sehr lang oder kommen noch Publisher Restrictions hinzu, kann ein TCString auch gern mal einige Kilobyte (also tausende an Zeichen) lang sein. Derartig lange Zeichenfolgen verlangsamen die Webseitenladegeschwindigkeit, führen zu Speicherproblemen und können in einigen Fällen sogar dazu führen, dass Webseiten nicht mehr erreichbar sind.
Die Lösung zu dem Problem heisst Fibonacci. Der Italienische Mathematiker erdachte um das Jahr 1202 eine mathematische Folge, mit der Zahlen einfach beschrieben werden können. Auf die heutigen Computersysteme übertragen, dienen die Zahlenfolgen letztlich der Kompression: Statt vieler langer Bit-Ketten beim IAB TCF v2, komprimiert das GPP Zahlenfolgen ganz einfach mit Fibonacci-Zahlen in sehr kurze Bit-Sequenzen. Und das Ergebnis kann sich sehen lassen: Während bei Ablehnen-Consent-Strings die Länge quasi gleich bleibt, schrumpft sie insbesondere bei langen Consent Strings um teilweise 70%. Ein IAB TCF Consent String der zuvor 1000 Zeichen lang war, könnte mit GPP also mit nur etwa 300 Zeichen dargestellt werden.
IAB TCF Canada und US-Bundesstaaten als erste Bewährungsprobe
Als erste Region wird Kanada den neuen GPP Standard einsetzen. Das IAB TCF Canada wird dabei ausschließlich über GPP bedient: Will ein Publisher oder Vendor die Signale für den Kanadischen Markt verwenden, muss er (nur) GPP implementieren. Obwohl das TCF Canada weitestgehend eine 1:1 Kopie vom IAB TCF v2 (Europa) ist, unterscheidet es sich also technisch durch den Zugangsweg und die Codierung.
Neben Kanada, werden zum 01.01.2023 auch in diversen US-Bundesstaaten neue Datenschutzgesetze in Kraft treten bzw. von den Behörden umgesetzt werden. Neben dem IAB TCF Canada, wird das IAB daher vermutlich noch in diesem Monat weitere GPP-Spezifikationen für Colorado, Utha oder Virginia heraus geben.
consentmanager und GPP
Das Team von consentmanager hat bei der Entwicklung von GPP eine tragende Rolle gespielt. So ist etwa der consentmanager CEO, Jan Winkler, der Haupt-Entwickler hinter der technischen Spezifikation von GPP beim IAB und ist damit an forderster Front für das Design und die Umsetzung des neuen Standards beim IAB verantwortlich. Kein anderes CMP hat einen derart starken Einfluss auf den neuen Standard gehabt. Für consentmanager-Kunden ist das von besonderem Vorteil: Da alle technischen Spezifikationen des IAB zuvor getestet werden mussten, existieren bei consentmanager bereits alle Bausteine die das GPP künftig aus macht. consentmanager wird daher das erste CMP, welches den neuen Standard vollständig unterstützen wird. Kunden die GPP für Kanada, Colorado, Utha, Virginia, Conneticut oder auch Europa einsetzen möchten, können dies bereits seit unserem dem Oktober-Update tun. consentmanager-Kunden sind damit (wieder einmal) allen anderen Anbietern um Monate voraus und können sich so eine bessere Marktposition sichern.
