Zgoda na pliki cookie w PrestaShop: czego naprawdę wymaga prawo

Ostatnia aktualizacja: czerwiec 2026. Odniesienia do praktyki egzekwowania przepisów (CNIL, TDDDG, Garante) odzwierciedlają stan na ten moment i zmieniają się w czasie; to wskazówki techniczne, a nie porada prawna — konkretne wymagania dla swoich rynków potwierdź z wykwalifikowanym doradcą.

Prawie każdy sklep PrestaShop ma baner cookies. Prawie żaden nie działa zgodnie z przepisami — i powód jest techniczny, nie prawny. Baner grzecznie siedzi w rogu, podczas gdy Google Analytics, Facebook Pixel i pół tuzina innych skryptów już uruchomiły się przy ładowaniu strony, ustawiły swoje pliki cookie i wysłały dane dalej. Klient klika „Akceptuję” albo „Odrzuć”; nic to nie zmienia, bo śledzenie nastąpiło, zanim w ogóle zobaczył wybór. Ten jeden błąd — uruchamianie plików cookie przed uzyskaniem zgody — jest najczęstszym naruszeniem dotyczącym cookies w sklepach PrestaShop, a jednocześnie tym, co zmienia baner z narzędzia zgodności w prawną dekorację.

Ten przewodnik dotyczy konkretnie zgody: jak musi wyglądać ważna zgoda, dlaczego kolejność działań (najpierw blokuj, potem uruchamiaj) decyduje o wszystkim i jak to faktycznie działa w architekturze hooków i modułów PrestaShop. Szerszy obraz — prawa osób, których dane dotyczą, politykę prywatności, rejestr RODO, dane, które możesz przechowywać — znajdziesz w artykułach RODO i zgodność cookies dla PrestaShop oraz w szerszym przewodniku RODO dla sklepów internetowych. Tutaj zostajemy przy banerze i skryptach, które za nim stoją.

Dwa akty prawne, jedna zasada, której musisz przestrzegać

Pliki cookie znajdują się na styku dwóch elementów prawa UE i warto wiedzieć, za co odpowiada każdy z nich — bo prowadzą w nieco innych kierunkach.

Łączny efekt można opisać prosto, ale łatwo wdrożyć go źle: musisz uzyskać wyraźną, świadomą zgodę przed umieszczeniem lub odczytaniem jakiegokolwiek nieistotnego pliku cookie. Zwróć uwagę na słowo przed. ePrivacy dotyczy samego zapisu na urządzeniu, więc zgoda musi pojawić się jako pierwsza — nie „baner jest widoczny, kiedy skrypt działa”, tylko skrypt naprawdę nie uruchamia się, dopóki użytkownik nie wyrazi zgody.

Co w sklepie PrestaShop liczy się jako „ściśle niezbędne”

Krótka, możliwa do obrony lista plików cookie, które możesz ustawić bez pytania — ponieważ sklep bez nich nie działa, a klient zażądał danej funkcji, na przykład dodając produkt do koszyka:

• Cookie sesyjne PrestaShop (PrestaShop-xxxxxxxx, sesja front-office) — utrzymuje koszyk, stan zalogowania i token CSRF między stronami. Bez niego nie ma sklepu.
• Uwierzytelnianie klienta — zapamiętanie, że zalogowany klient nadal jest zalogowany.
• Tokeny bezpieczeństwa — ochrona CSRF w formularzach i podczas finalizacji zakupu, sygnały antyfraudowe i antybotowe.
• Samo cookie zgody — wolno Ci zapamiętać wybór, którego użytkownik właśnie dokonał.
• Równoważenie obciążenia / routing — pliki cookie sesji przyklejonej, które kierują użytkownika na właściwy serwer.

Wszystko poza tą granicą — analityka, piksele reklamowe, testy A/B, osadzone kanały społecznościowe, odtwarzacze wideo zapisujące śledzące pliki cookie — wymaga najpierw zgody. Przydatny test: jeśli cookie istnieje po to, by pomagać Tobie (mierzyć, remarketingować, optymalizować), a nie po to, by dostarczyć stronę, o którą poprosił klient, jest nieistotne.

Jak naprawdę musi wyglądać ważna zgoda

„Kliknęli coś” to nie jest zgoda. RODO wyznacza standard jakości, a organy nadzorcze — szczególnie francuski CNIL i niemieckie organy ochrony danych — interpretują go dziś rygorystycznie. Ważna zgoda jest:

• Dobrowolna. To realny wybór, bez kary za odmowę. Cookie wall — „zaakceptuj wszystko albo nie możesz korzystać ze strony” — w większości UE tego testu nie przechodzi, bo zgoda nie jest dobrowolna, gdy jedyną alternatywą jest brak dostępu.
• Konkretna i granularna. Zgoda na analitykę jest oddzielna od zgody marketingowej. Jeden ogólny przycisk „zaakceptuj cookies”, który łączy wszystko razem, jest zbyt szeroki; przełączniki na poziomie kategorii (niezbędne / analityczne / marketingowe / preferencje) są przyjętym standardem.
• Świadoma. Użytkownik rozumie, na co się zgadza. Nie oznacza to polityki na 10 000 słów w samym banerze — wystarczy podsumowanie prostym językiem i link do pełnej listy plików cookie.
• Jednoznaczna i aktywna. Wyraźne działanie — kliknięcie „Akceptuję”. Dalsze przeglądanie nie jest zgodą. Przewijanie nie jest zgodą. Wstępnie zaznaczone pola są wprost zakazane.
• Możliwa do wycofania równie łatwo, jak została udzielona. Jeśli jedno kliknięcie ustawiło zgodę, jedno kliknięcie (z trwałego linku „Ustawienia cookies” w stopce) musi móc ją cofnąć.

Co to oznacza dla projektu Twojego banera? „Odrzuć wszystko” musi być tak samo widoczne i tak samo jednoklikowe jak „Akceptuj wszystko”, już na pierwszej warstwie — nie może być ukryte dwa kliknięcia dalej pod „Zarządzaj preferencjami”. Baner, w którym odmowa jest trudniejsza niż zgoda, to dokładnie ten zwodniczy wzorzec projektowy, za który nakładane są kary, i regulatorowi (albo zirytowanemu klientowi) bardzo łatwo go zauważyć.

Błąd, który psuje 90% banerów PrestaShop: uruchamianie przed zgodą

Tutaj szczegóły PrestaShop mają znaczenie, bo problem prawie zawsze jest architektoniczny. Większość sklepów dodaje śledzenie, wklejając fragment Google Analytics, Pixel albo Tag Manager do modułu podpiętego pod displayHeader (albo bezpośrednio do header.tpl motywu, przez moduł custom HTML typu „live edit”/wstrzykiwanie w nagłówek, albo przez moduł ps_googleanalytics). Wszystkie te metody wstrzykują skrypt na każdej stronie w momencie renderowania strony — czyli dokładnie wtedy, gdy cookie zostaje zapisane, na długo zanim odwiedzający przeczyta baner, nie mówiąc już o udzieleniu odpowiedzi.

Sam baner cookies to tymczasem tylko front-endowy JavaScript, który wyświetla okienko. Jeśli te dwa elementy nie są ze sobą połączone, baner jest kosmetyczny, a sklep niezgodny z przepisami, niezależnie od tego, jak dobrze wygląda. Dominują dwa tryby awarii:

• Uruchamianie przy ładowaniu. Skrypty startują od razu w hookHeader; baner pojawia się później. Pliki cookie są już ustawione. Kliknięcie „Akceptuję” albo „Odrzuć” nie zmienia niczego, co już się wydarzyło.
• Odrzucenie jest ignorowane. Użytkownik klika „Odrzuć wszystko”, ale skrypt analityczny — zarejestrowany niezależnie od banera — nadal uruchamia się na następnej stronie. Te dwa systemy nigdy nie zostały ze sobą połączone.

Rozwiązanie dotyczy kolejności działań, nie interpretacji prawnej. Skrypty nieistotne muszą być domyślnie zablokowane i wstrzykiwane dopiero po wyrażeniu zgody na odpowiednią kategorię. W praktyce oznacza to jedną z trzech architektur: (1) samo narzędzie do zgód kontroluje wstrzykiwanie skryptów i wstrzymuje tagi do czasu zgody użytkownika; (2) kierujesz wszystko przez Google Tag Manager i uzależniasz każdy tag od wyzwalacza zgody; albo (3) kierujesz wszystko przez Google Tag Manager z Google Consent Mode v2 — ale tylko jako warstwę wspierającą, nie jako samodzielną ścieżkę zgodności. Consent Mode pomaga wyłącznie wtedy, gdy jego domyślny stan zgody jest ustawiony na denied i przed zgodą odwiedzającego nie dochodzi do żadnego nieistotnego zapisu ani śledzenia; „ograniczone, bezciasteczkowe” sygnały wysyłane przez Google przed zgodą nadal mogą być prawnie wrażliwe i trzeba je uważnie ocenić oraz skonfigurować, zamiast zakładać, że są zgodne. Sam z siebie nie spełnia wymogu uprzedniego blokowania, którego wymaga ePrivacy. Możesz sprawdzić, w którym obozie jest Twój sklep, bez żadnych dodatkowych narzędzi: otwórz narzędzia deweloperskie przeglądarki, przejdź do panelu Application → Cookies podczas pierwszej wizyty przed kliknięciem czegokolwiek i poszukaj _ga, _fbp oraz podobnych wpisów. Jeśli tam są, Twój baner jest dekoracją.

Jak wygląda „najpierw blokuj” w znacznikach

Konkretna technika stojąca za warstwą zgody, która naprawdę blokuje, jest prosta: skrypt, który ma poczekać, nie trafia na stronę jako normalny <script src>. Trafia z unieszkodliwionym typem, aby przeglądarka go nie wykonała, a warstwa zgody przepisuje ten typ na text/javascript dopiero wtedy, gdy zaakceptowana zostanie pasująca kategoria. Wystarczy zobaczyć to raz, żeby odczarować całą obietnicę „blokowania przed zgodą”:

<!-- BLOCKED until consent: the browser parses but does NOT run this. -->
<script type="text/plain" data-cookiecategory="analytics"
        src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>

<!-- When the visitor accepts "analytics", the consent layer flips the type
     so the browser then executes it — never before. -->

Jeśli skrypt jest już aktywnym type="text/javascript" (albo w ogóle nie ma type) w źródle strony, nie jest zablokowany — uruchamia się przy ładowaniu, z banerem czy bez. Ten jeden atrybut jest praktyczną granicą między warstwą zgody, która działa, a banerem namalowanym na skryptach, które już się uruchomiły. I co z tego wynika? Gdy oceniasz dowolny moduł cookies albo konfigurację GTM, podgląd źródła i sprawdzenie, czy tagi śledzące są unieszkodliwione (text/plain), w pięć sekund pokazuje, czy uprzednie blokowanie jest realne, czy tylko pozorne.

Co PrestaShop daje natywnie — i gdzie to się kończy

PrestaShop dostarcza pewne prawne rusztowanie i warto dokładnie wiedzieć, jak daleko ono sięga, zanim sięgniesz po moduł.

Uczciwe podsumowanie: natywne narzędzia PrestaShop dobrze pokrywają informowanie i prawa dotyczące danych, ale żadne z nich nie robi tego, o czym jest ten artykuł — nie zatrzymuje nieistotnych plików cookie do czasu, aż odwiedzający powie „tak”. Do tego potrzebna jest warstwa zgody, która naprawdę kontroluje wstrzykiwanie skryptów.

Wdrożenie prawdziwej zgody w PrestaShop

Dedykowany moduł istnieje właśnie dlatego, że powyżej widać lukę: potrzebujesz czegoś, co przechwytuje skrypty śledzące i zwalnia je według kategorii, z poziomu back office, bez edytowania plików motywu i ręcznego spinania wyzwalaczy tagów. Nasz Lightweight Cookie Banner został zbudowany w PrestaShop dokładnie do tego zadania:

• Blokowanie domyślne, zwalnianie według kategorii. Skrypty analityczne i marketingowe są wstrzymywane do czasu, aż odwiedzający wyrazi zgodę na tę kategorię — niezbędne / analityczne / marketingowe / preferencje działają jako niezależne przełączniki. To jest uprzednie blokowanie, którego faktycznie wymaga prawo, a nie baner położony na skryptach, które już się uruchomiły.
• Odrzucenie tak łatwe jak akceptacja. „Odrzuć wszystko” znajduje się na pierwszej warstwie z taką samą widocznością jak „Akceptuj wszystko”, dzięki czemu unikasz egzekwowania przepisów dotyczących zwodniczych wzorców, które dotyka inne sklepy.
• Rejestr zgody. Moduł zapisuje, kiedy każdy odwiedzający wyraził zgodę i na co — to dowód, którego będziesz potrzebować, jeśli organ ochrony danych zapyta, jak uzyskałeś zgodę.
• Ponowna zgoda po zmianie. Dodajesz nową kategorię śledzenia albo aktualizujesz politykę cookies? Moduł pyta ponownie, zamiast po cichu opierać się na nieaktualnej zgodzie.
• Naprawdę lekki. Ładuje się bez spowalniania strony — więc warstwa zgodności nie kosztuje Cię wyniku PageSpeed, którego pilnujesz.

Jaki jest zysk? Konfigurujesz wszystko z back office, zamiast płacić deweloperowi za wszywanie logiki zgód w motyw, a baner przestaje być ryzykiem przebranym za zabezpieczenie. To techniczne umożliwienie zgodności — daje Ci uprzednie blokowanie i rejestr zgód, których oczekuje prawo — ale samo w sobie nie czyni sklepu „zgodnym”; polityka cookies, wybór kategorii i ujawnienia dotyczące podmiotów przetwarzających nadal pozostają Twoją odpowiedzialnością jako administratora. Jeśli Twój sklep korzysta też z narzędzi Google, połącz moduł z Consent Mode v2, aby GA4 nadal modelował konwersje od odwiedzających, którzy odmawiają — Consent Mode statystycznie szacuje tę utraconą część, nie odzyskuje ich rzeczywistych danych, a Ty nadal respektujesz „nie”, najpierw blokując.

Różnice między krajami: ta sama zasada, nierówne egzekwowanie

Zasada uprzedniej zgody obowiązuje w całej UE, ale gotowość do jej egzekwowania nie jest wszędzie taka sama. Kilka przykładów, które wpływają na konfigurację banera:

• Francja (CNIL). Najbardziej rygorystyczna w projektowaniu banerów: „Odmów wszystko” musi być na pierwszej warstwie, równorzędnie z „Akceptuj wszystko”. CNIL wielokrotnie nakładał wysokie kary konkretnie za trudne do znalezienia przyciski odmowy.
• Niemcy. Analityka wymaga zgody, kropka, a TDDDG (następca TTDSG) wpisuje zasadę uprzedniej zgody z ePrivacy bezpośrednio do prawa krajowego. Niemieckie organy niechętnie przyjmują argumenty o „uzasadnionym interesie” w śledzeniu.
• Włochy (Garante). Wymagają banera przy pierwszej wizycie z opcjami akceptuj / odrzuć / zarządzaj oraz podlinkowanej polityki cookies; wprost odrzuciły przewijanie jako zgodę.
• Hiszpania (AEPD) stosuje standard UE i publikuje szczegółowe wytyczne dotyczące banerów, historycznie egzekwując je łagodniej niż Francja czy Niemcy.
• Wielka Brytania (ICO). Po Brexicie Wielka Brytania zachowała zasady jako UK GDPR plus PECR; merytorycznie jest to ten sam obowiązek uprzedniej zgody, egzekwowany przez ICO.

Szerszą mapę prawną sprzedaży transgranicznej poza cookies znajdziesz w przewodniku prawo e-commerce w UE.

Zaakceptuj lukę w analityce — i zaplanuj ją

Niewygodna konsekwencja prawidłowego wdrożenia zgody: Twoja analityka staje się uboższa. Gdy istotna część odwiedzających odmawia śledzenia — często podaje się wartości z zakresu 30–40%, ale traktuj je orientacyjnie i mierz własny współczynnik zgód na podstawie rejestru — po prostu tracisz widoczność tego wycinka. To nie błąd, który trzeba obejść technicznie; to koszt zgodności, a udawanie, że jest inaczej, prowadzi sklepy z powrotem w pułapkę „uruchamiania przed zgodą”. Rozsądne sposoby ograniczania strat: oprzyj się na Consent Mode v2 dla modelowanych (szacowanych, nie odzyskanych) konwersji, rozważ pomiar po stronie serwera dla danych, które możesz zbierać bez cookies na urządzeniu, i przenieś analizę z indywidualnych ścieżek użytkowników na zagregowane trendy, które przetrwają mniejszą próbę.

Najczęściej zadawane pytania

Jak mogę teraz sprawdzić, czy mój baner naprawdę cokolwiek blokuje?

Otwórz sklep w świeżym oknie incognito, uruchom DevTools → Application → Cookies i sprawdź przed dotknięciem banera. Jeśli _ga, _fbp albo _gcl_au już tam są, skrypty uruchomiły się przy ładowaniu, a Twój baner jest kosmetyczny. Potem kliknij „Odrzuć wszystko” i odśwież: jeśli wrócą, odmowa nie jest połączona ze skryptami. Drugi sygnał znajdziesz w źródle strony — zablokowane tagi mają type="text/plain"; aktywne nie.

Czy „Akceptuj wszystko” plus link „Zarządzaj preferencjami” wystarczy, czy potrzebuję widocznego „Odrzuć wszystko”?

Potrzebujesz „Odrzuć wszystko” na pierwszej warstwie, z taką samą widocznością i kosztem kliknięcia jak „Akceptuj wszystko”. Ukrywanie odmowy za „Zarządzaj preferencjami” to konkretny zwodniczy wzorzec, za który CNIL i inne organy wielokrotnie karały. Równa widoczność na pierwszym ekranie to bezpieczny domyślny wybór na rygorystycznych rynkach.

Czy Google Consent Mode v2 sam w sobie sprawia, że mój baner jest zgodny?

Nie. Consent Mode sygnalizuje tagom Google, czy odwiedzający wyraził zgodę, i modeluje konwersje utracone przez osoby, które odmówiły — szacuje je, ale nie odzyskuje rzeczywistych danych. To warstwa wspierająca, a nie uprzednie blokowanie wymagane przez ePrivacy. Jeśli nieistotne pliki cookie nadal są zapisywane przed zgodą odwiedzającego, Consent Mode Cię nie ratuje; najpierw potrzebujesz warstwy, która naprawdę wstrzymuje skrypty.

Czy mogę zachować moduł ps_googleanalytics w PrestaShop i nadal działać zgodnie z przepisami?

Tylko jeśli coś go bramkuje. Sam ps_googleanalytics wstrzykuje swój tag przy ładowaniu strony i ustawia cookie GA przed zgodą. Albo prowadzisz go przez warstwę zgody / GTM, która blokuje go do momentu akceptacji „analytics”, albo go zastępujesz. Problemem nie jest sam moduł; problemem jest jego bezwarunkowe uruchamianie.

Czy cookie walls („zaakceptuj albo wyjdź”) są dozwolone?

W większości UE nie — zgoda nie jest „dobrowolna”, gdy jedyną alternatywą jest utrata dostępu do strony. Niektóre jurysdykcje i określone modele z płatną alternatywą są przedmiotem dyskusji, ale dla zwykłego sklepu PrestaShop cookie wall to zły wybór domyślny. Zamiast tego daj realną ścieżkę odmowy.

Praktyczne minimum, które trzyma Cię z dala od problemów

Jeśli chcesz działać zgodnie z przepisami bez nadmiernego komplikowania, zrób po kolei:

• Zainstaluj warstwę zgody, która blokuje skrypty — nie baner, który tylko informuje. (Lightweight Cookie Banner, jeśli chcesz obsługiwać to z back office.)
• Skonfiguruj ją tak, aby wstrzymywała analitykę i marketing do czasu akceptacji pasującej kategorii.
• Umieść „Odrzuć wszystko” na pierwszej warstwie, równorzędnie z „Akceptuj wszystko”.
• Opublikuj jasną politykę cookies (utwórz dla niej stronę CMS, jeśli Twoja instalacja jeszcze jej nie ma), wymieniając każdy plik cookie, jego cel i okres życia.
• Zweryfikuj to narzędziami deweloperskimi: świeża wizyta, sprawdź Application → Cookies przed kliknięciem — _ga / _fbp nie powinny istnieć. Potem kliknij „Odrzuć wszystko” i potwierdź, że nadal się nie pojawiają.
• Przechowuj rejestry zgód, aby móc pokazać, jak i kiedy zgoda została uzyskana.

To nie jest absolutne prawne maksimum w każdej jurysdykcji — niektóre wymagają głębszych ujawnień — ale pokrywa fundamenty i trzyma Cię z dala od działań egzekucyjnych, które naprawdę się zdarzają. W przypadku sformułowań specyficznych dla rynku warto poświęcić godzinę na prawnika znającego Twoje kraje docelowe; tylko nie pozwól, aby pogoń za idealną dokumentacją zatrzymała Cię przed naprawą jednej rzeczy, która faktycznie ma dziś znaczenie: upewnieniem się, że żadne cookie nie zostanie ustawione, zanim odwiedzający powie „tak”.

Powiązane przewodniki

• RODO i zgodność cookies dla PrestaShop: czego naprawdę potrzebujesz
• RODO dla sklepów internetowych: co musisz zrobić (i co możesz pominąć)
• Prawo e-commerce w UE: przewodnik właściciela sklepu po najważniejszych zasadach
• Dostępność dla sklepów internetowych: co oznacza dla Ciebie Europejski Akt o Dostępności