SPSS: czyszczenie danych ankietowych — logika odpowiedzi, progi, wykluczenia i dokumentacja

Cele i zasady czyszczenia danych ankietowych w SPSS

Czyszczenie danych ankietowych w SPSS to zestaw decyzji i działań, które mają doprowadzić surowy plik z odpowiedziami do postaci spójnej, analizowalnej i możliwie wiernej temu, co badani rzeczywiście chcieli zakomunikować. W praktyce chodzi o to, by ograniczyć wpływ przypadkowych błędów, nieuważnych odpowiedzi, błędów technicznych oraz niejednoznacznych kodowań na wyniki analiz.

Warto traktować czyszczenie danych jako osobny etap projektu: z jasno zapisanymi celami, kryteriami i sposobem dokumentowania. Dzięki temu wyniki są bardziej wiarygodne, a cały proces da się obronić metodologicznie.

Trzy nadrzędne cele: przejrzystość, powtarzalność, minimalizacja stronniczości

• Przejrzystość – każda zmiana w danych (rekodowanie, oznaczanie braków, filtrowanie przypadków) powinna mieć czytelne uzasadnienie i być łatwa do prześledzenia. W SPSS oznacza to m.in. pracę na jednoznacznie nazwanych zmiennych, spójnych etykietach oraz konsekwentne opisywanie przyjętych reguł.
• Powtarzalność – ten sam zestaw reguł powinien dawać ten sam rezultat niezależnie od tego, kto wykonuje czyszczenie i kiedy. Powtarzalność to fundament kontroli jakości i audytowalności: umożliwia replikację wyników oraz bezpieczne aktualizacje pliku (np. po dopłynięciu nowych odpowiedzi).
• Minimalizacja stronniczości – czyszczenie nie może „ustawiać” wyników pod oczekiwany efekt. Reguły powinny być definiowane w sposób możliwie obiektywny (najlepiej przed analizą wyników), a ich zastosowanie ma zmniejszać błąd pomiaru, a nie zmieniać strukturę próby w pożądanym kierunku.

Co obejmuje czyszczenie danych ankietowych (na poziomie ogólnym)

W ujęciu praktycznym czyszczenie w SPSS zwykle dotyczy kilku klas działań:

• Porządkowanie struktury danych: upewnienie się, że typy zmiennych, zakresy wartości, etykiety i jednostki są poprawne (np. skale liczbowe vs. kategorie, kody odpowiedzi, wartości specjalne).
• Ujednolicanie kodów: spójne traktowanie odpowiedzi typu „nie wiem”, „nie dotyczy”, odmowa odpowiedzi oraz pól pustych, tak aby analizy nie mieszały braków z realnymi wartościami.
• Weryfikacja zgodności z logiką kwestionariusza: sprawdzenie, czy odpowiedzi są możliwe w świetle filtrów, warunków i kolejności pytań (np. pytania zależne od wcześniejszego wyboru).
• Decyzje o wykluczeniach lub oznaczaniu obserwacji: identyfikacja przypadków, które mogą obniżać jakość (np. techniczne duplikaty, podejrzane rekordy) oraz określenie, czy są usuwane, czy tylko flagowane do analiz wrażliwości.

Kluczowe jest, by od początku rozróżniać działania porządkujące (np. korekta typów i kodów) od działań selekcyjnych (np. wykluczenia). Te drugie niemal zawsze mają większy wpływ na wnioski i wymagają szczególnie ostrożnych reguł oraz rzetelnej dokumentacji.

Zasady projektowania reguł czyszczenia

• Najpierw definicje, potem decyzje: zanim cokolwiek zmienisz w pliku, zdefiniuj, co w badaniu oznacza „poprawna odpowiedź”, „brak danych”, „rekord podejrzany” oraz „wykluczenie”.
• Reguły oparte na kwestionariuszu i metadanych: kryteria czyszczenia powinny wynikać z konstrukcji narzędzia (filtry, skale, dopuszczalne zakresy) oraz sposobu zbierania danych (tryb ankiety, logika platformy), a nie z samej treści wyników.
• Preferuj podejście zachowawcze: jeśli nie masz mocnych przesłanek, częściej lepiej jest oznaczyć obserwację flagą jakości niż ją usuwać. Pozwala to porównać wnioski „z” i „bez” przypadków wątpliwych.
• Minimalizuj liczbę wyjątków: im więcej ręcznych odstępstw, tym większe ryzyko niespójności. Dąż do reguł, które da się zastosować jednolicie w całym zbiorze.
• Rozdziel czyszczenie od analizy: czyszczenie powinno przygotować dane do analizy, ale nie zawierać interpretacji wyników. To pomaga utrzymać neutralność i ogranicza pokusę dostosowywania reguł do hipotez.

Przejrzystość w praktyce: co powinno być „widoczne” w pliku SPSS

Już na wczesnym etapie warto zadbać o to, aby plik po czyszczeniu był samowyjaśniający. Pomagają w tym:

• Spójne nazewnictwo zmiennych i wartości (tak, by było jasne, co jest oryginałem, a co wersją po recodowaniu).
• Etykiety zmiennych i wartości opisujące znaczenie kodów, zwłaszcza dla odpowiedzi specjalnych.
• Flagi jakości (zmienne wskaźnikowe) oddzielające informację „rekord spełnia/nie spełnia kryterium” od decyzji „rekord usuwamy/nie usuwamy”.
• Jednoznaczne kryteria zapisane w opisie projektu lub notatkach analitycznych, które można zestawić z tym, co widać w danych.

Powtarzalność: dlaczego jest krytyczna przy danych ankietowych

W ankietach często występują aktualizacje danych: dopływ nowych rekordów, korekty eksportu, zmiany w kwestionariuszu lub dodatkowe zmienne z platformy badawczej. Jeśli proces czyszczenia jest powtarzalny, można go zastosować ponownie bez ryzyka, że „ręczne poprawki” wprowadzą rozjazdy między wersjami pliku. Powtarzalność zwiększa też wiarygodność wyników, bo umożliwia niezależną weryfikację tego, jakie kroki doprowadziły do finalnego zbioru analitycznego.

Minimalizacja stronniczości: typowe ryzyka i jak im zapobiegać

Najczęstsze źródła stronniczości w czyszczeniu danych ankietowych nie wynikają ze złej woli, lecz z nieostrych reguł lub zbyt późnego podejmowania decyzji. Ryzyka, które warto kontrolować, to:

• Reguły ustalane po obejrzeniu wyników (np. dopasowywanie progów tak, by „lepiej wyglądało”). Remedium: ustal kryteria wcześniej i trzymaj się ich konsekwentnie.
• Asymetryczne traktowanie grup (np. częstsze wykluczanie określonych respondentów ze względu na styl odpowiedzi powiązany z cechami demograficznymi). Remedium: sprawdzaj, czy reguły nie zmieniają struktury próby w sposób niezamierzony.
• Mieszanie braków danych z realnymi odpowiedziami (np. kod „0” raz jako „brak”, raz jako „zero”). Remedium: jednoznacznie zdefiniuj i stosuj kody braków.
• Nadmierne „naprawianie” danych (np. zbyt agresywne korekty). Remedium: preferuj zachowanie oryginału oraz tworzenie wersji po czyszczeniu, zamiast nadpisywania.

Jeśli celem jest rzetelna analiza, czyszczenie powinno być postrzegane jako kontrolowany kompromis: usuwamy lub korygujemy tylko to, co ma jasne uzasadnienie metodologiczne, a wszelkie decyzje potencjalnie wpływające na wnioski opisujemy w sposób umożliwiający ocenę ich konsekwencji.

Dokumentacja jako część czyszczenia, a nie dodatek

W kontekście SPSS dokumentacja to nie tylko opis w raporcie. To również konsekwentne prowadzenie śladu decyzyjnego: jakie reguły przyjęto, które zmienne zostały zmienione, jakie rekordy oznaczono oraz dlaczego. Dobrze udokumentowane czyszczenie przyspiesza pracę zespołową, ułatwia interpretację wyników i zmniejsza ryzyko błędów w kolejnych iteracjach analizy.

2. Kontrole jakości odpowiedzi: spójność logiczna, attention checks i wykrywanie wzorców nierzetelnych odpowiedzi

Kontrola jakości odpowiedzi w SPSS ma jeden cel: odróżnić dane, które wiarygodnie reprezentują opinie respondentów, od zapisów przypadkowych, automatycznych lub nielogicznych. W praktyce obejmuje to trzy uzupełniające się obszary: spójność logiczną, attention checks oraz wykrywanie wzorców nierzetelnego wypełniania. Każdy z nich odpowiada na inne pytanie: czy odpowiedzi są wewnętrznie zgodne, czy respondent czytał pytania oraz czy sposób udzielania odpowiedzi wygląda na sensowny. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Spójność logiczna: zgodność odpowiedzi z „logiką kwestionariusza”

Spójność logiczna polega na weryfikacji, czy odpowiedzi nie przeczą sobie wzajemnie lub nie naruszają reguł wynikających z konstrukcji ankiety. To nie jest jeszcze ocena „prawdziwości” deklaracji, lecz sprawdzenie, czy zestaw odpowiedzi jest możliwy i zrozumiały w ramach przyjętych definicji.

• Reguły warunkowe (skip logic / filtrowanie): jeśli respondent zadeklarował, że nie korzysta z danej usługi, a później ocenia jej jakość, pojawia się niespójność wymagająca decyzji (np. korekta, oznaczenie jako brak, flaga do przeglądu).
• Zależności hierarchiczne: odpowiedzi w pytaniach szczegółowych powinny wynikać z odpowiedzi ogólnej (np. brak wskazań w pytaniu „które z poniższych” przy jednoczesnym podaniu liczby korzystanych opcji).
• Zakresy i ograniczenia skali: wartości poza dopuszczalnym zakresem, niemożliwe kombinacje (np. deklaracja wieku niezgodna z rokiem urodzenia, jeśli oba pola występują).
• Stałość definicji: to samo pojęcie mierzone w dwóch miejscach (np. „status zatrudnienia” i „forma pracy”) nie powinno prowadzić do sprzecznych klasyfikacji bez uzasadnienia.

W SPSS takie kontrole zwykle kończą się utworzeniem flag jakości (zmiennych pomocniczych), które nie zastępują danych, ale pozwalają je selekcjonować, porównywać i raportować. Ważne jest rozróżnienie między błędem logicznym a sytuacją, w której respondent mógł zinterpretować pytanie inaczej — wtedy lepsze jest oznaczenie przypadku do przeglądu niż automatyczne usuwanie.

Attention checks: czy respondent faktycznie czytał pytania

Attention checks to zaplanowane w kwestionariuszu elementy służące do wykrywania nieuwagi lub automatycznego klikania. W przeciwieństwie do spójności logicznej, która analizuje relacje między odpowiedziami „merytorycznymi”, attention checks wprost testują zachowanie respondenta podczas wypełniania.

• Pytania instrukcyjne: respondent otrzymuje jednoznaczną instrukcję wyboru konkretnej odpowiedzi. Niezastosowanie się do instrukcji jest silną przesłanką niskiej jakości danych.
• Pytania kontrolne o oczywistej odpowiedzi: stosowane ostrożnie, bo „oczywistość” bywa zależna od kontekstu kulturowego lub językowego; nadają się bardziej jako sygnał ostrzegawczy niż jedyne kryterium.
• Powtórzenia pozycji: ta sama treść (lub jej parafraza) pojawia się później; duża rozbieżność może wskazywać brak uwagi, ale może też wynikać ze zmiany perspektywy w trakcie ankiety.

Interpretując attention checks warto pamiętać, że pojedyncze potknięcie nie zawsze oznacza intencjonalną nierzetelność (np. błąd kliknięcia na urządzeniu mobilnym). Dlatego częstą praktyką jest traktowanie ich jako elementu łącznego oceny jakości, a nie jedynej podstawy do daleko idących decyzji.

Wzorce nierzetelnych odpowiedzi: szybkie heurystyki i sygnały ostrzegawcze

Trzeci filar to wykrywanie wzorców wskazujących na „mechaniczne” wypełnianie, losowe odpowiedzi albo zjawiska takie jak straightlining. To podejście różni się od dwóch poprzednich: zamiast sprawdzać konkretne reguły logiczne lub pojedyncze testy uwagi, analizuje kształt odpowiedzi w wielu pozycjach.

• Straightlining i brak zróżnicowania: wybieranie tej samej kategorii w długich bateriach pytań (np. same „3” lub same „zdecydowanie się zgadzam”). Może to oznaczać brak zaangażowania, ale czasem też realnie jednolite postawy — dlatego warto porównywać z długością baterii i treścią pozycji.
• Naprzemienne klikanie (patterns): schematy typu 1-5-1-5 w skali Likerta, sugerujące automatyzm.
• Losowość odpowiedzi: niespójne, chaotyczne zmiany odpowiedzi w bateriach, zwłaszcza gdy pozycje są podobne semantycznie.
• Sprzeczności „miękkie”: brak jawnego złamania logiki filtrów, ale zestaw odpowiedzi trudny do obrony (np. skrajne deklaracje w wielu obszarach bez żadnego zróżnicowania).
• Problemy w odpowiedziach otwartych jako sygnał jakości: puste, bezsensowne ciągi znaków, kopiowane frazy lub treści nie na temat mogą wspierać ocenę niskiej jakości, choć same w sobie nie przesądzają o wykluczeniu.

Najbezpieczniej traktować te wskaźniki jako flagi do dalszej weryfikacji, a nie automatyczny „wyrok”. W praktyce moc oceny rośnie, gdy kilka sygnałów występuje jednocześnie (np. niezaliczony attention check + straightlining + liczne niespójności).

Jak łączyć wyniki kontroli jakości w spójny obraz

Żeby kontrole jakości były użyteczne analitycznie, powinny prowadzić do czytelnych rezultatów: zestawu oznaczeń, które można wykorzystać do filtrowania przypadków, porównań oraz raportowania. Dobre praktyki obejmują:

• Rozdzielenie typów problemów: osobne flagi dla niespójności logicznych, attention checks i wzorców odpowiedzi — ułatwia to późniejsze decyzje i audyt.
• Stopniowanie pewności: rozróżnienie między „twardą” nieprawidłowością (np. złamanie reguły filtrów) a „miękkim” sygnałem (np. mała zmienność w baterii).
• Minimalizacja ryzyka stronniczości: kryteria powinny być neutralne względem badanych grup; np. wzorce odpowiedzi mogą zależeć od długości ankiety, urządzenia, zmęczenia czy poziomu kompetencji językowych.
• Konsekwencja w zastosowaniu: te same reguły dla całej próby i jasne uzasadnienie wyjątków.

Wyniki kontroli jakości powinny być zrozumiałe dla osób, które nie uczestniczyły w przygotowaniu analizy: co było sprawdzane, jakie przypadki oznaczono i dlaczego. Dzięki temu dalsze decyzje o traktowaniu danych są oparte na przejrzystych przesłankach, a nie na intuicji.

3. Braki danych i reguły postępowania: typy braków, kody missing, imputacja vs. wykluczenia i progi decyzyjne

Braki danych w ankietach są normą: wynikają z pominięć, filtrów (skip logic), odmów odpowiedzi lub błędów technicznych. W SPSS kluczowe jest rozróżnienie, jaki „rodzaj braku” reprezentuje puste pole, a następnie ustawienie spójnych reguł: kiedy brak zostaje jako brak, kiedy prowadzi do wykluczenia, a kiedy jest uzupełniany (imputacja). Najważniejsze zasady to: spójność kodów, jawna dokumentacja oraz minimalizacja stronniczości (np. nie „karanie” respondentów za braki, które wynikają z poprawnie działającej logiki ankiety).

3.1. Typy braków: co oznacza puste pole?

W praktyce warto odróżnić co najmniej cztery sytuacje. To rozróżnienie wpływa na to, czy obserwacja powinna być analizowana, wykluczana lub traktowana jako „nie dotyczy”.

3.2. System-missing vs. user-missing w SPSS

SPSS rozróżnia dwa główne mechanizmy braków:

• System-missing (zwykle widoczne jako kropka „.”): standardowy brak danych, np. puste pole po imporcie.
• User-missing: brak zdefiniowany przez badacza (np. kody 97/98/99 lub -1/-2), który SPSS ma traktować jak brak w analizach.

W danych ankietowych user-missing jest szczególnie przydatny, gdy chcesz rozróżniać znaczenia braków (np. „nie dotyczy” vs. „odmowa”), ale nadal wykluczać je z obliczeń statystycznych. Najczęstszy błąd to pozostawienie kodów typu 99 jako zwykłych wartości liczbowych — wtedy średnie, odchylenia czy korelacje będą zniekształcone.

3.3. Ustalanie i ujednolicanie kodów missing

Jeszcze przed analizą warto przyjąć konwencję kodowania (zwłaszcza gdy dane pochodzą z różnych fal/paneli lub kilku kwestionariuszy). Minimalny zestaw dobrych praktyk:

• Ustalić osobne kody dla: nie dotyczy, odmowa, nie wiem, brak techniczny (o ile te kategorie występują).
• Sprawdzić, czy kody nie kolidują ze skalą odpowiedzi (np. 0–10 vs. kod 0 jako brak).
• Przypisać kody jako user-missing w metadanych zmiennych.

Uzupełniająco (opcjonalnie) można zastosować składnię, aby hurtowo zadeklarować braki dla zestawu zmiennych:

MISSING VALUES q1 to q20 (97,98,99).
MISSING VALUES income (-1,-2).

3.4. Imputacja vs. wykluczenia: kiedy które podejście ma sens?

Decyzja o imputacji lub wykluczeniu zależy od: skali braków, typu zmiennej (wynikowa vs. kontrolna), mechanizmu braków oraz celu analizy. Na poziomie zasad (bez wchodzenia w szczegóły metod):

• Wykluczenia są najprostsze, ale mogą zmniejszać próbę i wprowadzać stronniczość, jeśli braki nie są losowe.
• Imputacja ma sens, gdy braki są umiarkowane, a zmienne są potrzebne do modeli/skal; wymaga jednak spójnych założeń i konsekwentnego raportowania.
• Braki strukturalne („nie dotyczy”) zwykle nie powinny być imputowane „na siłę” — często lepiej modelować je jako osobną sytuację (np. analizować tylko populację, której pytanie dotyczy).

3.5. Progi decyzyjne: jak ustalić reguły postępowania z brakami

Żeby decyzje nie były uznaniowe, ustala się progi (thresholds) dotyczące dopuszczalnej liczby braków. Dwa podstawowe poziomy decyzji:

• Per-zmienna (item-level): kiedy dana zmienna jest zbyt „dziurawa”, by ją analizować lub użyć w modelu.
• Per-respondent (case-level): kiedy respondent ma tak wiele braków, że jego rekord staje się mało użyteczny.

Progi warto dopasować do typu narzędzia:

• Skale/wielopozycyjne baterie: częściej stosuje się regułę minimalnej liczby odpowiedzi w obrębie skali (np. „co najmniej X z Y pozycji uzupełnionych”), a dopiero potem ewentualne uzupełnienie brakujących pozycji zgodnie z przyjętą procedurą.
• Zmienne kluczowe (np. metryczka lub główna zmienna wynikowa): częściej obowiązuje bardziej restrykcyjna zasada (np. brak = brak możliwości użycia w konkretnej analizie).

W SPSS praktycznie oznacza to również świadome użycie sposobu wykluczania w analizach: listwise (usuwa przypadek, jeśli brakuje czegokolwiek z zestawu) vs. pairwise (wykorzystuje maksimum danych dla każdej pary/obliczenia). Wybór metody wpływa na liczebności i porównywalność wyników między analizami, więc powinien wynikać z ustalonych reguł.

3.6. Dokumentowanie decyzji o brakach

Każda reguła dotycząca braków danych powinna być zapisana w sposób umożliwiający odtworzenie procesu. Minimalny zakres dokumentacji:

• Lista kodów missing i ich znaczeń (np. 97 = nie wiem, 98 = odmowa, 99 = brak techniczny, 96 = nie dotyczy).
• Informacja, które kody są user-missing, a które pozostają wartościami analitycznymi.
• Progi per-zmienna i per-respondent oraz to, czy stosujesz listwise czy pairwise w kluczowych analizach.
• Jeśli stosowana jest imputacja: które zmienne obejmuje i w jakich sytuacjach (na poziomie zasad, bez konieczności opisu algorytmu w tym miejscu).

4. Kryteria wykluczeń: progi, decyzje per-respondent/per-zmienna oraz wpływ na analizę

Kryteria wykluczeń to zestaw jawnych, z góry ustalonych reguł, które określają, kiedy odpowiedź (cały rekord respondenta) lub pojedyncza wartość w zmiennej powinna zostać usunięta z analizy albo oznaczona jako brak danych. Dobrze zdefiniowane wykluczenia pomagają ograniczyć wpływ danych niskiej jakości, ale jednocześnie mogą zwiększyć ryzyko stronniczości (np. gdy wykluczenia częściej dotyczą określonych grup). W SPSS kluczowe jest, by decyzje te były możliwe do odtworzenia (syntax) i łatwe do zraportowania. W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo konsekwencje progów wykluczeń widać bezpośrednio w liczebnościach i wnioskach.

Rodzaje progów wykluczeń

W praktyce progi dzieli się według tego, co mierzą i jaką decyzję wymuszają. Poniżej najczęstsze kategorie (bez wchodzenia w szczegółowe techniki wykrywania):

• Progi kompletności – np. minimalny odsetek udzielonych odpowiedzi w kluczowych blokach; zbyt wiele braków może oznaczać przerwanie ankiety lub niską użyteczność rekordu.
• Progi jakości odpowiedzi – np. niespełnienie zdefiniowanych warunków jakości (takich jak kryteria oparte o spójność lub sygnały nierzetelności). Ważne: sam próg to reguła decyzyjna, a nie metoda detekcji.
• Progi dotyczące wartości poza zakresem – np. wartości niemożliwe (błędy kodowania, błędy importu); zwykle skutkują korektą/rekodem do braków zamiast usunięcia całego rekordu.
• Progi specyficzne dla analizy – np. warunek włączenia do konkretnego modelu (subpopulacja, filtr merytoryczny); to często nie „wykluczenie z badania”, tylko ograniczenie analityczne.

Decyzje per-respondent vs. per-zmienna

Najważniejszym wyborem jest poziom, na którym stosujesz regułę:

Praktyczna zasada: jeśli kryterium mówi o globalnej wiarygodności respondenta, rozważ decyzję per-respondent; jeśli dotyczy lokalnej poprawności odpowiedzi, preferuj podejście per-zmienna.

Jak ustalać progi, żeby były obronne

• Predefiniuj progi w planie analizy lub protokole czyszczenia (zanim zobaczysz wyniki kluczowych testów).
• Oddziel kryteria „twarde” (np. wartości niemożliwe) od „miękkich” (np. podejrzenie niskiej jakości). Miękkie reguły częściej wymagają analizy wrażliwości.
• Utrzymuj symetrię: progi powinny działać tak samo dla wszystkich respondentów; wyjątki muszą być opisane i uzasadnione.
• Projektuj flagi, nie kasowanie: najpierw oznaczaj przypadki (zmienna flag), a dopiero potem stosuj filtry/analityczne wykluczenia.

Wpływ wykluczeń na analizę (co musisz sprawdzić)

Wykluczenia zmieniają nie tylko liczebność, ale i interpretację wyników. Minimum kontroli po zastosowaniu reguł to:

• Zmiana N ogółem oraz per-zmienna (czy analizy będą miały porównywalne podstawy).
• Różnice w składzie próby przed vs. po (np. rozkłady demografii, kluczowe segmenty). Jeśli wykluczenia nie są losowe, mogą zniekształcić wnioski.
• Stabilność wyników: czy wnioski utrzymują się przy alternatywnych, rozsądnych progach (analiza wrażliwości).
• Porównywalność wskaźników: jeśli różne modele mają różne kryteria włączenia, porównania „model do modelu” mogą być mylące.

Operacjonalizacja w SPSS: flagi i filtr zamiast trwałego usuwania

W SPSS warto tworzyć zmienną/zmienne flagujące i używać ich do filtrowania przypadków w analizach. To pozwala łatwo raportować, ile obserwacji odpadło i dlaczego, oraz wrócić do surowej wersji danych.

* Przykład: flaga wykluczenia (0 = OK, 1 = wyklucz) i praca na filtrze.
COMPUTE excl_any = 0.
IF (miss_share > 0.30) excl_any = 1.
IF (failed_quality = 1) excl_any = 1.
EXECUTE.

* Analizy tylko na przypadkach niewykluczonych.
FILTER OFF.
USE ALL.
SELECT IF (excl_any = 0).
EXECUTE.

W raportowaniu trzymaj rozdział: kryterium → liczba oznaczonych przypadków → decyzja (per-respondent/per-zmienna) → efekt na N. Taki format ułatwia obronę procesu czyszczenia i interpretację wyników.

5. Duplikaty i podejrzenia wielokrotnego udziału: identyfikacja, rozstrzyganie i konsekwencje

Duplikaty w danych ankietowych to sytuacje, w których ta sama osoba (lub to samo urządzenie/konto) wypełnia ankietę więcej niż raz albo gdy w zbiorze pojawiają się powielone rekordy w wyniku błędu eksportu, łączenia plików lub importu. W SPSS kluczowe jest odróżnienie: (1) duplikatu technicznego (zwykle identyczne wiersze), (2) wielokrotnego udziału (rekordy podobne, ale niekoniecznie identyczne) oraz (3) legitymowanych powtórzeń (np. pomiar falowy, panel, retest), które nie powinny być usuwane, tylko poprawnie oznaczone.

5.1. Po co wykrywać duplikaty (i czego unikać)

• Zawyżenie liczebności próby i sztuczne „wzmocnienie” określonych odpowiedzi (bias).
• Zaniżenie błędów standardowych i fałszywe wnioski o istotności (ten sam respondent liczy się wielokrotnie).
• Problemy z ważeniem i segmentacją (jeden przypadek może trafić do wielu grup).
• Ryzyko naruszeń procedury badawczej (np. incentywy, limity udziału).

Jednocześnie należy unikać pochopnego usuwania na podstawie pojedynczego sygnału (np. wspólnego IP lub tego samego czasu wypełniania), bo może to eliminować poprawne odpowiedzi z tej samej sieci (szkoła, firma, akademik).

5.2. Źródła duplikatów: techniczne vs. behawioralne

5.3. Identyfikacja duplikatów w SPSS: co porównywać

W praktyce stosuje się hierarchię identyfikatorów (od najbardziej wiarygodnych do najsłabszych):

• Unikalny identyfikator respondenta (ID z systemu ankietowego, panelu, token linku) — najlepsza podstawa do wykrywania wielokrotnego udziału.
• Metadane techniczne (np. IP, user agent, identyfikator urządzenia, e-mail/telefon jeśli zgodne z RODO i projektem) — przydatne, ale obarczone błędem współdzielenia.
• Znaczniki czasu (start/koniec, data wypełnienia) — pomocnicze, szczególnie przy „zrzutach” duplikatów w krótkim oknie czasowym.
• „Odcisk” odpowiedzi (hash/skrót z kluczowych pytań, wzorce odpowiedzi) — użyteczne, gdy brak ID; wymaga ostrożności, bo podobne odpowiedzi nie muszą oznaczać tego samego respondenta.

W SPSS najczęściej zaczyna się od wykrycia powtórzeń na kluczu (np. respondent_id), a dopiero potem buduje się warstwę sygnałów pomocniczych do oceny przypadków „podejrzanych”.

5.4. Podstawowe narzędzia SPSS do wykrywania powtórzeń

• Sort Cases + Identify Duplicate Cases — szybkie oznaczanie duplikatów na podstawie wybranych zmiennych klucza.
• Aggregate — zliczanie liczby rekordów per klucz i tworzenie wskaźników (np. liczba wystąpień ID).
• Compare Datasets — gdy duplikaty wynikają z łączenia plików lub kolejnych eksportów.

Poniżej przykładowy minimalny szkic w składni SPSS (jako uzupełnienie), który tworzy licznik wystąpień identyfikatora:

AGGREGATE
  /OUTFILE=* MODE=ADDVARIABLES
  /BREAK=respondent_id
  /n_id = N.

COMPUTE suspected_duplicate = (n_id > 1).
EXECUTE.

5.5. Rozstrzyganie: zostawić, scalić czy wykluczyć?

Decyzja powinna być spójna i audytowalna. Najczęstsze podejścia (bez wchodzenia w detale progów i jakości odpowiedzi):

• Duplikaty techniczne: zwykle usuwa się kopie, pozostawiając jeden rekord (np. pierwszy lub ostatni) zgodnie z ustaloną regułą.
• Wielokrotny udział: często wybiera się jeden rekord per osoba (np. najpełniejszy lub najpóźniejszy), a pozostałe oznacza i wyklucza z analiz przekrojowych.
• Częściowo uzupełnione rekordy: czasem zamiast usuwać rozważa się scalenie informacji, ale tylko jeśli projekt badania i struktura danych to umożliwiają, a procedura jest jednoznaczna.
• Niepewne przypadki: zamiast arbitralnego usuwania warto dodać flagę „suspected” i przygotować analizy porównawcze (wyniki z i bez tych rekordów).

5.6. Konsekwencje dla analizy i raportowania

• Zmiana N: raportuj liczbę rekordów przed/po deduplikacji oraz liczbę przypadków oznaczonych jako podejrzane.
• Wpływ na estymacje: duplikaty mogą przesuwać średnie i rozkłady; w szczególności, gdy wielokrotny udział nie jest losowy (np. dotyczy tylko jednej grupy).
• Wpływ na wariancję: obecność wielokrotnych udziałów może sztucznie zwiększać „pewność” wyników.
• Replikowalność: jeśli deduplikacja jest niejawna (ręczna), trudno odtworzyć wyniki; dlatego decyzje powinny opierać się na zapisanych regułach i zmiennych flagujących.

5.7. Minimalna dokumentacja, którą warto prowadzić

• Definicja klucza: na jakich zmiennych wykrywano duplikaty (ID, metadane, kombinacje).
• Reguła wyboru rekordu: np. „zostaw rekord o największej kompletności” lub „zostaw najpóźniejszy komplet”.
• Zmienne kontrolne: flagi typu suspected_duplicate, licznik wystąpień, kategoria decyzji (zostaw/wyklucz/niepewne).
• Podsumowanie liczbowe: ile przypadków dotyczyło duplikacji technicznej vs. podejrzeń wielokrotnego udziału.

6. Czas wypełniania i jakość: wykrywanie zbyt szybkich odpowiedzi, outliery czasu i reguły odcięcia

Czas wypełniania ankiety to jedna z najprostszych, a zarazem najbardziej użytecznych przesłanek jakości danych. Nie jest „dowodem” nierzetelności sam w sobie, ale pomaga wychwycić przypadki skrajne: osoby, które przeszły kwestionariusz nienaturalnie szybko (tzw. speeders) lub wyjątkowo długo (np. przerwy, rozproszenie, problemy techniczne). W SPSS warto potraktować czas jako zmienną kontrolną, na podstawie której buduje się reguły odcięcia i decyzje o wykluczeniu lub oznaczeniu obserwacji do dalszej weryfikacji.

6.1. Co mierzyć: całkowity czas vs. czasy sekcji/stron

• Czas całkowity (end-start) – najszybszy do wdrożenia; dobry do wykrywania skrajnie krótkich wypełnień oraz bardzo długich sesji.
• Czasy etapów (strony/bloki/sekcje) – lepsze do rozróżniania „szybkiego klikania” od realnego czytania oraz do identyfikacji fragmentów kwestionariusza, które generują podejrzane zachowania (np. matryce).

Jeśli masz tylko czas całkowity, nadal można sensownie pracować: kluczowe jest, by reguły były jasne, powtarzalne i udokumentowane.

6.2. Najczęstsze problemy interpretacyjne

• Długość ankiety i urządzenie: ten sam kwestionariusz bywa wypełniany szybciej na desktopie niż na telefonie (lub odwrotnie), a różnice mogą zależeć od typu pytań.
• Przerwy w trakcie: długie czasy często oznaczają porzucenie i powrót, niekoniecznie „dokładność”.
• Filtry/ścieżki: respondenci mogą widzieć różną liczbę pytań. Porównywanie „surowego” czasu między ścieżkami bywa mylące.
• Język i kompetencje: tempo czytania różni się między osobami; zbyt agresywny próg może wprowadzać stronniczość.

6.3. Wykrywanie zbyt szybkich odpowiedzi (speeders)

„Zbyt szybko” warto definiować operacyjnie i konsekwentnie. W praktyce stosuje się trzy podejścia, które można łączyć:

• Próg absolutny: np. mniej niż X sekund/minut dla całej ankiety lub kluczowych bloków (szczególnie, gdy długość jest stała).
• Próg względny oparty o rozkład: np. dolny percentyl czasu (1%, 5%) lub odchylenie standardowe po transformacji (często logarytmicznej).
• Tempo na jednostkę treści: np. czas na pytanie/ekran (jeśli dostępne), co lepiej uwzględnia różne ścieżki.

W SPSS pomocne jest tworzenie flagi jakości, np. speed_flag, zamiast natychmiastowego usuwania danych. Pozwala to porównać wyniki analizy z i bez tych przypadków.

6.4. Outliery czasu: skrajnie długie wypełnienia

Bardzo długi czas częściej oznacza przerwę niż lepszą jakość. Typowe strategie:

• Oznaczenie do przeglądu: ekstremalnie długie czasy trafiają do ręcznej kontroli lub dodatkowych testów jakości.
• Winsoryzacja czasu (przy analizach metrycznych): obcięcie wartości czasu do górnego percentyla, jeśli czas jest tylko zmienną pomocniczą (a nie kryterium wykluczeń).
• Wykluczenie: gdy długi czas współwystępuje z innymi sygnałami problemów (np. niespójności, „straightlining”).

6.5. Ustalanie reguł odcięcia: rekomendowana logika decyzyjna

Reguły odcięcia powinny minimalizować ryzyko arbitralności. Dobrą praktyką jest oparcie decyzji o kilka przesłanek: czas + dodatkowy wskaźnik jakości (np. błędy logiczne, wzorce odpowiedzi). Sam czas traktuj jako screening, nie jako jedyne kryterium.

6.6. Operacjonalizacja w SPSS: proste flagi i przegląd rozkładu

W SPSS zwykle zaczyna się od obejrzenia rozkładu czasu, a potem buduje się zmienną flagującą. Poniżej przykładowy, minimalistyczny schemat (zakłada zmienną duration_sec):

* Podstawowy przegląd rozkładu czasu.
FREQUENCIES VARIABLES=duration_sec
  /STATISTICS=MEAN MEDIAN MINIMUM MAXIMUM.

EXAMINE VARIABLES=duration_sec
  /PLOT=BOXPLOT HISTOGRAM
  /STATISTICS=DESCRIPTIVES.

* Przykładowa flaga: bardzo krótki czas (próg absolutny).
COMPUTE speed_flag = (duration_sec < 180).
VARIABLE LABELS speed_flag 'Flaga: czas wypełniania poniżej 180 s'.
VALUE LABELS speed_flag 0 'nie' 1 'tak'.
EXECUTE.

Jeśli pracujesz na percentylach, praktyczne jest wyznaczenie progu na podstawie rozkładu (np. wstępnie w osobnym kroku) i zapisanie go w dokumentacji wraz z datą oraz wersją pliku.

6.7. Dokumentowanie decyzji i wpływ na wyniki

• Zapisz reguły: definicja progu (sekundy/minuty, percentyl, transformacja), zmienna czasu, sposób liczenia (całość vs. sekcje).
• Zachowaj flagi: zamiast usuwać obserwacje bez śladu, trzymaj zmienne typu speed_flag, longtime_flag.
• Raportuj liczności: ilu respondentów oznaczono/wykluczono i z jakiego powodu.
• Sprawdź wrażliwość: porównaj kluczowe wyniki z i bez przypadków odciętych czasem, aby ocenić stabilność wniosków.

Takie podejście pozwala użyć czasu wypełniania jako użytecznego filtra jakości, a jednocześnie ograniczyć ryzyko nadmiernych, stronniczych wykluczeń.

7. Kodowanie odpowiedzi otwartych „Inne, jakie?”: standaryzacja, słowniki kodów, kontrola jakości kodowania

Pola „Inne, jakie?” łączą zalety pytania zamkniętego (porównywalność kategorii) z ryzykiem chaosu tekstowego: literówek, synonimów, wieloznaczności i odpowiedzi nie na temat. Celem kodowania w SPSS jest zamiana swobodnego tekstu na spójne, policzalne kategorie bez utraty sensu oraz z zachowaniem przejrzystości decyzji. W praktyce oznacza to ustalenie zasad mapowania odpowiedzi na kody, utrzymanie jednolitych etykiet oraz udokumentowanie wyjątków.

Standaryzacja odpowiedzi przed kodowaniem

Zanim przypiszesz kody, warto uporządkować treść, aby minimalizować sztuczne „różnice” między odpowiedziami. Standaryzacja nie powinna zmieniać znaczenia wypowiedzi, tylko jej zapis.

• Normalizacja zapisu: ujednolicenie wielkości liter, usunięcie nadmiarowych spacji, konsekwentne traktowanie znaków diakrytycznych, rozwinięcie oczywistych skrótów, jeśli są jednoznaczne.
• Redukcja wariantów: łączenie prostych wariantów tej samej treści (np. różne formy fleksyjne) w jedną postać roboczą.
• Separacja informacji: gdy respondent wpisuje kilka elementów naraz, ustal, czy kodujesz odpowiedź jako wielokrotną (kilka kodów) czy wybierasz dominujący wątek. Najważniejsze jest konsekwentne stosowanie jednej reguły.

Słownik kodów (codebook) dla „Inne”

Słownik kodów to centralny punkt kontroli jakości: definiuje kategorie, ich znaczenie i granice. Powinien umożliwiać innym osobom identyczne zakodowanie tych samych wypowiedzi.

• Definicje kategorii: krótki opis tego, co wchodzi do kategorii, a co nie (kryteria włączenia i wyłączenia).
• Hierarchia i poziomy szczegółowości: decyzja, czy kody mają być szerokie (łatwiejsze porównania, mniejsze ryzyko rozdrobnienia) czy szczegółowe (więcej informacji, większe ryzyko małych liczebności). Warto dopasować poziom do planowanej analizy.
• Zasady dla odpowiedzi niejednoznacznych: np. kiedy stosować kod „nie da się zakodować”, „zbyt ogólne”, „brak treści”, „odpowiedź poza zakresem pytania”.
• Kody techniczne a merytoryczne: oddziel kategorie tematyczne od kodów porządkowych typu „puste”, „nieczytelne”, „żart/obraźliwe”, aby później nie mieszać jakości danych z treścią.
• Spójne etykiety: etykiety kategorii powinny być krótkie, jednoznaczne i stabilne w czasie; zmiany nazw bez zmian znaczenia łatwo wprowadzają zamieszanie w raportowaniu.

Jak kodować w SPSS bez utraty informacji

Najbezpieczniejsze jest zachowanie oryginalnego tekstu i dodanie obok zmiennych zakodowanych. Dzięki temu możesz wrócić do źródła przy wątpliwościach, audycie lub rozszerzeniu słownika.

• Oddzielenie surowych danych od kodów: tekst pozostaje niezmieniony, a kody trafiają do nowych zmiennych.
• Obsługa wielokrotności: jeśli dopuszczasz kilka kodów dla jednej odpowiedzi, zadbaj o spójny sposób zapisu (np. kilka zmiennych kodów albo zestaw wskaźników). Wybór powinien wynikać z tego, jak później będziesz liczyć częstości i zależności.
• Uważność na rzadkie kategorie: jeśli pewne kody pojawiają się bardzo rzadko, rozważ regułę łączenia ich do kategorii „pozostałe” — ale tylko wtedy, gdy nie zniekształca to kluczowych wniosków.

Kontrola jakości kodowania

Kodowanie jest podatne na subiektywność, dlatego potrzebuje prostych mechanizmów kontroli, które ograniczają przypadkowe i systematyczne błędy.

• Podwójne kodowanie próbki: dwie osoby kodują tę samą część odpowiedzi, a rozbieżności służą doprecyzowaniu definicji kategorii.
• Przegląd przypadków granicznych: szczególnie krótkie, wieloznaczne i „wielowątkowe” wpisy warto oznaczać do wspólnej decyzji zgodnej z zasadami słownika.
• Kontrola spójności w czasie: gdy słownik ewoluuje, sprawdzaj, czy wcześniejsze odpowiedzi nie wymagają rekodowania według nowych definicji, aby utrzymać porównywalność.
• Audyt częstości i wykrywanie anomalii: nagłe „wyskoki” liczebności kategorii, nietypowo dużo kodów technicznych lub bardzo wysoki udział „pozostałe” mogą sygnalizować problem w instrukcji pytania albo w samym kodowaniu.
• Rozdzielenie jakości od treści: odpowiedzi bez treści, obraźliwe lub automatyczne powinny być klasyfikowane konsekwentnie jako kody jakości, a nie jako kategorie merytoryczne.

Dokumentacja decyzji koderskich

Bez dokumentacji kodowanie staje się niepowtarzalne. Dobra praktyka to zapisywanie nie tylko „co zakodowano”, ale też „dlaczego”.

• Wersjonowanie słownika: każda zmiana definicji kategorii lub reguł powinna mieć odnotowaną datę i opis wpływu.
• Lista wyjątków: krótkie uzasadnienia dla nietypowych decyzji (np. przypisanie do kategorii mimo niepełnego opisu) ułatwiają późniejszą kontrolę.
• Reguły łączenia i rozbijania kategorii: jeśli kategorie były scalane lub dzielone, opisz kryteria oraz zachowaj możliwość odtworzenia poprzedniego stanu.

Dobrze zakodowane „Inne, jakie?” zwiększa wartość ankiety: pozwala zachować głos respondenta, a jednocześnie daje dane gotowe do analiz ilościowych. Kluczem jest konsekwencja: jednolite reguły, stabilny słownik kodów oraz kontrola jakości, która minimalizuje dowolność interpretacji.

8. Dokumentowanie procesu: SPSS Syntax, log zmian, raport czyszczenia, polityka czyszczenia oraz checklista/audyt

Dokumentacja czyszczenia danych ankietowych w SPSS jest równie ważna jak same decyzje o wykluczeniach, progach czy kodowaniu. Dobrze udokumentowany proces zwiększa przejrzystość (wiadomo, co i dlaczego zrobiono), powtarzalność (da się odtworzyć identyczny wynik) oraz ogranicza ryzyko stronniczości (decyzje są z góry opisane i spójnie stosowane). W praktyce dokumentacja powinna pozwolić niezależnej osobie odpowiedzieć na pytania: jakie reguły zastosowano, kiedy, na jakich zmiennych, z jakim skutkiem i jakie dane weszły do finalnych analiz.

SPSS Syntax jako „źródło prawdy” procesu

Najbardziej odporną na błędy formą dokumentowania w SPSS jest praca w oparciu o Syntax (a nie wyłącznie klikanie w menu). Syntax pełni podwójną rolę: jest instrukcją wykonawczą oraz zapisem tego, co faktycznie zrobiono. W dokumentowaniu chodzi nie o rozbudowane komentarze, lecz o jednoznaczne pokazanie kolejności kroków, nazewnictwa wersji danych oraz miejsc, w których podejmowane są decyzje (np. ustawienie braków, tworzenie flag jakości, wybór podzbioru do analizy). Dobrą praktyką jest konsekwentne opisywanie w komentarzach dlaczego dany krok jest potrzebny, a nie tylko co robi.

Log zmian: kiedy, co się zmieniło i dlaczego

Oprócz Syntax przydatny jest log zmian (changelog) – zwięzły rejestr kolejnych modyfikacji danych i reguł. Ma on znaczenie zwłaszcza wtedy, gdy proces czyszczenia jest iteracyjny, angażuje więcej niż jedną osobę lub gdy pojawiają się korekty po wstępnych analizach. Log zmian powinien utrwalać m.in. datę aktualizacji, zakres zmiany (np. doprecyzowanie kryterium, korekta kodu braków), powód oraz wpływ na liczebności (ile rekordów/odpowiedzi obejmuje zmiana). Taki rejestr pomaga uniknąć „cichego” przesuwania progów i ułatwia wyjaśnienie rozbieżności między wersjami wyników.

Raport czyszczenia: co weszło do analiz

Raport czyszczenia to dokument końcowy (lub cykliczny), który tłumaczy, jak z surowego eksportu ankiety powstał zbiór analityczny. Jego rolą jest podsumowanie reguł i ich konsekwencji, bez wchodzenia w techniczne detale implementacji. Raport powinien jasno oddzielać: decyzje planowane (z góry przyjęte) od decyzji reaktywnych (podjętych po zobaczeniu problemu w danych), a także wskazywać, które zmienne lub które grupy respondentów były objęte kontrolami jakości. W raporcie warto także opisać przyjęte definicje „danych finalnych” (np. czy analizy opierają się na wersji po wszystkich wykluczeniach, czy na kilku wariantach do analiz wrażliwości) oraz zasady nadawania wersji plików.

Przykładowa polityka czyszczenia: reguły z góry i zasada spójności

Polityka czyszczenia to krótki, możliwie stały dokument organizujący decyzje: jakie typy kontroli jakości są dopuszczalne, kiedy stosuje się wykluczenia, jak traktuje się braki danych oraz jak rozstrzyga się przypadki graniczne. W kontekście minimalizacji stronniczości kluczowe jest, aby polityka:

• uprzedzała o kryteriach (co najmniej na poziomie kategorii decyzji),
• narzucała hierarchię decyzji (co ma pierwszeństwo, gdy reguły się „zderzają”),
• wymagała spójnego stosowania tych samych reguł w obrębie projektu,
• określała, kiedy potrzebna jest uzasadniona eskalacja (np. odstępstwo od reguły) i jak ją dokumentować.

Polityka nie musi zawierać szczegółowych progów w każdym projekcie, ale powinna określać, w jakiej formie progi są ustalane, zatwierdzane i zapisywane, aby nie były zmieniane ad hoc.

Checklista i audyt: kontrola kompletności i ryzyk

Checklista to narzędzie, które zapewnia, że dokumentacja i proces czyszczenia są kompletne, a kluczowe ryzyka zostały przejrzane. Jej celem nie jest dublowanie kroków analitycznych, tylko dopilnowanie standardu: czy jest ślad decyzyjny, czy istnieje wersjonowanie, czy da się odtworzyć zbiór finalny, czy zachowano rozdział między danymi surowymi i przetworzonymi. Z kolei audyt to okresowa weryfikacja (np. przez inną osobę lub po czasie), czy proces rzeczywiście jest odtwarzalny i czy decyzje były stosowane konsekwentnie. Audyt może wykryć typowe problemy: brak jednoznacznego wskazania wersji danych, niespójne nazwy zmiennych po recodingu, niedokumentowane poprawki „ręczne”, niejasne kryteria rozstrzygania przypadków granicznych lub brak śladu tego, co zostało wykluczone.

Minimum dokumentacyjne, które warto utrwalić

Aby dokumentacja była użyteczna i proporcjonalna do skali projektu, zwykle wystarczy zestaw kilku elementów utrzymanych w porządku:

• Surowy plik danych zapisany w stanie nienaruszonym oraz jasno oznaczony jako „raw”.
• Plik/plik(i) Syntax prowadzące od danych surowych do danych analitycznych.
• Log zmian opisujący kolejne modyfikacje reguł i ich skutki.
• Raport czyszczenia streszczający reguły, ich zakres oraz wpływ na próbę.
• Definicje zmiennych (etykiety, wartości, kody braków) w wersji finalnej, tak aby interpretacja wyników była jednoznaczna.
• Ślad wykluczeń/flag jakości w danych (np. zmienne pomocnicze), pozwalający zrozumieć, dlaczego dany rekord jest poza analizą.

Tak zorganizowana dokumentacja sprawia, że czyszczenie danych w SPSS staje się procesem kontrolowanym: decyzje są sprawdzalne, wyniki dają się odtworzyć, a ryzyko przypadkowego „dopasowania” kryteriów do oczekiwanych rezultatów jest mniejsze.

Na zakończenie – w Cognity wierzymy, że wiedza najlepiej działa wtedy, gdy jest osadzona w codziennej pracy. Dlatego szkolimy praktycznie.

LLM dla analityków: jak robić „data Q&A” z kontrolą definicji KPI i słownika metryk 25 kwietnia 2026

Ewaluacja multimodalna: jak testować modele, które czytają obrazy, wykresy i skany umów 23 kwietnia 2026