Consent Mode v2 w PrestaShop krok po kroku

Praktyczna instrukcja wdrożenia dla sklepów na PrestaShop 8 i 9 — konfiguracja modułu cookies, sygnały do GA4, Google Ads i CAPI, testy i częste błędy z realnych wdrożeń.

Aktualizacja: 7 września 2026 · Czas czytania: 9 min · Kategoria: Compliance i tracking

Sklep na PrestaShop, który nie ma poprawnie skonfigurowanego Consent Mode v2, płaci za to dwa razy. Raz — bo Google Ads nie widzi 30–50% konwersji od użytkowników z EOG, którzy odrzucili cookies marketingowe. Drugi raz — bo prawnicy klienta lub UODO, w razie audytu, potrafią rozliczyć z tego samego banera cookies, który dziś rozwiązuje sprawę jednym „Akceptuję wszystko”. Ten tekst jest o tym, jak zrobić to raz, dobrze, w architekturze, która nie odpadnie za pół roku.

Piszę z perspektywy agencji, która utrzymuje kilkanaście sklepów PrestaShop w abonamencie. Nie ma tu teorii oderwanej od praktyki — są konkretne moduły, hooki i kawałki JS, które faktycznie wdrażamy u klientów.

Czym jest Consent Mode v2 i po co PrestaShopowi

Consent Mode v2 to interfejs Google, przez który sklep przekazuje do wszystkich tagów Google (GA4, Google Ads, Floodlight) informację, na co użytkownik się zgodził. To nie jest baner cookies. Baner cookies to interfejs do zbierania zgód od użytkownika. Consent Mode v2 to to, co robisz z tymi zgodami po tym, jak je zbierzesz.

Rozróżnienie jest kluczowe, bo najczęstszy błąd, jaki widzimy przy audytach, wygląda tak: sklep ma ładny baner OK/Odrzuć, użytkownik klika „Odrzuć wszystko” — i mimo to GA4 dalej zbiera zdarzenia, a Google Ads dalej pobiera cliki. Prawnie sklep jest w tym momencie na czarnej liście, a technicznie po prostu nie ma wdrożonego Consent Mode v2.

Google od 6 marca 2024 wymaga sygnałów Consent Mode v2 do pełnej pracy Google Ads w EOG — bez nich nie ma modelowania konwersji, ograniczone są audiencje remarketingowe, a od 2025 znika też część funkcji Enhanced Conversions. Prawo (RODO plus PKE od 10 listopada 2024) wymaga zgody na cookies opcjonalne przed ich zapisem — Consent Mode v2 to techniczny wehikuł, który tę zgodę honoruje.

Basic vs advanced — który tryb dla e-commerce

Consent Mode v2 działa w dwóch trybach. Różnica jest praktyczna, nie kosmetyczna, i to jest jedna z pierwszych decyzji, którą trzeba podjąć.

Dla większości sklepów PrestaShop, które robimy w Centrum ZW, wybieramy advanced. Basic ma sens tylko w scenariuszach edge'owych — np. dla klienta w branży medycznej, który świadomie akceptuje utratę danych w zamian za zerową ekspozycję na ryzyko, że tag załaduje się przed zgodą. Dla sklepu z odzieżą, elektroniką czy DIY, który wydaje 5–50 tys. zł miesięcznie na Google Ads, basic to strzał w kolano.

Architektura wdrożenia: moduł cookies + GTM + Consent Mode v2

W PrestaShop 8 i 9 rekomendowana architektura to trzy warstwy:

1. Moduł cookies — obsługuje baner, przechowuje decyzje użytkownika, wystawia API do reszty systemu.
2. Google Tag Manager — jeden kontener, który zarządza GA4, Google Ads, Meta Pixel i pozostałymi tagami.
3. Consent Mode v2 layer — kilka linii JavaScript, które łączą decyzję z modułu cookies z GTM.

Trzymamy tę architekturę u wszystkich klientów, których obsługujemy w abonamencie. Powód jest brutalnie praktyczny: gdy Google zmienia specyfikację (a robi to średnio raz na kwartał), wystarczy poprawić jedną warstwę, a nie przekopywać się przez cały front sklepu.

Wybór modułu cookies

W PrestaShop testowaliśmy kilkanaście rozwiązań. Trzy, które w 2026 wciąż polecamy:

• Seigi Cookie — darmowy, dobry na start, obsługuje Consent Mode v2 out of the box. Sprawdza się dla sklepów do 5 tys. sesji miesięcznie.
• Moduły PrestaShow / PrestaPremium — płatne, ale lepiej wspierane. Mają wbudowaną integrację z Google Tag Manager i konfigurowalny mapping zgód.
• Cookiebot / Consentmanager — CMP klasy enterprise, ładowane przez GTM. Wybieramy je dla sklepów multijęzycznych, z większym ruchem i wymogiem audytu zgód (np. sklepy sprzedające do Niemiec, gdzie ryzyko kary DSGVO jest realne).

Zawsze jest krytyczne, żeby moduł cookies wyzwalał się przed pozostałymi hookami śledzącymi. W PrestaShop robi się to przez ustawienie priorytetu w hooku displayHeader — moduł cookies musi być pierwszy, moduły trackingowe (np. PShowConversion) niżej.

Konfiguracja Consent Mode v2 w GTM

W GTM tworzymy tag typu „Google tag” (nie „GA4 configuration” — to stare) i wpinamy go w Consent Initialization – All Pages. Wewnątrz taga wywołujemy domyślne stany zgód:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'functionality_storage': 'granted',
  'security_storage': 'granted',
  'wait_for_update': 500
});
gtag('set', 'ads_data_redaction', true);
gtag('set', 'url_passthrough', true);

Po decyzji użytkownika w banerze moduł cookies wywołuje aktualizację:

gtag('consent', 'update', {
  'ad_storage': granted ? 'granted' : 'denied',
  'ad_user_data': granted ? 'granted' : 'denied',
  'ad_personalization': granted ? 'granted' : 'denied',
  'analytics_storage': analytics ? 'granted' : 'denied'
});

Cztery parametry, które trzeba obsłużyć w EOG (od marca 2024): ad_storage, ad_user_data, ad_personalization, analytics_storage. Nie pomijaj żadnego — Google Ads odrzuci sygnały jako niekompletne.

Meta Pixel i inne tagi niebazujące na Google

Consent Mode v2 to specyfikacja Google. Meta Pixel, TikTok Pixel i pozostałe tagi trzeba obsłużyć osobno — w GTM przez własne triggery uzależnione od zmiennej z modułu cookies. Częsty błąd to założenie, że skoro Google respektuje zgody, to Meta też. Nie respektuje — trzeba wpiąć logikę ręcznie. Piszemy o tym szerzej w tekście wdrożenie Meta Pixel i CAPI.

Wdrożenie krok po kroku — checklist

Poniżej rekonstrukcja tego, co robimy przy każdym wdrożeniu w sklepie PrestaShop. Zwykle mieści się w jednym dniu roboczym.

Krok 1: Audyt startowy (30 min)

• Sprawdź wersję PrestaShop (dla 1.7 wiele modułów już nie ma aktualizacji).
• Wyszukaj aktywne moduły śledzące (Google Analytics, Facebook Pixel, TikTok, Klaviyo).
• Wypnij ewentualne duplikaty tagów — w 1 na 3 sklepach znajdujemy dwie różne implementacje GA4 działające równolegle.
• Sprawdź, przez co obecnie jest baner cookies. Jeśli to gpdrcookiebar z 2021 — do wymiany.

Krok 2: Instalacja modułu cookies (30 min)

• Zainstaluj wybrany moduł.
• Ustaw priorytet w hooku displayHeader na 1 (najwyżej).
• Skonfiguruj kategorie: niezbędne, analityczne, marketingowe, funkcjonalne.
• Włącz przycisk „Odrzuć wszystko” na pierwszym ekranie — jego brak to jeden z najczęstszych powodów kar (patrz sprawa Google 325 mln EUR z CNIL, 2025).

Krok 3: Konfiguracja GTM (2–3h)

• Wgraj tag „Consent initialization”.
• Dodaj GA4 configuration wpiętą w consent — parametry ustawione na wymagające zgody analitycznej.
• Dodaj Google Ads Conversion Linker i konwersje z tego samego consenta.
• Dla Meta Pixel — trigger na zmiennej z modułu cookies (nie na Consent Mode v2).

Krok 4: Integracja modułu cookies z GTM (1–2h)

• W ustawieniach modułu cookies wskaż, że aktualizacje zgód mają iść przez gtag('consent', 'update', ...).
• W większości modułów to jedna zmienna do włączenia. W kilku (starsze wersje Seigi) trzeba wkleić kilka linijek do szablonu.

Krok 5: Testy (1–2h)

• Google Tag Assistant w trybie preview — sprawdź, czy tag GA4 wysyła gcs=G100 przy braku zgody i gcs=G111 przy pełnej.
• W konsoli przeglądarki: google_tag_data.ics powinien zwócić bieżący stan.
• DebugView w GA4 — zdarzenia powinny się pojawić po zgodzie.
• Sprawdź w narzędziu EDPS Cookie Inspector lub prostym scanem, czy przed zgodą naprawdę nie ma cookies marketingowych.

Krok 6: Raport zgód w GA4 (10 min)

• GA4 → Administracja → Zbieranie danych → Ustawienia zgody — włącz raport.
• Po 5–7 dniach zaczniesz widzieć dane modelowane. To potwierdzenie, że Consent Mode v2 działa poprawnie.

Najczęstsze błędy z realnych audytów

Tydzień w tydzień oglądamy sklepy, które „mają Consent Mode v2” — a nie mają. Poniżej pięć najczęstszych patologii, na których się przewracają.

1. Consent Mode v2 wdrożony tylko przez wtyczkę WordPress

Zdarza się, że klient migruje z WooCommerce na PrestaShop i zostawia sobie „stary CMP”. Nie działa. Zgody z Cookie Notice for WordPress nie propagują się do PrestaShop.

2. Domyślne stany „granted” zamiast „denied”

Trafiamy na to co drugi audyt. Ktoś skopiował snippet z internetu i domyślnie wszystko jest na „granted”. To oznacza, że przed zgodą tagi zbierają cookies. Prawnie — złamanie RODO i PKE. Technicznie — Consent Mode v2 traci sens.

3. Brak parametrów ad_user_data i ad_personalization

W wersji v2 doszły dwa nowe parametry. Sklepy, które migrowały z v1, często ich nie mają. Efekt: Google Ads odrzuca modelowanie konwersji, a klient nie wie, dlaczego przychód w raportach jest niższy niż w rzeczywistości.

4. Brak przycisku „Odrzuć wszystko” na pierwszym ekranie

Jeden z ryzykowniejszych błędów prawnych. CNIL ukarał Google w 2022 kwotą 150 mln EUR i ponownie w 2025 za brak równorzędnego przycisku odrzucenia. UODO w praktyce podąża tą samą ścieżką — sklepy do 100 tys. zł kary są w polskiej rzeczywistości realne.

5. Brak wait_for_update

Parametr wait_for_update: 500 mówi tagom Google, żeby poczekały pół sekundy na decyzję użytkownika, zanim wyślą pingi. Bez niego wysyłają wszystko od razu z „denied”, co wykrzywia dane. Drobny bug, poważne konsekwencje w analityce.

Ile to trwa i co to kosztuje

Dla standardowego sklepu PrestaShop 8 (jeden język, GTM już postawiony, GA4 i Google Ads podpięte) — jeden dzień pracy. Około 8 godzin, z tego 2h na audyt, 2h na konfigurację modułu i GTM, 2h na testy, 2h na dokumentację i raport dla klienta. Nasze wdrożenie zamyka się jednorazową opłatą, jeśli klient nie wchodzi w abonament, albo wchodzi w koszt opieki miesięcznej jako element bazowy, gdy klient jest z nami na stałe.

Sklep multijęzyczny albo z niestandardowymi konwersjami (LearnDash, CartFlows, PYS PRO — piszemy o tym osobno) potrafi wymagać 2–3 dni. Ale bazowa filozofia się nie zmienia: robisz raz, dobrze, w architekturze, która za kwartał nie odpadnie.

Najczęściej zadawane pytania