Co robi natywny baner plików cookie Squarespace i gdzie się zatrzymuje

Natywny Cookie Banner Squarespace — dostępny w Settings, Cookies & Visitor Data — obsługuje konfigurowalny interfejs banera, udostępnia wybór stylu zgody operatora i integruje się z własnymi analizami i powierzchniami marketingowymi Squarespace. Gdy operator włączy baner i skonfiguruje ustawienia danych odwiedzających, wewnętrzne integracje Squarespace respektują wybór odwiedzającego bez dodatkowej konfiguracji: Squarespace Analytics jest bramkowany sygnałem analitycznym, piksele remarketingowe Pinterest, Facebook i Google Ads respektują sygnał marketingowy, a własne zbieranie danych behawioralnych platformy jest blokowane dla odwiedzających, którzy odmówią.

Czego baner nie robi, i gdzie na Squarespace najczęściej dochodzi do naruszenia zgodności, to bramkowanie skryptów innych firm, które operator dodaje przez Code Injection. Panel Code Injection — w Settings, Advanced — pozwala operatorowi wkleić dowolny HTML i JavaScript do nagłówka strony, stopki lub lokalizacji na każdej stronie. Skrypty wstrzyknięte w ten sposób uruchamiają się zanim odwiedzający zobaczy baner, co oznacza, że każdy tag innej firmy wklejony do Code Injection uruchamia się niezależnie od zgody. Hotjar, niestandardowe kontenery Google Tag Manager, dodatkowe Facebook Pixels, widżety czatu, dostawcy wideo — wszystko, czego nie ma na liście natywnych integracji Squarespace, nie będzie bramkowane przez natywny baner, chyba że operator opakuje skrypt w sprawdzenie zgody.

Domyślny styl zgody: opt-in vs domyślny

Baner Squarespace obsługuje zarówno styl zgody opt-in, jak i domyślny, a opcja domyślna pozostaje dostępna, mimo że była źródłem powtarzających się ustaleń organów regulacyjnych w stosunku do witryn hostowanych przez Squarespace w całej EEA. Operator musi wybrać opcję opt-in, zweryfikować, że zbieranie danych odwiedzających jest domyślnie wyłączone do momentu akceptacji przez odwiedzającego, oraz upewnić się, że możliwość odrzucenia jest co najmniej tak samo widoczna jak możliwość akceptacji w interfejsie banera. Te trzy ustawienia — wyraźna zgoda, domyślnie wyłączone, widoczne odrzucenie — to minimum, którego witryna Squarespace potrzebuje, by przekroczyć próg wyznaczony przez EDPB w wytycznych dotyczących banerów plików cookie z 2023 roku.

Powierzchnia Code Injection i sposób jej bramkowania

Wzorzec integracji działający na Squarespace składa się z trzech części. Po pierwsze, poprawnie skonfiguruj natywny baner. Po drugie, zidentyfikuj każdy skrypt w Code Injection i oceń, do której kategorii zgody należy. Po trzecie, opakuj każdy skrypt Code Injection w sprawdzenie zgody przed jego wykonaniem — czytając udostępniony stan zgody Squarespace w czasie wykonywania lub wstawiając element skryptu warunkowo dopiero po tym, jak baner zwróci pozytywny sygnał dla odpowiedniej kategorii.

Najczystszym wzorcem dla skryptów wstrzykniętych do nagłówka jest konwersja do postaci zastępczej: zmień atrybut type z text/javascript na text/plain, dodaj atrybut data-category identyfikujący bramę zgody i dołącz mały skrypt bootstrap, który nasłuchuje zdarzenia zmiany zgody Squarespace i przepisuje atrybut type, gdy kategoria zostanie przyznana. Wzorzec bootstrap jest tym samym, którego używają Webflow, Drupal i Cloudflare Zaraz; wkład Squarespace to obiekt stanu zgody, który bootstrap odczytuje.

Powierzchnia widżetów innych firm, którą operatorzy Squarespace rutynowo pomijają

Operatorzy Squarespace w dużym stopniu polegają na wbudowanych blokach dla bogatych treści, które napędzają większość atrakcyjności platformy. Każdy z tych bloków wprowadza osobną powierzchnię zgody, której natywny baner automatycznie nie bramkuje.

• Bloki wideo — Filmy YouTube i Vimeo w tle ładują skrypty innych firm dostawcy przy każdym renderowaniu strony. Tryb osadzania YouTube z rozszerzoną prywatnością i tryb osadzania Vimeo do-not-track są opcjami, ale bezpieczniejszym wzorcem jest opakowanie bloku wideo w zastępczy element kliknij-aby-załadować, który pobiera iframe dostawcy dopiero gdy odwiedzający go wyraźnie aktywuje.
• Bloki społecznościowe — Bloki Instagram, Twitter, TikTok i Pinterest pobierają skrypt osadzania dostawcy i ustawiają pliki cookie po stronie dostawcy. Wzorzec jest ten sam: zastąp aktywny blok statycznym podglądem, który ładuje osadzenie tylko przy interakcji użytkownika, za bramą zgody marketingowej.
• Formularze zapisu na newsletter — Wbudowany formularz Squarespace jest świadomy zgody, ale osadzenia formularzy Mailchimp, Klaviyo, ConvertKit i podobnych innych firm już nie, a wbudowany dostawca formularzy zazwyczaj ładuje własną analitykę przy renderowaniu formularza. Każdy musi być opakowany w sprawdzenie zgody.
• Widżety czatu — Osadzenia czatu Drift, Intercom, Tidio i podobnych ustawiają własne pliki cookie sesji i tożsamości oraz ładują własny JavaScript. Należą co najmniej za bramę zgody funkcjonalnej, a za bramę marketingową, jeśli platforma czatu integruje się z CRM, który propaguje dane odwiedzających.

Squarespace Commerce i powierzchnia koszyka

Squarespace Commerce wprowadza ściśle niezbędne pliki cookie dla stanu koszyka, tożsamości sesji i płatności, które nie wymagają zgody, ponieważ są niezbędne do usługi, której zażądał odwiedzający. Komplikacje pojawiają się wokół powierzchni marketingowych, które wprowadza Commerce: e-maile o porzuconych koszykach, silniki rekomendacji produktów, integracja z Facebook Conversions API, remarketing Google Ads i integracja Klaviyo lub Mailchimp, którą włącza większość sklepów. Są one niekonieczne i muszą być bramkowane. Natywny baner Squarespace obsługuje własne integracje Conversions platformy; Klaviyo i Mailchimp oraz każda niestandardowa konfiguracja Conversions wymagają bramkowania po stronie operatora.

Walidacja i postawa audytowa na 2026

Obronialne wdrożenie Squarespace w 2026 roku musi przejść cztery kontrole techniczne. Po pierwsze, czysta sesja przeglądarki obsługiwana z adresu IP w EEA musi wygenerować zero nienizbędnych plików cookie przed zadziałaniem banera — obejmuje to pliki cookie zarządzane przez Squarespace, skrypty Code Injection, wbudowane bloki wideo i społecznościowe oraz wszelkie widżety newsletterów lub czatu na stronie. Po drugie, ścieżka odrzucenia musi utrzymać ten stan. Po trzecie, ścieżka akceptacji musi wygenerować tylko tagi, na które odwiedzający wyraził zgodę, a pliki cookie Squarespace i stan zgody muszą zawierać odpowiedni rekord. Po czwarte, wycofanie musi natychmiast zatrzymać dalsze uruchamianie tagów, wygasić pliki cookie ustawione podczas sesji z wyrażoną zgodą i przekazać rezygnację do dalszych odbiorców innych firm. Kwestia śladu audytowego to miejsce, gdzie natywny baner Squarespace aktualnie pokazuje swoje ograniczenia. Baner rejestruje stan zgody odwiedzającego w pliku cookie pierwszej strony, który odczytują własne integracje Squarespace, ale platforma nie prowadzi dziennika audytu po stronie serwera, który można odpytywać przez identyfikator odwiedzającego lub identyfikator sesji, jak robi to CMP innej firmy. W przypadku wdrożeń działających głównie w jurysdykcjach z lżejszymi oczekiwaniami dotyczącymi śladu audytowego natywny baner jest wystarczający, gdy jest poprawnie skonfigurowany. W przypadku wdrożeń wymagających odpytywalnego dziennika zgody — raportowanie w wielu jurysdykcjach, rekordy zgody na dostawcę, integracja z oczekiwanym standardem dokumentacji EDPB — CMP innej firmy warstwowy nad natywnym banerem jest właściwą odpowiedzią, z wyłączonym natywnym banerem i zainstalowanym Cookiebot, OneTrust, Usercentrics lub Iubenda przez Code Injection. Witryna Squarespace, która świadomie wybrała między dwoma ścieżkami, zablokowała każdą powierzchnię Code Injection, rozwiązała wzorzec wbudowanych widżetów i uwzględniła integracje marketingowe specyficzne dla Commerce, to witryna Squarespace, która zamieniła przyjazną dla projektantów prostotę platformy w obronialnną część postawy zgody operatora, a nie ukryty dług zgodności.