Jak zmienić CMP na stronie? Migracja banera cookies krok po kroku

Migrację CMP zacznij od inwentaryzacji i eksportu, a nie od usunięcia starej wtyczki. Zapisz konfigurację banera, kategorie, reguły blokowania, integracje, potrzebne rejestry zgód i aktywne punkty instalacji. Nowy system skonfiguruj oraz przetestuj przed publikacją. Dopiero w kontrolowanym oknie przełącz stronę tak, aby na produkcji działał jeden CMP, a następnie sprawdź tagi, cookies, Consent Mode, formularze i zakupy.

Największe ryzyko pojawia się pomiędzy systemami. Jeżeli stary CMP zostanie wyłączony za wcześnie, opcjonalne skrypty mogą działać bez właściwej kontroli. Jeżeli oba rozwiązania pozostaną aktywne, użytkownik może zobaczyć dwa banery, a tagi otrzymają sprzeczne decyzje. Samo ukrycie starego okna przez CSS nie usuwa jego SDK, cookies, reguł ani aktualizacji zgody.

Ten poradnik publikuje CookieStart, dostawca CMP. Procedura techniczna opiera się na aktualnych materiałach producentów i źródłach urzędowych sprawdzonych 16 września 2026 r. Decyzja, czy i w jakim zakresie można zachować wcześniejsze zgody, wymaga oceny konkretnej konfiguracji, informacji przekazanej użytkownikom i obsługiwanych rynków.

Kiedy warto zmienić CMP?

Zmiana platformy zarządzania zgodami może być uzasadniona, gdy obecne rozwiązanie:

• nie wykrywa wszystkich skryptów i cookies;
• nie pozwala wygodnie zarządzać wieloma domenami lub językami;
• nie obsługuje wymaganych integracji;
• utrudnia poprawne wdrożenie Google Consent Mode v2;
• nie zapewnia potrzebnego rejestru decyzji;
• powoduje problemy z wydajnością albo cache;
• ma limity lub koszty nieadekwatne do ruchu i liczby witryn;
• nie daje zespołowi wystarczającej dokumentacji i wsparcia;
• przestało odpowiadać procesom agencji, sklepu lub organizacji.

Powód biznesowy nie określa jeszcze sposobu migracji. Inaczej wygląda zmiana prostej wtyczki na jednej stronie WordPress, a inaczej przełączenie platformy obsługującej wiele domen, języków, aplikację, IAB TCF, tagowanie serwerowe i kilka zespołów marketingowych.

Co może pójść nie tak podczas zmiany banera cookies?

Ryzyko	Możliwy skutek
stary CMP wyłączony przed uruchomieniem nowego	luka w wyświetlaniu banera i blokowaniu skryptów
dwa aktywne CMP	dwa banery, konkurujące zapisy zgody i sprzeczne sygnały
stary kod pozostawiony w GTM	niewidoczne aktualizacje zgody albo ponowne ładowanie SDK
błędne mapowanie kategorii	analityka uruchamia marketing lub odwrotnie
brak eksportu przed zamknięciem konta	utrata dostępu do konfiguracji i potrzebnych rejestrów
automatyczne uznanie starych decyzji	przypisanie granted bez wiarygodnego mapowania
brak reakcji po akceptacji	tagi zaczynają działać dopiero na kolejnej podstronie
duplikat GA4 lub Pixela	podwójne odsłony, leady albo zakupy
zmiana na produkcji bez planu powrotu	dłuższa awaria formularza, sklepu lub pomiaru
ocena wyłącznie wyglądu banera	skrypty działają inaczej niż sugeruje interfejs

Dlatego migracja CMP jest projektem technicznym, analitycznym i organizacyjnym. Nie ogranicza się do skopiowania kolorów oraz tekstu przycisków.

Plan migracji CMP w 10 krokach

Bezpieczna kolejność wygląda następująco:

1. Ustal zakres, właścicieli i kryteria powrotu.
2. Zapisz stan wyjściowy i wykonaj backup.
3. Wyeksportuj potrzebne dane ze starego CMP.
4. Zinwentaryzuj technologie niezależnie od starego panelu.
5. Podejmij decyzję o obsłudze wcześniejszych zgód.
6. Skonfiguruj nowy CMP poza produkcją.
7. Zmapuj tagi, kategorie i Consent Mode.
8. Przetestuj staging oraz plan przełączenia.
9. Wykonaj kontrolowaną publikację z jednym aktywnym CMP.
10. Przeprowadź test produkcyjny, monitoring i dopiero później zamknij stare konto.

Każdy etap powinien mieć osobę odpowiedzialną i dowód wykonania. W małej witrynie będzie to krótki protokół. W sklepie lub grupie serwisów może być potrzebna macierz domen, dostawców, tagów i scenariuszy.

Krok 1. Ustal zakres migracji i odpowiedzialność

Zapisz, co dokładnie obejmuje zmiana:

• domeny, subdomeny i wersje językowe;
• produkcję, staging i domeny tymczasowe;
• stronę internetową, sklep, aplikację oraz osadzone formularze;
• rynki i reguły regionalne;
• WordPress, WooCommerce, inne CMS i kod własny;
• GTM web, tagowanie serwerowe i kod gtag.js;
• GA4, Google Ads, Meta Pixel, narzędzia UX, czaty, mapy i filmy;
• Conversions API i inne integracje backendowe;
• rejestry zgód, raporty i wymagania organizacji.

Wyznacz właściciela projektu, administratora CMP, osobę odpowiedzialną za GTM, analitykę, stronę i ocenę prawną. Zapisz również warunki, które uruchomią powrót do poprzedniej wersji, na przykład:

• brak banera dla nowego użytkownika w obszarze, w którym powinien się pojawić;
• opcjonalne tagi działające mimo odmowy;
• brak aktualizacji Consent Mode po decyzji;
• dwa interfejsy zgód;
• awaria formularza, koszyka lub płatności;
• trwałe błędy JavaScript blokujące ważne funkcje.

Plan powrotu musi być wykonalny. Jeżeli przed przełączeniem anulujesz licencję, usuniesz konfigurację albo stracisz dostęp do starego skryptu, poprzednia wersja może nie dać się szybko przywrócić.

Krok 2. Zapisz stan wyjściowy

Przed zmianą wykonaj backup witryny i eksport aktualnej wersji kontenera GTM. Zanotuj:

• datę i godzinę kontroli;
• wersję CMS, motywu, wtyczek i CMP;
• identyfikatory domeny, kontenera i narzędzi pomiarowych;
• treść pierwszej oraz drugiej warstwy banera;
• wygląd na komputerze i telefonie;
• kategorie i technologie przypisane do każdej z nich;
• stan skryptów przed zgodą, po akceptacji, odmowie i wycofaniu;
• cztery wartości Consent Mode v2;
• działanie formularzy, sklepu i kluczowych konwersji;
• bieżącą wydajność oraz błędy Console.

Warto zapisać również punkt odniesienia dla liczby decyzji, użytkowników GA4, konwersji, zamówień i leadów. Nie po to, aby oczekiwać identycznych wartości po zmianie, ale aby szybko wykryć nagłe odchylenie. Nowy interfejs, sposób ładowania i definicje raportów mogą zmienić linię bazową.

Krok 3. Wyeksportuj dane ze starego CMP

Nie rozwiązuj umowy przed ustaleniem, do czego stracisz dostęp. W zależności od produktu wyeksportuj albo udokumentuj:

• treści banera i polityki cookies;
• listę języków i tłumaczeń;
• kategorie, cele i opisy technologii;
• wyniki skanów cookies i skryptów;
• reguły blokowania, wyjątki oraz listy dozwolonych domen;
• ustawienia geolokalizacji i regionów;
• listy dostawców, cele i konfigurację TCF, jeśli jest używana;
• sposób integracji z GTM i sygnałami zgody;
• niestandardowe zdarzenia, callbacki i kod własny;
• identyfikatory witryn, domen oraz środowisk;
• potrzebne rejestry decyzji i historię zmian;
• raporty przydatne do rozliczeń, audytu albo obsługi żądań;
• warunki umowy dotyczące retencji, eksportu i usunięcia danych.

Nie każdy dostawca udostępnia ten sam zakres eksportu. Sam plik CSV z decyzjami nie oznacza, że nowy CMP potrafi go zaimportować albo powiązać z tym samym użytkownikiem. Zapisuj oryginalny format, opis pól, strefę czasową i wersję konfiguracji.

Zakres retencji oraz podstawę przechowywania dawnych rejestrów ustal dla organizacji. Nie przechowuj wszystkiego bezterminowo tylko dlatego, że eksport jest dostępny, ale też nie usuwaj potrzebnych danych bez sprawdzenia obowiązków, umowy i procedur.

Krok 4. Zinwentaryzuj stronę niezależnie od starego CMP

Lista w panelu starego dostawcy może być niepełna albo nieaktualna. Wykonaj nowy skan oraz ręczne przejście przez ścieżki, które wymagają interakcji.

Sprawdź co najmniej:

• stronę główną i główne szablony treści;
• landing page kampanii;
• formularz kontaktowy i zapis do newslettera;
• logowanie i konto użytkownika;
• film, mapę, czat oraz widżety zewnętrzne;
• produkt, koszyk, kasę i podziękowanie;
• popupy oraz elementy ładowane po kliknięciu;
• wersję mobilną;
• subdomeny i wersje językowe.

Połącz kilka źródeł:

Źródło	Co pokazuje
skaner	zasoby i cookies znalezione na odwiedzonych adresach
Source	kody osadzone bezpośrednio w HTML
Network	rzeczywiste żądania i ich inicjatory
Application	cookies, local storage i session storage
GTM Preview	tagi, reguły, zmienne i kolejność zdarzeń
ustawienia CMS	wtyczki, motyw, builder i kody globalne
backend	zdarzenia serwerowe, CAPI i integracje niedostępne w przeglądarce

Automatyczny skan nie przejdzie samodzielnie każdej kasy, nie wypełni chronionego formularza i nie potwierdzi stanu zdarzenia serwerowego. Uzupełnij go ręcznymi scenariuszami.

Krok 5. Zdecyduj, co zrobić z wcześniejszymi zgodami

Zmiana dostawcy nie przenosi automatycznie decyzji użytkowników. Stary i nowy CMP mogą różnić się:

• nazwą oraz formatem cookie zgody;
• pseudonimowym identyfikatorem użytkownika;
• wersją i treścią komunikatu;
• liczbą kategorii;
• celami przetwarzania;
• listą dostawców;
• zakresem domen i regionów;
• sposobem zapisywania czasu oraz dowodu wyboru;
• okresem ważności decyzji.

Techniczne przeniesienie można rozważać tylko wtedy, gdy oba systemy wspierają taki proces, da się wiarygodnie odwzorować wybór, a zakres nowej konfiguracji nie rozszerza wcześniejszej decyzji. Import powinien być udokumentowany i przetestowany na kopiach danych.

Ponowne wyświetlenie banera może być potrzebne, gdy:

• nowy CMP nie rozumie starego formatu;
• nie można powiązać decyzji z właściwą przeglądarką;
• zmieniły się cele, kategorie lub dostawcy;
• nie da się potwierdzić treści i wersji wcześniejszej informacji;
• dane są niepełne albo utraciły ważność według przyjętej polityki;
• ocena prawna wskazuje potrzebę ponownego wyboru.

Nie ustawiaj granted tylko dlatego, że nowe narzędzie nie znalazło starej decyzji. Brak wiarygodnego mapowania powinien prowadzić do stanu domyślnego przyjętego przez organizację i, gdy to potrzebne, do ponownego pytania użytkownika.

Pytanie o ważność wcześniejszej zgody nie ma jednej odpowiedzi dla każdego wdrożenia. Zależy od zakresu decyzji i informacji, a nie tylko od nazwy dostawcy CMP. Tę część należy poddać moderacji prawnej.

Krok 6. Skonfiguruj nowy CMP przed publikacją

Nową konfigurację przygotuj na stagingu, domenie testowej albo w trybie podglądu, który nie wpływa na użytkowników produkcji.

Ustaw i sprawdź:

• właściwe domeny, subdomeny i protokół HTTPS;
• regiony oraz wersje językowe;
• treść pierwszej i drugiej warstwy banera;
• przyciski akceptacji, odmowy i ustawień;
• kategorie, opisy, cele i dostawców;
• panel ponownego otwierania preferencji;
• okres przechowywania wyboru;
• reguły blokowania skryptów i osadzonych treści;
• wyjątki dla technologii rzeczywiście niezbędnych;
• integrację z GTM, GA4, reklamami i narzędziami zewnętrznymi;
• zapis decyzji oraz dostępne raporty.

Nie kopiuj automatycznie wszystkich kategorii ze starego CMP. Najpierw porównaj ich znaczenie. Kategoria „Statystyka” w jednym systemie nie musi obejmować dokładnie tych samych technologii co „Analityka” w drugim.

Jeśli migrujesz do CookieStart na WordPressie, aktualna strona wtyczki CookieStart opisuje połączenie domeny, skanowanie, klasyfikację, blokowanie i historię zgód. Konfigurację konkretnej instalacji trzeba jednak sprawdzić na stagingu i później na produkcji.

Krok 7. Zmapuj Consent Mode, GTM i pozostałe tagi

Nowy CMP powinien stać się jednym źródłem aktualnego wyboru. W przypadku Google Consent Mode v2 sprawdź:

• ad_storage;
• analytics_storage;
• ad_user_data;
• ad_personalization.

Stan domyślny musi pojawić się przed tagami, które go używają. Po akceptacji, odmowie lub zmianie preferencji CMP powinien wysłać aktualizację na tej samej stronie. Google podkreśla tę kolejność w dokumentacji Consent Mode.

Podczas migracji usuń albo wyłącz:

• tag starego CMP w GTM;
• drugi consent default;
• stare zdarzenia akceptacji i odmowy;
• zmienne odczytujące cookie poprzedniego systemu;
• reguły zależne od dawnych nazw kategorii;
• kod update pozostawiony w motywie lub wtyczce;
• wyjątki i blokady, których właścicielem był stary CMP.

Nie kasuj tagów GA4, Google Ads ani innych usług tylko dlatego, że są powiązane z dawnymi regułami. Najpierw zmapuj ich docelowe zachowanie.

Consent Mode dotyczy obsługiwanych usług Google. Meta Pixel, TikTok, Microsoft Clarity, narzędzie czatu albo film osadzony zewnętrznie wymagają osobnej kontroli. Poprawne cztery sygnały nie dowodzą, że te technologie respektują wybór.

Jeżeli CookieStart ma obsługiwać integrację Google, aktualny zakres funkcji i sposób testu opisuje strona Consent Mode v2 w CookieStart.

Krok 8. Przygotuj migrację na WordPressie

Na WordPressie stary baner może pochodzić z miejsca innego niż lista aktywnych wtyczek. Sprawdź:

1. Wtyczki CMP, analityczne i reklamowe.
2. Wtyczki dodające kod do nagłówka lub stopki.
3. Ustawienia motywu i motywu potomnego.
4. header.php, footer.php i functions.php.
5. Elementor Custom Code oraz globalne szablony buildera.
6. Must-Use Plugins w wp-content/mu-plugins.
7. Google Tag Manager i drugi kontener.
8. Cache strony, serwera, hostingu i CDN.
9. Zoptymalizowane pliki JavaScript i service worker.
10. Osobną instalację w katalogu albo subdomenie.

Nową wtyczkę można przygotować wcześniej, ale nie uruchamiaj dwóch frontendowych mechanizmów zgód dla tych samych użytkowników. Jeśli produkt pozwala skonfigurować konto i domenę bez emisji banera, wykorzystaj ten tryb. W przeciwnym razie pracuj na stagingu.

Nie wyłączaj wszystkich wtyczek na produkcji w celu znalezienia konfliktu. Testuj na stagingu, a na żywej stronie wykonuj tylko kontrolowane zmiany z możliwością szybkiego powrotu.

Krok 9. Wykonaj kontrolowane przełączenie

Najbezpieczniejszy model to pojedyncza, przygotowana publikacja albo bardzo krótkie okno zmian. Dokładna kolejność zależy od architektury, ale cel jest stały:

• użytkownik nie trafia na stronę bez właściwego mechanizmu zgód;
• dwa CMP nie działają równocześnie;
• nowy stan domyślny obowiązuje przed tagami;
• stare SDK nie aktualizuje decyzji w tle.

Przykładowa procedura:

1. Potwierdź backup, wersję GTM i gotowy plan powrotu.
2. Zatrzymaj publikacje treści, tagów i wtyczek na czas zmiany.
3. Opublikuj przygotowaną konfigurację nowego CMP.
4. Wyłącz frontend starego CMP we wszystkich znalezionych punktach.
5. Włącz docelowy kod nowego CMP i właściwą wersję GTM.
6. Wyczyść cache WordPressa, serwera, CDN i plików zoptymalizowanych.
7. Otwórz czystą sesję jako niezalogowany użytkownik.
8. Sprawdź dokładnie jeden baner i stan domyślny.
9. Wykonaj najważniejsze scenariusze odmowy, akceptacji i funkcji biznesowych.
10. Jeśli wystąpi warunek powrotu, przywróć wcześniej przetestowaną wersję.

Równoległe porównanie starego i nowego systemu wykonuj na oddzielnych środowiskach albo za pomocą kontrolowanych grup testowych zaprojektowanych przez zespół. Nie wyświetlaj dwóch niezależnych banerów temu samemu użytkownikowi produkcji.

Krok 10. Przetestuj stronę po migracji

Sprawdź, czy stary CMP został usunięty

Miejsce	Oczekiwany wynik
Source	brak starego SDK, identyfikatora i kodu inicjalizacyjnego
Network	brak nowych żądań do starego CDN, API i endpointów
Elements	jeden kontener banera i jeden panel preferencji
Application	stare cookie zgody nie jest ponownie tworzone przez aktywny kod
Console	brak błędów i wywołań związanych ze starym CMP
GTM Preview	stary tag, zmienne i zdarzenia nie uruchamiają się
Tag Assistant	jeden spójny ciąg stanu domyślnego i aktualizacji

Stare cookie może pozostać w przeglądarce do wygaśnięcia, nawet gdy kod został usunięty. Ważne jest, czy stary system nadal je odczytuje, odnawia albo na jego podstawie steruje tagami. Usuwanie istniejących danych powinno wynikać z planu migracji i dokumentacji obu narzędzi.

Wykonaj macierz scenariuszy

Każdy główny scenariusz rozpocznij w nowej sesji.

Scenariusz	Co sprawdzić	Warunek pozytywnego wyniku
pierwsza wizyta	baner, cookies, storage i tagi	jeden baner oraz zamierzony stan domyślny
brak interakcji	opcjonalne technologie	zachowanie zgodne z przyjętym trybem
odrzucenie	tagi, cztery sygnały i zapis	odmowa nie jest nadpisana
tylko analityka	mapowanie kategorii	marketing pozostaje odrzucony
tylko marketing, jeśli interfejs to umożliwia	niezależność kategorii	analityka nie otrzymuje niezamierzonej zgody
akceptacja wszystkiego	aktualizacja i bieżąca strona	tagi reagują bez duplikatów
wycofanie	panel, nowy stan i dalsze działania	kolejne zdarzenia respektują zmianę
następna podstrona	trwałość decyzji	wybór jest odtworzony przed tagami
ponowna wizyta	pamięć wyboru	CMP nie nadaje innego stanu
formularz	sukces i zdarzenie lead	formularz działa, zdarzenie występuje raz
koszyk i kasa	sesja, płatność i skrypty	odmowa nie psuje funkcji niezbędnych do zakupu
zakup	identyfikator, wartość, waluta	jedna poprawna konwersja w dozwolonym scenariuszu
urządzenie mobilne	interfejs i przyciski	baner nie zasłania ważnych funkcji
różne regiony	reguły geograficzne	wariant odpowiada założeniom

Sprawdź Consent Mode w Tag Assistant

W nowej sesji połącz stronę z Tag Assistant. Przed kliknięciem banera znajdź najwcześniejsze zdarzenie Consent i sprawdź On-page Default. Po zapisaniu wyboru przejdź do najnowszego zdarzenia oraz On-page Update. Google opisuje ten test w instrukcji diagnostyki Consent Mode.

Szukaj zwłaszcza:

• dwóch poleceń default pochodzących z różnych systemów;
• aktualizacji starego CMP;
• braku jednego z czterech sygnałów;
• zmiany na granted mimo odmowy;
• aktualizacji dopiero po przeładowaniu;
• taga zablokowanego przed zgodą, który nie reaguje po akceptacji;
• duplikatów GA4, Google Ads i zdarzeń e-commerce.

Monitoruj stronę po zmianie

Test w dniu publikacji nie wykryje wszystkich problemów. Przez ustalony okres monitoruj:

• wyświetlanie banera na kluczowych szablonach;
• błędy JavaScript i nieudane żądania;
• odsetek akceptacji, odmowy i braku interakcji;
• liczbę sesji GA4, konwersji i źródła ruchu;
• kliknięcia oraz konwersje w platformach reklamowych;
• leady w CRM i zamówienia w sklepie;
• formularze, płatności i zwroty z zewnętrznych domen;
• wydajność strony;
• zgłoszenia użytkowników i zespołu obsługi.

Nie porównuj współczynnika zgód starego i nowego banera bez uwzględnienia różnic w treści, układzie, regionach, czasie ważności i sposobie liczenia. Ustal nową linię bazową po potwierdzeniu poprawnego działania.

Nie zakładaj też, że migracja lub Consent Mode odzyska wszystkie dane. Prawidłowe respektowanie odmowy może zmniejszyć obserwowalność w narzędziach analitycznych.

Kiedy zamknąć stare konto CMP?

Zamknięcie powinno nastąpić dopiero po:

• potwierdzeniu stabilnej pracy nowego CMP;
• eksporcie wszystkich potrzebnych danych;
• sprawdzeniu polityki retencji i usuwania;
• udokumentowaniu konfiguracji oraz wersji przełączenia;
• potwierdzeniu braku aktywnego starego kodu;
• zakończeniu okresu pozwalającego na bezpieczny powrót;
• ustaleniu, kto i gdzie przechowuje archiwum;
• sprawdzeniu warunków wypowiedzenia i rozliczenia.

Jeżeli stary dostawca przetwarzał dane w imieniu organizacji, zakończenie współpracy może wymagać działań określonych w umowie powierzenia oraz procedurze usunięcia lub zwrotu danych. Zakres należy zweryfikować z osobą odpowiedzialną za ochronę danych i umowy.

Najczęstsze błędy podczas migracji CMP

Objaw	Możliwa przyczyna	Co sprawdzić
dwa banery	stara wtyczka, GTM lub kod motywu nadal działa	Source, Network, wtyczki i kontenery
brak banera	nowa domena nie jest połączona albo cache ma starą wersję	status integracji, kod HTML i cache
tagi działają przed wyborem	brak blokowania lub kod poza CMP	Initiator, GTM i wtyczki
GA4 nie działa po akceptacji	brak aktualizacji albo zdarzenia po zmianie	Tag Assistant i reguły GTM
odmowa zmienia się na zgodę	stary update albo drugi CMP	dataLayer, kod strony i GTM
kategorie reagują razem	błędne mapowanie starej i nowej taksonomii	macierz technologii i wartości zgody
wybór znika na kolejnej stronie	domena, ścieżka lub zapis decyzji są błędne	Application i konfiguracja subdomen
formularz lub płatność nie działa	skrypt potrzebny do funkcji został zablokowany	klasyfikacja, Console i Network
dwa page_view albo purchase	tag pozostał w dwóch źródłach	identyfikatory, Initiator i wtyczki
tylko administrator widzi poprawny wynik	cache omija zalogowanych użytkowników	incognito, CDN i wersja anonimowa
stare cookie wraca	stare SDK nadal działa albo service worker podaje kod	Network, źródło i cache przeglądarki
spadek danych bez awarii biznesu	zmiana obserwowalności lub utrata pierwszej odsłony	zgody, tryb Consent Mode i UTM

Zakres prawny dla Polski i Unii Europejskiej

W Polsce art. 399 Prawa komunikacji elektronicznej dotyczy przechowywania informacji lub uzyskiwania dostępu do informacji w urządzeniu użytkownika. Wyjątki obejmują transmisję komunikatu oraz dostarczenie usługi żądanej przez użytkownika. Aktualny tekst jest dostępny w Elektronicznym Dzienniku Ustaw.

Europejska Rada Ochrony Danych w raporcie zespołu do spraw banerów cookies wskazuje między innymi na znaczenie możliwości wycofania zgody. Migracja nie powinna więc usuwać użytkownikowi dostępnego mechanizmu zmiany preferencji.

Ocena techniczna nie odpowiada samodzielnie na pytania:

• czy wcześniejsza zgoda nadal obejmuje te same cele i odbiorców;
• czy należy ponownie poprosić użytkownika o wybór;
• jaki okres retencji zastosować do dawnych rejestrów;
• czy treść nowego banera jest wystarczająca;
• które technologie są rzeczywiście niezbędne;
• jak obsłużyć rynki poza Polską i UE.

Te kwestie wymagają moderacji prawnej dla konkretnej organizacji. Samo wdrożenie nowego CMP nie stanowi gwarancji zgodności całej witryny.

Najczęstsze pytania o migrację CMP

Czy po zmianie CMP trzeba ponownie zapytać o zgodę?

Nie ma uniwersalnej odpowiedzi wynikającej wyłącznie ze zmiany dostawcy. Trzeba sprawdzić zakres wcześniejszej decyzji, treść informacji, kategorie, cele, dostawców, ważność oraz techniczną możliwość wiarygodnego odwzorowania wyboru. Jeśli mapowanie nie jest możliwe albo zakres się zmienił, ponowne pytanie może być potrzebne. Decyzję należy poddać ocenie prawnej.

Czy można uruchomić dwa CMP na czas migracji?

Można porównywać konfiguracje na oddzielnych środowiskach, ale nie należy pozostawiać dwóch niezależnych systemów zarządzających tymi samymi zgodami u jednego użytkownika produkcji. Mogą wysyłać sprzeczne stany, podwójnie blokować skrypty i pokazywać dwa banery.

Czy wystarczy odinstalować starą wtyczkę WordPress?

Nie zawsze. Kod może pozostać w GTM, motywie, builderze, dodatku do nagłówka, MU Plugin, cache CDN albo osobnej instalacji. Po zmianie sprawdź Source, Network, Application i GTM Preview.

Czy Consent Mode v2 przeniesie się automatycznie?

Nie. Nowy CMP musi ustawić właściwy stan domyślny, mapować kategorie na cztery sygnały i wysyłać aktualizację po decyzji. Stare tagi, zmienne i polecenia trzeba usunąć albo dostosować.

Co zrobić ze starym cookie zgody?

Najpierw ustal, czy jest potrzebne do mapowania. Po migracji sprawdź, czy stary kod nie odczytuje ani nie odnawia cookie. Jego usunięcie, pozostawienie do wygaśnięcia lub wykorzystanie w kontrolowanym imporcie powinno wynikać z dokumentacji i przyjętego planu.

Ile trwa migracja CMP?

Nie ma jednej wiarygodnej wartości. Czas zależy od liczby domen, języków, regionów, tagów, ścieżek sklepowych, integracji serwerowych, jakości dokumentacji i możliwości eksportu. Prosta strona i rozbudowany e-commerce wymagają innego zakresu testów.

Czy po migracji dane GA4 i reklam powinny być identyczne?

Nie. Nowy interfejs i reguły mogą zmienić odsetek decyzji, a poprawne respektowanie odmowy wpływa na obserwowalność. Istotne jest, czy tagi zachowują się zgodnie z decyzją i czy nie ma błędów, duplikatów ani utraty zdarzeń po akceptacji.

Czy można anulować stary abonament od razu po publikacji?

Lepiej zrobić to po eksporcie, stabilizacji, zakończeniu okresu powrotu i sprawdzeniu warunków umowy. Zbyt szybkie zamknięcie konta może utrudnić dostęp do konfiguracji, logów albo poprzedniego skryptu.

Zanim przełączysz dostawcę, sporządź niezależną listę technologii działających na stronie – zeskanuj stronę z CookieStart.