Treść wpisu

Jak przygotować arkusz, żeby dało się go policzyć

Zanim jakikolwiek test statystyczny policzy cokolwiek, dane muszą mieć układ, który program rozumie. Większość opóźnień, które widzimy na etapie sprawdzania arkusza, nie wynika z trudnego badania, tylko z tego, że sam plik ma układ zrobiony pod czytanie przez człowieka, nie pod obliczenie przez program.

Układ arkusza, najczęstszy błąd: pytania w wierszach

Reguła jest jedna: jeden wiersz to jedna osoba badana, jedna kolumna to jedna zmienna. Ten układ nazywa się szerokim i to jedyny, który przyjmują SPSS, jamovi i JASP bez przeróbki.

Najczęstszy błąd wygląda inaczej: każde pytanie kwestionariusza w osobnym wierszu, a każda osoba badana w osobnej kolumnie, bo tak wygodniej się to czyta przy wpisywaniu ręcznym. Program statystyczny nie policzy z takiego arkusza nic, dopóki ktoś go nie obróci. Drugi wariant tego samego błędu to układ długi bez wyraźnego identyfikatora osoby: jedna osoba zajmuje kilka wierszy (na przykład jeden wiersz na każdy pomiar), a bez kolumny z numerem osoby program nie wie, które wiersze do siebie należą.

Kodowanie braków, dlaczego puste to nie to samo co zero

Pusta komórka i wpisane zero to dwie różne informacje, i pomylenie ich zmienia wynik, nie tylko wygląd arkusza. Pusta komórka mówi „nie wiadomo, jaka jest odpowiedź tej osoby na to pytanie”. Zero mówi „ta osoba odpowiedziała zero”, co jest konkretną, ważną odpowiedzią, na przykład zero epizodów bólu w tygodniu.

Programy statystyczne domyślnie traktują pustą komórkę jako brak danych i wyłączają ją z obliczeń dla tej zmiennej. Jeśli ktoś wpisze zero zamiast zostawić puste pole tam, gdzie osoba nie odpowiedziała, program policzy tę osobę tak, jakby faktycznie odpowiedziała zero, co przy skali punktowej zaniża średnią całej grupy. Odwrotny błąd, zostawienie pustego pola tam, gdzie odpowiedzią naprawdę było zero, wyrzuca z analizy osoby, które powinny w niej zostać.

Pozycje odwrócone i skąd wiadomo, że są

Część kwestionariuszy zawiera pozycje sformułowane przecząco względem reszty skali, na przykład skala satysfakcji, w której większość pytań brzmi „jestem zadowolona z…”, a jedno „czuję się sfrustrowana…”. Wysoki wynik na tym jednym pytaniu oznacza niską satysfakcję, odwrotnie niż na pozostałych.

Klucz kwestionariusza, czyli instrukcja jego autorów, zawsze wskazuje, które pozycje trzeba odwrócić przed zsumowaniem wyniku ogólnego. Sygnał ostrzegawczy bez zaglądania do klucza: alfa Cronbacha wychodzi rażąco niska albo nawet ujemna, mimo że pytania wydają się dotyczyć tego samego zjawiska. To najczęściej znaczy, że ktoś zapomniał odwrócić pozycję przed policzeniem wyniku sumarycznego, nie że skala jest wadliwa.

Etykiety zmiennych, nazwy kolumn, polskie znaki

Nazwa kolumny w arkuszu i etykieta zmiennej w programie statystycznym to dwie różne rzeczy, i obie mają znaczenie. Nazwa kolumny musi być krótka i bez polskich znaków diakrytycznych, bo część programów i formatów eksportu wciąż psuje ą, ę, ć, ż przy zapisie albo imporcie. Etykieta zmiennej, czyli pełny opis, jaki widać potem w tabelach wynikowych, może i powinna być napisana pełnym zdaniem po polsku, bo to ona trafia do raportu.

Dobra praktyka: nazwa kolumny w rodzaju stres_p3, etykieta zmiennej „Pozycja 3 skali stresu: Czułam się zdenerwowana z powodu czegoś, co wydarzyło się niespodziewanie”. Bez tego rozróżnienia arkusz z pięćdziesięcioma pytaniami zamienia się w zestaw kolumn, których nikt po fakcie nie potrafi rozszyfrować.

Eksport z Formularzy Google, pięć pułapek

Formularze Google eksportują dane wygodnie do arkusza, ale sam eksport ma kilka miejsc, w których dane wychodzą inaczej, niż wygląda formularz.

Pierwsza pułapka: pytania typu „zaznacz wszystkie pasujące” eksportują się jako jedna kolumna z odpowiedziami rozdzielonymi przecinkami, nie jako osobne zmienne 0/1 dla każdej opcji. Trzeba je rozdzielić ręcznie przed analizą, inaczej program potraktuje całą listę jako jeden nierozpoznawalny tekst.

Druga: jeśli różne osoby zaznaczyły różną liczbę opcji w tym samym pytaniu wielokrotnego wyboru, kolumny po rozdzieleniu przecinkami nie będą się zgadzać między wierszami.

Trzecia: separator dziesiętny. Arkusz Google zapisany i otwarty w polskim ustawieniu regionalnym może zamienić kropkę dziesiętną na przecinek albo odwrotnie przy eksporcie do CSV, w zależności od ustawień języka konta. Warto sprawdzić dwie, trzy wartości po eksporcie, zanim zaimportuje się cały plik.

Czwarta: znaczniki czasu. Formularz domyślnie dodaje kolumnę z datą i godziną wypełnienia, która trafia do analizy jako zmienna, jeśli ktoś jej nie usunie, i potrafi zepsuć automatyczne rozpoznawanie typu kolumn przy imporcie.

Piąta: pytania warunkowe, czyli te pokazywane tylko części osób w zależności od wcześniejszej odpowiedzi. Osoby, które nie widziały pytania, mają w eksporcie puste pole, identyczne wizualnie z polem osoby, która pytanie widziała i nie odpowiedziała. Te dwa przypadki wymagają osobnego kodu braku danych, inaczej analiza policzy ich razem.

Zanim wyślesz dane do analizy

Te same pięć spraw da się sprawdzić samodzielnie w dziesięć minut: układ szeroki, spójne kodowanie braków, odwrócone pozycje zgodne z kluczem, czytelne nazwy kolumn, oczyszczony eksport z formularza. Jeśli po tym sprawdzeniu nadal nie masz pewności, czy arkusz jest gotowy do analizy, prościej zapytać przed wysłaniem danych niż poprawiać już policzony wynik.