Bitte helfen Sie uns, Ihnen zu helfen und füllen Sie folgende Felder aus:
Ihre LimeSurvey-Version: Version 5.6.65
Eigener Server oder LimeSurvey-Cloud: LimeSurvey Cloud (Expert Abo)
Genutzte Designvorlage: Fruity Theme
==================
Hallo zusammen,

bei unserer zuletzt durchgeführten Umfrage wurden die gegebenen Antworten nicht richtig abgespeichert. Über zusätzliche Attribute haben wir in der Teilnehmerübersicht kodiert, wer welche Fragegruppen sehen soll. Das fuktioniert einwandfrei: jeder TN sieht genau die Fragegruppen, die er sehen soll. Allerdings sind die gegebenen Antworten dann nicht unter der entsprechenden Fragengruppe zu finden, sondern zufällig unter einer anderen Fragegruppe.

Beispiel: Eine Person soll Fragen aus der Fragegruppe "Obst" und aus der Fragegruppe "Gemüse" beantworten. Die richtigen Fragen werden angezeigt und die Person beantwortet sie. Schaunt man anschließend in die Ergebnisse tauchen die Antworten z.B. unter den Fragegruppen "Brot" und "Nüsse" auf. Wiederholt man den Vorgang, tauchen die Antworten wieder unter anderen Fragengruppe (z.B. "Getreide" und "Gewürze")

Es scheint dabei keine sytematische "Verschiebung" der Antworten zu geben und wir können uns nicht erklären, wie es zu dieser falschen Speicherung der Antworten kommt.

- Hat jemand eine Idee, wie bzw. wieso das passiert sein könnte?
- Gibt es eine Möglichkeit, die richtig zugeordneten Antworten noch zu erhalten?

Über Ideen und Hinweise würden wir und sehr freuen. Vielen Dank schonmal.

Liebe Grüße
Annika und Max

Man soll ja nie "unmöglich" sagen. Aber ich sage es jetzt mal. Das hört sich für mich technisch nicht möglich an, es sei denn ihr generiert die Fragentexte automatisch und aleatorisch.

Also idealerweise hier eure LSS anhängen, damit man sich das anschauen kann.

Aber: im Normalfall wird jeder Frage eine (oder gar mehrere) Spalten in der Datenbank zugewiesen. Die Reihenfolge dieser Spalten bleibt immer gleich, auch wenn die Fragen randomisiert sind.

Allerdings sind die gegebenen Antworten dann nicht unter der entsprechenden Fragengruppe zu finden, sondern zufällig unter einer anderen Fragegruppe.

Was heisst das genau? Wo schaut ihr euch das an? Export? Antworttabelle in Limesurvey?

Hallo holch,

vielen Dank für deine Antwort. Leider hat es etwas gedauert, bis wir die die LSS nun schicken können, da wir aus Datenschutzgründen die Inhalte der Unfrage anpassen mussten.

Die Antworten der Umfrage haben wir uns sowohl über Limesurvey direkt als auch in verschiedenen exportierten Formaten (csv, Excel und PDF) angeschaut und es ist überall das gleiche Problem.3

Wir haben das ganze auch nochmal selbst getestet, indem wir zwei mal bei den gleichen Fragen genau die gleichen Antworten gegeben haben. In den Ergebnissen haben wir dann allerdings in den einzelnen Spalten unterschiedliche Antworten stehen. Demnach scheinen die Antworten nicht immer in einer bestimmten anderen Spalte aufzutauchen, sondern verteilein sich zufällig auf andere Spalten, was die Daten komplett unbrauchbar macht.

Vielleicht hast du duch die LSS ja noch eine Idee, wodurch das passieren könnte. Wir wären dir auf jeden Fall super dankbar!

da wir aus Datenschutzgründen die Inhalte der Unfrage anpassen mussten.

Das ist gut so, wir wollen ja auch die Umfrage und ihren Inhalt gar nicht selber sehen, sondern eben nur ein Beispiel des Problems. Werde mir die Umfrage mal ansehen, ob es da irgendwo eine Möglichkeit gibt, dass das was ihr da beschreibt passiert.

Wenn ich da nichts in der Struktur der Umfrage finde, müsstet ihr euch direkt an die Limesurvey GmbH wenden, die sind ja für die Server und die Datenbanken zuständig. Bin mir aber ziemlich sicher, dass wenn eure Beschreibung so stimmt, dass es was mit der Struktur und irgendwelchen Skripten zu tun hat.

Schauen wir mal.

Und sicher, dass ihr eine LS5 am Start habt? Der Login-Screen eurer Installation sieht mir sehr nach LS6 aus...

Hmm, das ist natürlich jetzt ein kleines "Monster", mti so vielen Fragegruppen und Fragen und die Fragen sind auch recht schlecht beschriftet. Obst, Nüsse, Gemüse etc. hätte das verstehen doch enorm erleichtert. Jetzt steht da generisch Gruppe 1-19.

Aber fangen wir mal an:

Gruppe 1:

((( ! is_empty(TOKEN:ATTRIBUTE_1) && (TOKEN:ATTRIBUTE_1 == 1))))

Diese Condition versteh ich schon mal nicht. Die Frage wird angezeigt, wenn das attribute_1 nicht leer ist. ok. Aber dann muss es auch auf jeden Fall noch 1 sein. Aber wenn es 1 ist, dann kann es ja nicht leer sein. Also kann man sich den ersten Teil eigentlich sparen.

Das gleiche scheint auch bei Gruppe 2 usw der Fall zu sein. Wo kommen denn diese Konditionen her?

Bei Gruppe 3 ist auf einmal das TokenAttribute 19 relevant. Bei Gruppe 4 dann das Attribut 3. Das kann man so machen, klar. Kein Problem. Aber da die Gruppen und Fragen halt keine logischen Namen haben kann ich nicht erschliessen ob dies ein Fehler ist oder nicht.

Mir erscheint, dass ihr die Umfrage so "tot" anonymisiert habt, dass man gar nicht weiss, ob eine Antwort irgendwo falsch abgelegt wurde. Kann man ja gar nicht testen. Die Fragen scheinen immer alle gleich zu sein. Wie wollt ihr da wissen ob eine Antwort falsch abgelegt wurde?

Und eine Tokentabelle wäre zum testen natürlich auch gut gewesen, der Fehler kann ja auch in dieser Tabelle liegen.

Auf dieser Basis wird es schwer werden zu sagen was da schief läuft.

Habe jetzt mal in den geschlossenen Modus gewechselt. Und a entspricht die Nummer des Attributs ja immer genau der nummer der Gruppe. So ist es jedenfalls benannt.

Da dies aber bei euren Konditionen durcheinander geht, gehe ich mal davon aus, dass ihr einfach bei ein paar der Gruppen die falschen Konditionen gesetzt habt. Das würde erklären, warum mache Antworten an "der falschen Position" sind. Die Leute haben einfach die falschen Gruppen angezeigt bekommen. Siehe oben: Gruppe 3 wird angezeigt, wenn das Attribute 19 gleich 1 ist. Das ist auch noch bei ein paar anderen Gruppen der Fall, dass die Nummer der Gruppe nicht mit der Nummer des Attributs übereinstimmt. Das kann ein Problem der Anonymisierung sein, kann man halt nicht sagen.

Gruppe 8 wird z.B. angezeigt wenn Attribut 17 ==1 ist. Gruppe 11 bei Attribut 6. usw.

Das ist das einzige, was ich sehe, wäre aber eine sehr gute Erklärung für euer Problem. Würde aber auch bedeuten dass ihr eher suboptimal testet.

Hallo,
ich will mich einmal einschalten.
Zunächst:
Dieses unlogische Ungetüm ((( ! is_empty(TOKEN:ATTRIBUTE_1) && (TOKEN:ATTRIBUTE_1 == 1)))) entsteht, wenn man den Bedingungs-Designer benutzt. Der "doppel-moppelt" dabei.
Wir benutzen dieses antiquierte Relikt auch nicht mehr seit es ExpressionScript gibt.

Egal, das ist ja nicht das Problem.
Wenn Ihr genau hingeschaut habt, habt Ihr gesehen, dass nur die erste Frage (die Matrix) im Datensatz "verstreut" wird.
Und das liegt daran, dass Ihr allen diesen Fragen denselben Randomisierungsgruppennamen gegeben habt.
    



Dadurch werden alle diese 19 Matrizen über die 19 Gruppen zufällig verteilt (also Frage 1 von G17 erscheint vielleicht in G4, Frage 1 von G6 in G13)
Und das ist jetzt einfach "dumm gelaufen"
Wie @holch:
Der Test wurde nicht vollständig durchgeführt. Dieser sollte nämlich bis zum Einlesen der Testdaten in das finale Auswertetool durchgeführt werden.
Ich weiß, das ist jetzt Salz in die Wunde gestreut, tut mir auch Leid; aber machen könnt Ihr jetzt nichts mehr.

Und auch das

Mir erscheint, dass ihr die Umfrage so "tot" anonymisiert habt

Es ist doch sicher kein psychologischer Test enthalten, dessen Rechte bei irgendeinem Verlag (z.B. Hogrefe) liegen.
Bei einem anscheinend simplen Vergleich von Marken sehe ich wahrlich keinen Grund dafür.

Joffm

Joffm wieder mit seinen adleraugen. Das hatte ich gar nicht gesehen und muss gestehen, ich habe gestern Abend gar nicht dran gedacht, dass da eine randomisierung stattfindet.

Ich würde sagen Joffm hat euer Problem gelöst.

Adleraugen? Eher Maulwurfsaugen.
Ich hatte die Schriftgröße des Laptops auf 120% gesetzt und sah dann dies
 
Dreck auf dem Bildschirm, oder was? Naja, dann sah ich es. War also wirklich Zufall.

Joffm
 

Vielen herzlichen Dank euch für eure Hilfe! Das bringt auf jeden Fall schon mal Licht ins Dunkel.

Wir haben uns die Umfrage mit euren Hinweisen Im Kopf nochmal gründlich angeschaut in den letzten Tagen und haben tatsächlich noch eine offene Frage bezüglich der Randomisierungsgruppen:
wir haben teilweise zu viele Antworten auf Fragen aus bestimmten Fragegruppen. Das heißt wir haben mehr Antworten als gemäß der Vernetzung mit den Attributen möglich sein sollten. Kann das auch auf die Randomisierungsgruppen zurückgeführt werden?
Unser Verständnis wäre gewesen, dass die Randomisierungsgruppen dafür sorgen, dass die Fragen, die eine Person laut ihren Attributen sehen kann, durcheinander gewürfelt werden. Dies kann aber nicht erklären, dass wir Antworten auf Fragen haben, die Personen laut Attributen nicht sehen können oder?

Liebe Grüße

Unser Verständnis wäre gewesen, dass die Randomisierungsgruppen dafür sorgen, dass die Fragen, die eine Person laut ihren Attributen sehen kann, durcheinander gewürfelt werden.

Das ist so nicht richtig. Ihr scheint etwas zu verwechseln.
Anhand der zusätzlichen Attribute wird entschieden, welche "Gruppen" angezeigt werden.
Dies wird ja über die "Bedingung" auf Gruppen-Ebene geregelt.

Die "Randomisierungsgruppe" ist etwas ganz Anderes. Sie bezeichnet eigentlich einen internen Container mit dem Namen dieser Gruppe. Alle Elemente dieser Randomisierungsgruppe - seien es Fragen oder Gruppen - werden verwürfelt.  

Daher kann man sehr leicht ein Gegenbeispiel zu der Meinung

wir haben teilweise zu viele Antworten auf Fragen aus bestimmten Fragegruppen. Das heißt wir haben mehr Antworten als gemäß der Vernetzung mit den Attributen möglich sein sollten

konstruieren.
Nehmen wir an, jedem der ersten 10 Teilnehmer wird die GrupPe gezeigt, die seiner Nummer entspricht. 
TN1 : G1
TN2: G2
...
TN10: G10

Nun nehmen wir den pathologischen Fall, dass die Frage F1 der Gruppe 6 aufgrund der Randomisierungsgruppe
bei TN1 in G1 fällt
bei TN2 in G2
...
bei TN 10 in G10

Dann hättet Ihr 10 Antworten für die Frage F1 der Gruppe 6, die alle unsinnig sind.

Um dies nachzuvollziehen solltet Ihr in der originalen Umfrage, die noch diese Randomisierungsgruppe "r1" der Matrixfrage enthält, die Fragencodes anzeigen lassen; dann seht Ihr ja welche Frage wirklich in welcher Gruppe angezeigt wird.
Und wenn Ihr dann testweise Eingaben (wohldefiniert und notiert) macht, werdet Ihr in der Antworttabelle sehen, dass die Daten genau da stehen, wo sie laut Design sein sollen.
Welche dieser randomisierten Fragen in der laut Attribut angezeigten Gruppe gezeigt wird, ist in diesem Fall eben reiner Zufall.

Joffm

P.S.
Um einmal diese Basics zu visualisieren, solltet Ihr einfach einmal eine kleine Teststudie mit ein paar Gruppen (alle in derselben Randomisierungsgruppe) und ein paar Textanzeigen in jeder Gruppe, die nur sagen "Ich bin Frage x in Gruppe y".
Jetzt gebt einmal allen Fragen denselben Randomisierungsgruppennamen,
und ein andermal nur jeweils den Fragen innerhalb der Gruppe, aber verschieden von den Namen in den anderen Gruppen  
Und dann Gruppennamen und Fragencode anzeigen lassen

Um noch einmal darauf zurückzukommen:
Hier eine kleine Übersicht, was herauskommen kann.
10 Teilnehmer, jeweils 2 mit denselben Attributen.
 
Man sieht sehr schön, dass zwar die Gruppen angezeigt werden, wie es die Bedingung aufgrund der Attribute verlangt; aber dass dann irgendwelche zufälligen Fragen angezeigt werden.
Manche kommen gar nicht, manche mehrmals, eben alles recht zufällig.
(Wobei UG118 wohl ein Schreibfehler war)

Joffm

P.S.
Ein bisschen unklar bleibt ja auch die Beziehung zwischen Attribut und gezeigter Gruppe. Warum konnte dies nicht stringenter und weniger fehleranfällig sein?
Und wozu diente sie?
Ist es so, dass z.B. TB1 (Anton Ameise) aus einem bestimmten Grund die Attribute 1 und 2 bekam, und TB2 (Berta Biber) aus einem bestimmten Grund die Attribute 4 und 12?
Oder sollte es nur eine vordefinierte zufällige Aufteilung auf die Gruppen sein - wie ich ja schon öfters geschrieben habe "Dann lass Deine Oma vorher bestimmen, wer in welche Gruppe fällt".
Dies sind nun Interessefragen meinerseits, um so etwas bei Gelegenheit in einem der Tutorials zu zeigen - oder eben bessere Lösungen vorzuschlagen.