Jak anonimizować statystyki wyszukiwań użytkowników katalogu

Statystyki wyszukiwań w katalogu wyglądają niewinnie: fraza, miejscowość, godzina, liczba wyników i kliknięta wizytówka. Problem zaczyna się wtedy, gdy kilka takich informacji pozwala odtworzyć zachowanie konkretnego użytkownika. Zapytanie „psychiatra dziecięcy”, mała miejscowość, dokładny czas oraz stały identyfikator urządzenia tworzą zapis, którego nie można bezpiecznie nazwać anonimowym.

Najważniejsza zasada brzmi: nie anonimizuje się pojedynczej kolumny, lecz cały zestaw danych oraz możliwość łączenia go z innymi źródłami. Usunięcie adresu e-mail nie pomoże, jeżeli w tabeli pozostaną pełny adres IP, identyfikator sesji, dokładny znacznik czasu i historia kolejnych zapytań. Taki rekord nadal może wskazywać konkretną osobę.

Najpierw ustal, które dane rzeczywiście są potrzebne

Typowy katalog zapisuje więcej informacji, niż później wykorzystuje. W logach trafiają się pełne adresy IP, parametry urządzenia, identyfikatory reklamowe, współrzędne GPS, treść zapytania, dokładna godzina, wybrana kategoria, kliknięty profil firmy i adres strony odsyłającej. Większość raportów biznesowych potrzebuje jednak tylko kilku elementów:

• znormalizowanej frazy lub kategorii,
• przybliżonej lokalizacji,
• przedziału czasowego,
• liczby wyszukiwań,
• liczby wyświetleń i kliknięć,
• informacji, czy wyszukiwanie zwróciło wyniki.

To rozróżnienie powinno zostać wykonane przed zapisaniem danych, a nie dopiero podczas tworzenia miesięcznego raportu. Jeżeli pełny adres IP nie jest potrzebny do zabezpieczenia serwisu, nie powinien trafiać do tabeli analitycznej. Gdy jest potrzebny do wykrywania nadużyć, należy przechowywać go oddzielnie, z krótkim terminem retencji i dostępem ograniczonym do administratorów odpowiedzialnych za bezpieczeństwo.

W praktyce dobrze działa podział na trzy warstwy:

1. Log bezpieczeństwa – zawiera dane techniczne potrzebne do wykrywania ataków, błędów i automatycznego ruchu. Retencja zwykle wynosi od 7 do 30 dni, a przy udokumentowanym ryzyku nadużyć może być dłuższa.
2. Dane operacyjne – służą do diagnozowania jakości wyszukiwarki, na przykład błędnych zapytań lub problemów z indeksowaniem. Powinny być pseudonimizowane i przechowywane możliwie krótko.
3. Statystyki raportowe – zawierają wyłącznie zagregowane wyniki, bez możliwości prześledzenia historii jednej osoby.

Najczęstszy błąd polega na skopiowaniu surowych logów do hurtowni danych i pozostawieniu ich tam „na wszelki wypadek”. Po kilku miesiącach nikt nie pamięta, po co zapisano część pól, ale dane nadal są dostępne dla analityków, administratorów i narzędzi zewnętrznych. To zwiększa skutki ewentualnego wycieku bez wyraźnej korzyści biznesowej.

Przed wdrożeniem analityki należy przygotować prostą tabelę decyzyjną. Dla każdego pola trzeba wskazać:

• cel zbierania,
• podstawę przetwarzania,
• odbiorców danych,
• czas przechowywania,
• sposób ograniczenia identyfikowalności,
• termin automatycznego usunięcia.

Jeżeli przy danym polu nie można wpisać konkretnego celu, pole należy usunąć.

Agregacja musi uniemożliwiać odtworzenie zachowania jednej osoby

Pseudonimizacja nie jest anonimizacją. Zamiana identyfikatora użytkownika na skrót lub losowy numer nadal pozwala śledzić kolejne wyszukiwania tej samej osoby. Takie dane pozostają danymi osobowymi, szczególnie gdy administrator zachowuje klucz, tabelę powiązań albo dostęp do innych informacji umożliwiających identyfikację.

Bezpieczniejszy model zaczyna się od ograniczenia dokładności danych.

Pełnego adresu IP nie należy przenosić do statystyk. W przypadku IPv4 można usunąć ostatni oktet, na przykład zamienić 83.10.24.167 na 83.10.24.0. Nie daje to jednak automatycznie anonimowości. W małej organizacji, sieci firmowej albo słabo zaludnionym regionie skrócony adres nadal może zawęzić grupę do kilku osób. Dlatego do raportów lepiej przenosić wyłącznie kraj, województwo albo duży obszar statystyczny.

Dokładny czas również jest ryzykowny. Zapis 2026-08-01 13:42:17 ułatwia zestawienie logu z monitoringiem, historią serwera, danymi operatora lub zdarzeniem w systemie firmy. W standardowych raportach wystarcza:

• godzina bez minut – przy dużym ruchu,
• przedział dwu- lub czterogodzinny – przy średnim ruchu,
• dzień – przy niewielkiej liczbie wyszukiwań,
• tydzień lub miesiąc – dla rzadkich kategorii i małych miejscowości.

Frazy wpisywane przez użytkowników wymagają osobnego traktowania. Zapytanie może zawierać nazwisko, numer telefonu, adres, numer sprawy, objawy choroby albo inną informację prywatną. Nie wolno zakładać, że pole wyszukiwarki zawiera wyłącznie neutralne hasła.

Przed zapisaniem frazy w warstwie analitycznej należy:

• usuwać adresy e-mail i numery telefonów,
• wykrywać numery PESEL, NIP, REGON i ciągi przypominające numery dokumentów,
• zastępować dokładne adresy kategorią lokalizacji,
• ograniczać długość zapytania, na przykład do 100–150 znaków,
• normalizować wielkość liter, odmiany i literówki,
• przypisywać popularne zapytania do kategorii zamiast zachowywać pełną treść.

Przykładowo zapytania „dentysta dziecięcy Mokotów”, „stomatolog dla dziecka Warszawa Mokotów” i „dentysta dziecko Mokotów” można raportować jako jedną kategorię: stomatologia dziecięca – Warszawa, Mokotów. Analityk nadal widzi popyt, lecz nie otrzymuje pełnej historii wpisywanej przez użytkownika.

Kolejną barierą jest minimalna liczebność grupy. Nie należy udostępniać wyniku, jeżeli dana kombinacja cech pojawia się tylko raz lub kilka razy. Rozsądny próg operacyjny dla wewnętrznego panelu to co najmniej 5–10 zdarzeń w jednej grupie. Dla raportów przekazywanych partnerom lub publikowanych publicznie bezpieczniej stosować próg 10–20 zdarzeń.

Nie są to liczby zapisane w RODO. To progi techniczne, które trzeba dostosować do ryzyka. Grupa 10 wyszukiwań może być wystarczająca dla kategorii „restauracja” w Warszawie, ale zbyt mała dla zapytania dotyczącego terapii uzależnień w gminie liczącej kilka tysięcy mieszkańców.

Jeżeli grupa nie osiąga ustalonego minimum, system powinien:

• ukryć wynik,
• połączyć go z kategorią „pozostałe”,
• rozszerzyć obszar geograficzny,
• wydłużyć okres raportowania,
• uogólnić frazę do szerszej kategorii.

Za szczególnie ryzykowne należy uznać łączenie następujących elementów: rzadka fraza + mała miejscowość + dokładny czas + stały identyfikator. Każdy z nich osobno może wyglądać nieszkodliwie, ale razem tworzą charakterystyczny ślad użytkownika.

Jak zbudować statystyki, które nadal są użyteczne

Dobra anonimizacja nie polega na usunięciu tylu informacji, że raport przestaje odpowiadać na pytania biznesowe. Trzeba zacząć od decyzji, jakie wnioski mają wynikać ze statystyk.

Jeżeli celem jest ocena brakujących ofert, wystarczą:

• kategoria zapytania,
• województwo lub powiat,
• liczba wyszukiwań bez wyników,
• tydzień albo miesiąc,
• przedział liczby użytkowników.

Jeżeli celem jest poprawa wyszukiwarki, potrzebne będą dodatkowo znormalizowane warianty fraz, liczba zwróconych wyników i informacja o kliknięciu. Nadal nie jest potrzebny pełny profil urządzenia ani wielomiesięczna historia jednej osoby.

Najpraktyczniejsza architektura zakłada, że surowe zdarzenie jest przetwarzane natychmiast:

1. System odbiera zapytanie.
2. Moduł filtrujący usuwa dane bezpośrednio identyfikujące.
3. Fraza zostaje przypisana do kategorii.
4. Lokalizacja jest uogólniana.
5. Czas trafia do ustalonego przedziału.
6. Zdarzenie zwiększa licznik odpowiedniej grupy.
7. Surowa wersja jest usuwana albo trafia do oddzielnego, krótkotrwałego logu technicznego.

Dzięki temu podstawowa tabela analityczna nie zawiera pojedynczych historii wyszukiwania. Zawiera liczniki, na przykład:

stomatologia dziecięca | Warszawa-Mokotów | tydzień 31 | 286 wyszukiwań | 41 bez wyników

Taki rekord pozwala ocenić popyt i jakość katalogu, ale nie pokazuje, kto, o której minucie i z jakiego urządzenia wykonał zapytanie.

W panelach partnerów trzeba dodatkowo ograniczyć możliwość wykonywania wielu nakładających się filtrów. Nawet prawidłowo zagregowane dane mogą zostać rozbite na małe grupy przez serię zapytań: najpierw cały miesiąc, następnie poszczególne tygodnie, dni i lokalizacje. Różnica między wynikami pozwala czasem wyliczyć ukrywaną wartość.

Dlatego panel powinien mieć:

• stały minimalny próg wyświetlenia,
• ograniczony zestaw filtrów,
• blokadę eksportu małych grup,
• rejestrowanie pobrań raportów,
• limity liczby zapytań,
• takie same zasady zaokrąglania w panelu i plikach eksportowych.

Przy dużych zbiorach można zastosować kontrolowane dodawanie szumu, czyli niewielką zmianę prezentowanych wartości. Raport może na przykład pokazywać 1 240 wyszukiwań zamiast dokładnej wartości 1 237. Przy analizie trendów różnica jest nieistotna, a utrudnia ustalenie, czy konkretne zdarzenie zostało wliczone do wyniku.

Bardziej zaawansowanym rozwiązaniem jest prywatność różnicowa. Wymaga ona jednak ustalenia budżetu prywatności i kontroli liczby zapytań. Źle skonfigurowany mechanizm daje fałszywe poczucie bezpieczeństwa albo zniekształca raport tak mocno, że dane tracą znaczenie. Dla małego katalogu prostsza agregacja, minimalne progi i krótka retencja zwykle dają lepszy stosunek kosztu do efektu.

Przed udostępnieniem danych trzeba przeprowadzić trzy testy:

• Wyodrębnienie: czy pojedynczy rekord albo bardzo małą grupę można odróżnić od pozostałych?
• Łączenie: czy dane można zestawić z logami serwera, CRM, kontami użytkowników lub publicznymi informacjami?
• Wnioskowanie: czy z raportu można ustalić wrażliwą cechę lub zachowanie konkretnej osoby?

Jeżeli odpowiedź na którekolwiek pytanie brzmi „tak”, zbiór nie powinien być traktowany jako anonimowy. Trzeba zwiększyć agregację, usunąć kolejne pola albo ograniczyć dostęp.

Dodatkowe informacje na: katalog NAP – https://aiqo.pl.

FAQ

Czy usunięcie adresu IP wystarczy do anonimizacji?
Nie. Użytkownika można nadal rozpoznać po identyfikatorze sesji, dokładnym czasie, lokalizacji, treści zapytań albo charakterystycznej sekwencji kliknięć.

Czy zahaszowany identyfikator użytkownika jest anonimowy?
Zwykle nie. Stały hash pozwala łączyć zdarzenia tej samej osoby. Jeżeli można go odtworzyć, porównać ze słownikiem wartości albo połączyć z inną tabelą, dane pozostają pseudonimizowane.

Jak długo przechowywać surowe logi wyszukiwań?
Należy wybrać najkrótszy okres wystarczający do konkretnego celu. Dla diagnostyki i bezpieczeństwa często stosuje się 7–30 dni. Dłuższa retencja wymaga rzeczywistego uzasadnienia, kontroli dostępu i automatycznego usuwania.

Jaki minimalny próg liczebności przyjąć?
Dla wewnętrznych statystyk można rozpocząć od 5–10 zdarzeń, a dla danych publicznych lub przekazywanych partnerom od 10–20. Próg trzeba podnieść dla małych miejscowości, rzadkich zapytań i kategorii ujawniających zdrowie, przekonania lub problemy osobiste.

Czy zagregowane dane zawsze przestają być danymi osobowymi?
Nie. Agregat obejmujący jedną osobę albo grupę łatwą do rozpoznania nadal może pozwalać na identyfikację. Problemem są także filtry umożliwiające stopniowe zawężenie wyniku.

Czy można przechowywać pełne frazy wyszukiwania?
Tylko wtedy, gdy istnieje konkretny cel i wdrożono filtrowanie danych osobowych. Bezpieczniej przechowywać kategorię zapytania, a pełne frazy analizować przez krótki czas w oddzielnym środowisku z ograniczonym dostępem.

Czy anonimizacja zwalnia z obowiązków RODO?
Dopiero skutecznie zanonimizowane informacje wypadają poza zakres przepisów o danych osobowych. Sam proces anonimizacji nadal jest operacją wykonywaną na danych osobowych i musi być odpowiednio zabezpieczony.

Pierwszym działaniem nie powinien być zakup nowego narzędzia analitycznego. Najpierw trzeba wyłączyć przesyłanie pełnych adresów IP, stałych identyfikatorów i surowych fraz do głównej tabeli statystycznej. Następnie należy ustawić automatyczne usuwanie logów oraz minimalny próg liczebności raportów. Dopiero po zamknięciu tych trzech źródeł ryzyka ma sens poprawianie wykresów, eksportów i paneli dla partnerów.