IAB представи най-новия си стандарт през септември: IAB GPP. Тук обясняваме какво стои зад него, как се използва и защо GPP се превръща в заместител на IAB TCF v3.
IAB TCF v2 като основа
В Европа стандартът IAB TCF v1 е мярката за всички неща от 2018 г., когато става въпрос за предаване на съгласие от уебсайтове към други участници на пазара (обикновено рекламодатели). През 2020 г. беше пусната нова версия с IAB TCF v2, която донесе различни подобрения. Оттогава обаче се случиха много неща и бяха добавени много нови изисквания, които не са внедрени в TCF v2. Това включва:
- TCF е под критика в Белгия във връзка с различни фактори. Технически е необходима актуализация, за да може да отговори на новите изисквания на властите
- От TCF v2, използването на TCF се промени от една страна (виждаме много повече случаи на ограничения на издателите), от друга страна много нови доставчици бяха включени в GVL на IAB („Глобален списък на доставчици“). И двете гарантират, че низът за съгласие нараства и по този начин все повече се превръща в проблем.
В допълнение към Европа, редица други региони вече са толкова напреднали, че има нужда от единен стандарт за съгласие. След Европа и Калифорния е необходимо да се излъчват съответните сигнали и за Канада, Вирджиния, Колорадо, Юта и Кънектикът от 1 януари 2023 г. Може също да се предположи, че в близко бъдеще ще последват и други региони. TCF обаче е предназначен само за Европа (GDPR) и простото му копиране всеки път няма да бъде устойчиво за доставчиците в дългосрочен план. Поради това е необходимо ново решение, което да адресира проблемите на TCF, от една страна, и да е достатъчно гъвкаво и широкообхватно, за да бъде осъществимо за много нови региони, от друга.
Глобална платформа за поверителност
Отговорът на горните проблеми вече е GPP или Global Privacy Platform. GPP, част от IAB Tech Lab, е предимно техническа спецификация, а не изрично „политика“. По-специално, той регулира как е структуриран „низът за съгласие“, кои API са налични и как CMP, издателите и доставчиците взаимодействат помежду си. Въпреки това, вместо да указва фиксиран ред, както при TCF, GPP дефинира само „конструктивен комплект“ от елементи, от които след това могат да се използват регионалните спецификации. Така че, ако регион иска да предложи ново техническо решение утре, той може да го направи много лесно на базата на GPP – без да се налага да пише огромни и обширни технически спецификации. Всичко, което регионът трябва да направи, е да създаде политика („Правилата“) и да напише Manfist. Последният регулира техническата структура на информацията и автоматично служи като основа за всички GPP функции.
Фибоначи към компресия
Един от основните проблеми на IAB TCF v2 (Европа) е нарастващият размер на низовете за съгласие, наричани още TCString. Докато низът за съгласие „всичко е отхвърлено“ обикновено е дълъг само около 60 знака, низът за съгласие „всичко е прието“ може да бъде с дължина 300 или 500 знака. Ако списъкът с доставчици на уебсайта е много дълъг или има ограничения на издателя, TCString може също да бъде с дължина няколко килобайта (т.е. хиляди знака). Такива дълги низове забавят скоростта на зареждане на уеб страницата, причиняват проблеми с паметта и в някои случаи дори могат да причинят уеб страниците да станат недостъпни.
Решението на проблема се нарича Фибоначи. Около 1202 г. италианският математик създава математическа последователност, която може да се използва за просто описание на числа. Прехвърлени към днешните компютърни системи, числовите поредици в крайна сметка се използват за компресиране: вместо много дълги битови вериги с IAB TCF v2, GPP просто компресира числови поредици с числа на Фибоначи в много къси битови поредици. И резултатът е впечатляващ: докато дължината на низовете за отхвърляне на съгласие остава повече или по-малко същата, тя се свива със 70% в някои случаи, особено в случай на дълги низове за съгласие. Низ за съгласие на IAB TCF, който преди беше дълъг 1000 знака, можеше да бъде представен с GPP само с около 300 знака.
IAB TCF Канада и щатите на САЩ като първи тест
Канада ще бъде първият регион, който ще използва новия GPP стандарт. IAB TCF Canada се обслужва изключително чрез GPP: Ако издател или доставчик иска да използва сигналите за канадския пазар, той (само) трябва да внедри GPP. Въпреки че TCF Канада до голяма степен е копие 1:1 на IAB TCF v2 (Европа), той се различава технически по отношение на пътя за достъп и кодирането.
В допълнение към Канада, нови закони за защита на данните също ще влязат в сила или ще бъдат приложени от властите в различни американски щати на 1 януари 2023 г. В допълнение към IAB TCF Канада, IAB вероятно ще публикува допълнителни GPP спецификации за Колорадо, Юта или Вирджиния този месец.
мениджър за съгласие и GPP
Екипът на ConsentManager изигра ключова роля в развитието на GPP. Например главният изпълнителен директор на consentmanager, Ян Винклер, е основният разработчик зад техническата спецификация на GPP в IAB и следователно отговаря за дизайна и внедряването на новия стандарт в IAB. Никой друг CMP не е имал толкова силно въздействие върху новия стандарт. Това е особено предимство за клиентите на consentmanager: тъй като всички технически спецификации на IAB трябваше да бъдат тествани предварително, consentmanager вече разполага с всички компоненти, които ще съставляват GPP в бъдеще. следователно consentmanager ще бъде първият CMP, който напълно поддържа новия стандарт. Клиенти, които искат да използват GPP за Канада, Колорадо, Юта, Вирджиния, Кънектикът или Европа, могат да го направят от нашата актуализация през октомври. клиентите на consentmanager са (за пореден път) месеци пред всички други доставчици и по този начин могат да си осигурят по-добра пазарна позиция.
