Dwa różne zadania

Gdy odwiedzający dokonuje wyboru zgody, muszą się wydarzyć dwie osobne rzeczy. Po pierwsze, przeglądarka musi zapamiętać wybór, aby baner nie pojawiał się na każdej stronie, a tagi wiedziały, co im wolno. Po drugie, możesz później musieć udowodnić, że wybór został dokonany, co odwiedzającemu pokazano i kiedy. Te zadania często realizują różne mechanizmy przechowywania, a ich mieszanie powoduje realne problemy: banery, które wciąż wracają, wybory znikające w niektórych przeglądarkach lub brak zapisu, gdy ktoś o niego zapyta.

To porównanie omawia trzy popularne opcje — pliki cookie first-party, pamięć przeglądarki taką jak localStorage oraz rekordy zgody po stronie serwera — i miejsce każdej z nich.

Opcja 1: pliki cookie first-party

Pliki cookie to tradycyjny dom stanu zgody. CMP z TCF zwykle zapisują ciąg zgody w cookie first-party, a wiele CMP zapisuje w nim także własne dane o preferencjach.

Mocne strony

• Czytelne dla serwera. Cookie jest wysyłane z każdym żądaniem, więc kod serwerowy, logika brzegowa i tagowanie po stronie serwera mogą odczytać wybór bez czekania na JavaScript.
• Współdzielone między subdomenami. Cookie ustawione na Twojej domenie rejestrowalnej może obejmować subdomeny www, blog i shop.
• Powszechnie oczekiwane. Wiele integracji ad tech szuka zgody w plikach cookie.

Słabe strony

• Limity rozmiaru. Przeglądarki ograniczają rozmiar cookie do około 4 KB, a ciąg TCF z wieloma dostawcami plus inne wartości mogą się do tego zbliżyć.
• Narzut na żądania. Każde żądanie do Twojej domeny niesie cookie, także żądania obrazów i skryptów.
• Limity czasu życia w niektórych przeglądarkach. Intelligent Tracking Prevention w Safari ogranicza cookies tworzone przez JavaScript do maksymalnego czasu życia siedmiu dni. Cookies ustawiane przez Twój własny serwer w odpowiedzi HTTP są zwykle traktowane łagodniej, choć zdarzają się wyjątki.

Opcja 2: localStorage i inna pamięć przeglądarki

Niektóre CMP zapisują szczegółowe preferencje w localStorage, czasem obok mniejszego cookie.

Mocne strony

• Więcej miejsca. Kilka megabajtów na origin, dość na szczegółowe wybory na poziomie dostawców.
• Brak narzutu na żądania. Nic nie jest automatycznie wysyłane na serwer.

Słabe strony

• Niewidoczne dla serwera. Kod serwerowy i logika brzegowa nie mogą go odczytać, więc każda decyzja po stronie serwera musi czekać na przeglądarkę.
• Przypisane do jednego originu. Pamięć na www.example.com nie jest dostępna na shop.example.com, więc odwiedzający może znów zobaczyć baner na każdej subdomenie.
• Podlega usuwaniu. Safari może usuwać pamięć zapisywalną przez skrypty, w tym localStorage, dla witryn, z którymi użytkownik nie wchodził w interakcję przez siedem dni korzystania z przeglądarki, a tryby przeglądania prywatnego zwykle czyszczą ją po zakończeniu sesji.

Opcja 3: rekordy zgody po stronie serwera

Rekord serwerowy to wpis zapisywany przez Ciebie lub dostawcę CMP przy każdym dokonanym wyborze. Zwykle zawiera pseudonimowy identyfikator, znacznik czasu, wybory, wersję pokazanego banera lub polityki oraz kontekst, taki jak region.

Mocne strony

• Trwały dowód. Przetrwa czyszczenie cookies i ograniczenia przeglądarek, co czyni go właściwym narzędziem do wykazania, że zgoda została uzyskana.
• Możliwy do audytu. Możesz raportować wybory w czasie i odpowiadać na pytania o konkretne zdarzenia.
• Potencjał międzyurządzeniowy. Dla zalogowanych czytelników rekord serwerowy może synchronizować wybory między urządzeniami, jeśli im to wyjaśnisz.

Słabe strony

• Nie zastępuje stanu lokalnego. Tagi w przeglądarce nadal potrzebują szybkiego, lokalnego sygnału; wywoływanie serwera przy każdym wyświetleniu strony w celu sprawdzenia zgody dodaje opóźnienie.
• Sam jest daną osobową. Rekordy wymagają okresu przechowywania, kontroli dostępu i miejsca w polityce prywatności.
• Zależność od identyfikatora. Anonimowych odwiedzających można dopasować do rekordu tylko przez identyfikator zapisany na ich urządzeniu, co wraca do pamięci lokalnej.

Zestawienie

• Najlepsze do zapamiętania wyboru w sieci: cookies first-party, najlepiej ustawiane przez Twój serwer na stabilny czas życia.
• Najlepsze do szczegółowych danych o preferencjach w przeglądarce: localStorage w parze z cookie, które serwer może odczytać.
• Najlepsze do udowodnienia wyboru: rekordy po stronie serwera.
• Najgorszy wybór pojedynczej opcji: poleganie wyłącznie na localStorage, co zostawia serwer ślepym, a wybór kruchym w niektórych przeglądarkach.

Praktyczne podejście łączone

1. Autorytatywny sygnał lokalny — na przykład ciąg TCF i zwarty rekord preferencji — zapisz w cookie first-party o zasięgu Twojej domeny rejestrowalnej.
2. localStorage używaj tylko do danych uzupełniających, które nie muszą trafiać na serwer.
3. Zapisuj rekord po stronie serwera dla każdego wyboru, wraz z wersją pokazanego banera i polityki.
4. Jeśli zapisany wybór zniknie, pokaż baner ponownie zamiast zakładać wcześniejszą odpowiedź.
5. Ustal okres ponownego pytania dla zapisanych wyborów i odnotuj go w swojej polityce.

Zapisanie samego wyboru zgody odwiedzającego jest zwykle traktowane jako niezbędne do świadczenia usługi, o którą odwiedzający poprosił — zapamiętania jego decyzji — ale sprawdź wytyczne obowiązujące na Twoich głównych rynkach.

Najważniejsze wnioski

• Zapamiętanie wyboru i udowodnienie wyboru to różne zadania wymagające różnej pamięci.
• Cookies są czytelne dla serwera i współdzielone między subdomenami, ale ograniczone rozmiarem i — w Safari — czasem życia, gdy ustawia je skrypt.
• localStorage daje miejsce, ale jest niewidoczne dla serwera i przeglądarki mogą je czyścić.
• Rekordy serwerowe to warstwa dowodowa, a nie zamiennik sygnału lokalnego.
• Połącz cookie first-party ustawiane przez serwer, opcjonalną pamięć przeglądarki i rekordy serwerowe.