Analityka a prywatność: framework zgodności (consent, minimizacja danych, retencja) w 2026

Zanim w sklepie wystartuje kolejny skrypt analityczny, warto sprawdzić, czy ktoś potrafi wskazać cel, zakres danych, podstawę prawną i termin ich usunięcia, bo RODO wymaga ograniczenia przetwarzania do tego, co naprawdę niezbędne. GUS podał, że w 2025 roku analitykę danych prowadziło już 25,9% polskich przedsiębiorstw, o 6,6 punktu procentowego więcej niż dwa lata wcześniej (Główny Urząd Statystyczny, 2025), co oznacza więcej wdrożeń bez formalnej kontroli nad zgodami i retencją. Framework porządkuje te decyzje krok po kroku, od banera cookies po kontrolę dostawców i architekturę headless.

Framework zgodności: analityka zaczyna się od celu, a nie od narzędzia

Przed instalacją kolejnego skryptu analitycznego w firmie warto odpowiedzieć na cztery pytania:

• jaki cel biznesowy ma realizować pomiar,
• jakie dane są rzeczywiście potrzebne do tego celu,
• jaka podstawa prawna obejmuje każde przetwarzanie,
• jak długo dane pozostaną użyteczne, zanim trzeba je usunąć.

RODO wymaga ograniczenia danych do zakresu adekwatnego, stosownego i niezbędnego do celu przetwarzania. Zasada ta obejmuje identyfikatory użytkowników, adresy IP, identyfikatory urządzeń, dane o zamówieniach, historię wizyt oraz informacje przekazywane do narzędzi zewnętrznych (Parlament Europejski i Rada UE, 2016).

Sklep internetowy powinien traktować analitykę jako proces przetwarzania danych, wykraczający poza sam raport marketingowy. Warto opisać przepływ danych od przeglądarki, przez system zarządzania zgodami i narzędzie analityczne, aż po hurtownię danych, CRM i narzędzia reklamowe. Odsetek firm prowadzących taką analitykę systematycznie rośnie, a wraz z nim rośnie liczba wdrożeń bez odpowiedniej kontroli nad zgodami i retencją danych. Analityka przestaje być domeną wyspecjalizowanych działów i staje się częścią codziennego zarządzania sklepem, nawet tam, gdzie nikt formalnie nie zajmuje się ochroną danych.

Zgoda na analitykę i pliki cookie w polskim sklepie internetowym

Zgoda w rozumieniu RODO musi być dobrowolna, konkretna, świadoma i jednoznaczna. Powinna wynikać z oświadczenia albo wyraźnego działania potwierdzającego (Prezes Urzędu Ochrony Danych Osobowych, 2025).

Dla sklepu internetowego przekłada się to na konkretne wymagania wobec banera cookies i konfiguracji tagów:

Element	Wymaganie	Typowy błąd
Uruchomienie skryptów	Analityczne cookie startują po zgodzie	Tagi ładują się przed kliknięciem
Przyciski	„Akceptuj” i „Odrzuć” na tym samym poziomie	Odrzucenie schowane w ustawieniach
Domyślny stan	Pola dla analityki niezaznaczone	Checkbox zaznaczony z góry
Zakres zgody	Analityka rozdzielona od marketingu	Jedna zgoda na wszystko
Wycofanie	Równie łatwe jak udzielenie	Brak widocznej opcji zmiany

Europejska Rada Ochrony Danych wskazuje, że informacja potrzebna do uzyskania ważnej zgody powinna obejmować tożsamość administratora, cel każdego procesu, rodzaj zbieranych danych oraz prawo do wycofania zgody (Europejska Rada Ochrony Danych, 2020). UODO dodaje, że użytkownik musi mieć możliwość odrzucenia plików bez ograniczenia dostępu do serwisu (Prezes Urzędu Ochrony Danych Osobowych, 2025).

Porada ecommerceblog.pl: po wdrożeniu banera wykonaj test w nowym oknie przeglądarki z wyłączonymi rozszerzeniami blokującymi reklamy. Przed kliknięciem „Akceptuj” sprawdź w narzędziach deweloperskich, czy uruchamiają się skrypty analityczne i tagi reklamowe, następnie kliknij „Odrzuć” i powtórz test. Sam wygląd banera nic nie potwierdza, decyduje moment faktycznego uruchomienia skryptów.

Podstawa prawna: zgoda, uzasadniony interes i analityka bez identyfikacji

RODO nie narzuca jednej podstawy prawnej dla każdego rodzaju analityki. Podstawa powinna wynikać z celu, zakresu danych, sposobu identyfikacji użytkownika i technologii pomiaru.

Zgoda jest najprostszą podstawą dla analityki opartej na plikach cookie lub identyfikatorach rozpoznających użytkownika między wizytami. Musi być przy tym możliwa do wykazania, więc system zarządzania zgodami powinien zapisywać datę, wersję komunikatu, zakres zgody oraz jej wycofanie.

Prawnie uzasadniony interes można analizować przy pomiarach koniecznych do bezpieczeństwa czy działania usługi, ale wymaga to testu równowagi między interesem administratora, niezbędnością przetwarzania a wpływem na użytkownika. Samo nazwanie narzędzia „analitycznym” nie przesądza o podstawie prawnej.

UODO opisuje przykład Plausible Analytics, narzędzia bez plików cookie, które według polityki urzędu nie zbiera danych osobowych, a mierzy odwiedziny, odsłony, źródła wejścia, przeglądarkę, czas na stronie i błędy 404 (Prezes Urzędu Ochrony Danych Osobowych, 2018). Brak cookies nie oznacza automatycznie braku danych osobowych. Ocena musi uwzględniać adres IP, identyfikatory, dane urządzenia i możliwość połączenia z kontem klienta, a pseudonimizacja zmniejsza ryzyko, ale nie zmienia statusu danych na nieosobowe.

Minimalizacja danych: jak projektować pomiar odpowiadający na pytania biznesowe

Minimalizacja zaczyna się od pytania, jaką decyzję ma wspierać dany raport. Jeśli zespół chce wiedzieć, ile osób przechodzi z karty produktu do koszyka, potrzebuje zdarzeń wyświetlenia produktu i dodania do koszyka. Nie musi przy tym przesyłać adresu e-mail, numeru telefonu ani całej zawartości koszyka.

Plan pomiarowy warto podzielić na kategorie danych według funkcji, jaką pełnią:

• dane konieczne do pomiaru sprzedaży,
• dane potrzebne do oceny działania strony,
• dane potrzebne do personalizacji,
• dane wykorzystywane w reklamie,
• dane zbierane wyłącznie dlatego, że domyślna konfiguracja narzędzia je przewiduje.

Szczególnej kontroli w sklepie internetowym wymagają:

• adres e-mail i numer telefonu,
• imię i nazwisko,
• adres dostawy,
• numer klienta,
• numer zamówienia,
• pełny adres URL z parametrami,
• treść wyszukiwania wpisana przez użytkownika,
• dane ze zdarzeń zakupowych,
• identyfikatory kont reklamowych,
• identyfikatory urządzeń i przeglądarek.

Do raportowania często wystarczają dane zagregowane, przedziały wartości albo identyfikatory jednorazowe. Danych osobowych nigdy nie powinno się przesyłać w adresie URL, a warstwę danych trzeba sprawdzać regularnie, bo błąd konfiguracji łatwo powoduje wysyłkę danych do wielu narzędzi jednocześnie. Więcej o typowych pułapkach po stronie danych opisuje checklista porządnych danych z testami jakości.

Porada ecommerceblog.pl: przed uruchomieniem nowego zdarzenia utwórz kartę pomiaru z sześcioma polami: nazwa zdarzenia, cel biznesowy, parametry, źródło danych, podstawa prawna i termin usunięcia. Jeśli nie da się jasno opisać celu i retencji, zdarzenie nie powinno trafić do wdrożenia.

Retencja danych: osobny termin dla surowych danych, raportów i kopii

RODO wymaga, aby dane osobowe były przechowywane w formie umożliwiającej identyfikację nie dłużej, niż to konieczne dla celów przetwarzania (Parlament Europejski i Rada UE, 2016). Trybunał Sprawiedliwości Unii Europejskiej potwierdził konieczność ustanowienia terminów usuwania lub regularnej kontroli danych (Trybunał Sprawiedliwości Unii Europejskiej, 2024).

W praktyce sklep powinien odrębnie opisać retencję dla różnych typów danych:

Typ danych	Poziom identyfikacji	Typowy horyzont przeglądu
Surowe zdarzenia i logi	wysoki	krótki
Dane przypisane do użytkownika	wysoki	krótki do średniego
Dane o zamówieniach	wysoki, wymogi rachunkowe	wynika z przepisów finansowych
Raporty zagregowane	niski	długi
Kopie zapasowe u dostawców	zależny od konfiguracji	wymaga odrębnej weryfikacji

Nie istnieje jeden uniwersalny okres retencji dla każdego sklepu. Termin powinien wynikać z celu, cyklu sprzedażowego, obowiązków rachunkowych oraz ryzyka identyfikacji. Dane potrzebne do analizy sezonowości mogą wymagać dłuższego przechowywania po zagregowaniu, natomiast surowe dane na poziomie użytkownika zwykle powinny mieć krótszy termin.

Porada ecommerceblog.pl: ustaw trzy różne terminy w rejestrze retencji: dla danych surowych, dla danych pseudonimizowanych i dla raportów zagregowanych. Raz na kwartał sprawdzaj, czy automatyczne usuwanie faktycznie działa, bo wiele wdrożeń ma opisany termin w dokumentacji, ale żadnej aktywnej reguły w narzędziu.

Zarządzanie zgodami w architekturze headless i przy wielu narzędziach

Architektura headless zwiększa liczbę punktów, w których dochodzi do przetwarzania danych. Interfejs sklepu może działać w jednym systemie, koszyk w drugim, płatność w zewnętrznym komponencie, a analityka w chmurze. Zgoda użytkownika musi być przekazywana między tymi elementami w sposób kontrolowany, a decyzję o samej architekturze warto podejmować z pełną świadomością konsekwencji dla zgodności, o czym pisze framework decyzji dotyczący headless commerce.

• przechowywać stan zgody według celu,
• przekazywać go do menedżera tagów,
• blokować tagi przed uzyskaniem zgody,
• rejestrować zmiany i wycofania,
• obsługiwać różne subdomeny,
• rozwijać rozróżnianie użytkowników zalogowanych i niezalogowanych.

Zgody marketingowe nie powinny łączyć się automatycznie z analitycznymi.

Przy analityce serwerowej trzeba pamiętać, że przeniesienie wysyłki danych z przeglądarki na serwer nie usuwa obowiązków administratora. Nadal konieczne jest określenie, jakie dane są wysyłane, do jakiego odbiorcy, w jakim celu i na jakiej podstawie prawnej. Rozporządzenie w sprawie sztucznej inteligencji zaczęło mieć zasadnicze zastosowanie od 2 sierpnia 2026 roku, z wyjątkami określonymi w przepisie (Parlament Europejski i Rada UE, 2024). Jeśli dane analityczne trafiają do systemów AI, na przykład do segmentacji klientów czy prognozowania popytu, zwykłe raportowanie należy oddzielić od profilowania i automatycznego podejmowania decyzji. Zasady etycznego wykorzystania takich danych opisuje framework etycznego AI dla personalizacji i pricingu.

Kontrola dostawców, transfery danych i rozliczalność

Przed wdrożeniem narzędzia sklep powinien ustalić, kto jest administratorem, kto podmiotem przetwarzającym, a kto niezależnym odbiorcą danych. Dostawca może wykorzystywać dane do własnych celów, więc sama umowa powierzenia nie zawsze opisuje całą relację.

Lista kontrolna przy ocenie dostawcy powinna obejmować:

1. zakres zbieranych danych,
2. cele, jakie dostawca realizuje własnymi środkami,
3. lokalizację hostingu i podwykonawców,
4. transfery poza Europejski Obszar Gospodarczy,
5. szyfrowanie i mechanizmy usuwania danych,
6. sposób obsługi żądań użytkowników,
7. dostępność audytów i informacji o incydentach,
8. możliwość ograniczenia zbierania danych do niezbędnego minimum.

Data Act stosuje się od 12 września 2025 roku i reguluje między innymi dostęp do danych generowanych przez produkty i usługi powiązane, przy zachowaniu ochrony danych osobowych (Parlament Europejski i Rada UE, 2023). W typowym sklepie nie zastępuje RODO, choć ma znaczenie przy urządzeniach połączonych, aplikacjach mobilnych i usługach generujących dane użytkownika.

Rozliczalność wymaga zachowania dowodów: wersji planu pomiarowego, konfiguracji systemu zarządzania zgodami, listy tagów, testów, umów z dostawcami i decyzji o retencji. Dokumentacja powinna pozwalać odtworzyć, dlaczego dane były zbierane i kto miał do nich dostęp. Problemy z takim udokumentowaniem często wynikają z pospiesznych wdrożeń opisanych w artykule o błędach przy wdrażaniu AI w sklepie.

Lista wdrożeniowa frameworku na 2026 rok

1. spisz wszystkie narzędzia, skrypty, tagi, integracje i eksporty danych,
2. przypisz każdemu narzędziu cel, dane, odbiorcę i podstawę prawną,
3. sprawdź, które skrypty uruchamiają się przed uzyskaniem zgody,
4. rozdziel analitykę, personalizację i marketing,
5. usuń zbędne parametry oraz dane osobowe z adresów URL,
6. przygotuj plan pomiarowy oparty na konkretnych pytaniach biznesowych,
7. ustal terminy usuwania dla surowych danych, identyfikatorów i kopii zapasowych,
8. zweryfikuj umowy oraz transfery danych poza Europejski Obszar Gospodarczy,
9. przetestuj akceptację, odrzucenie i wycofanie zgody,
10. przeprowadź przegląd po każdej zmianie systemu, dostawcy lub celu analitycznego.

W 2025 roku 69,7% osób w wieku od 16 do 74 lat w Polsce kupowało przez internet w ciągu poprzednich 12 miesięcy (Główny Urząd Statystyczny, 2025). Skala zakupów online zwiększa znaczenie jakości pomiaru, ale też ryzyko wynikające z niekontrolowanego łączenia danych zakupowych, identyfikatorów i informacji o zachowaniu.

Sklepy, które planują migrację systemu lub zmianę dostawcy analityki, powinny wliczyć te ryzyka w budżet projektu, bo koszty porządkowania danych po fakcie bywają wyższe niż koszt audytu przed startem, co opisuje tekst o ukrytych kosztach migracji danych.