Ein SurveyJS-Template beschreibt Struktur, Fragen und Präsentationslogik eines Surveys — Seiten, Elemente, Fragetypen, Validatoren und bedingte Sichtbarkeitsregeln. Es nutzt dasselbe offene, deklarative Format wie das SurveyJS-Ökosystem, sodass alles, was du baust, portabel bleibt, statt in einem proprietären Format gefangen zu sein.
Der Survey-Creator von Crowdee lässt dich Templates visuell erstellen und in der Vorschau ansehen. Templates können auf ein bestimmtes Projekt beschränkt oder in der gesamten Organisation geteilt werden, und sie lassen sich vollständig über die API verwalten — die genaue Referenz findest du unter https://docs.crowdee.ai. Was du im visuellen Editor baust, entspricht immer derselben Struktur, die die API zurückgibt — ein von Hand gestaltetes und ein programmatisch bereitgestelltes Template sind also jederzeit austauschbar.
Ein Crowd-Job referenziert immer eine bestimmte Version eines Templates, nicht das Template selbst. Das ist eine bewusste Designentscheidung: Sobald ein Job erstellt wurde, ist der Survey, den er den Workern präsentiert, eingefroren. Nachfolgende Bearbeitungen des Templates erstellen neue Versionen, beeinflussen aber laufende Jobs nicht.
Jede Änderung an einem Template erzeugt eine neue Version. Versionen werden nur hinzugefügt; der Verlauf wird nie überschrieben. Das ist wichtig für die Datenprovenienz: Wenn du Crowd-Antworten sechs Monate nach einem Job exportierst, kannst du immer genau rekonstruieren, welche Frageformulierung und welche Antwortoptionen die Worker gesehen haben, weil jeder Job — und jede Aufgabe darin — dauerhaft mit der exakten Version verknüpft bleibt, die verwendet wurde.
Die praktische Implikation für Template-Autoren ist, jede Version als eigenständiges Messinstrument zu betrachten. Eine Frage, die zur Klarheit umformuliert wurde, ist nicht dieselbe Frage — Worker könnten sie anders interpretieren, und das Zusammenführen von Antworten aus verschiedenen Versionen könnte Inkonsistenz einführen. Wenn ein Template während eines Projekts verbessert werden muss, erstelle einen neuen Job, der die neue Version referenziert, und trenne die resultierenden Datensätze klar. Mische keine Antworten aus verschiedenen Versionen, ohne die Instrument-Änderung zu berücksichtigen.
Statische Templates stellen jedem Worker dieselben fixen Fragen. Das funktioniert für binäre Klassifikationsaufgaben, bei denen der Beurteilungsgegenstand für alle Worker gleich ist. Für Aufgaben, bei denen jeder Worker ein anderes Inhaltselement beurteilen soll — einen anderen Nachrichtenartikel, eine andere Bild-URL, eine andere Produktbeschreibung — braucht man Per-Task-Variation.
Platzhalter lösen dieses Problem. Der Template-Body kann Tokens wie ###feldName### enthalten. Bei der Task-Zuweisung ersetzt die Plattform diese Tokens durch Werte aus der zugewiesenen Input-Data-Variante des Workers. Eine Frage wie "Bitte lesen Sie den folgenden Beitrag und bewerten Sie seine Kohärenz: ###postText###" wird bei der Zuweisung zu "Bitte lesen Sie den folgenden Beitrag und bewerten Sie seine Kohärenz: [der eigentliche Beitragstext]". Welchen Inhalt ein Worker tatsächlich gesehen hat, lässt sich später immer nachvollziehen, sodass Antworten gegen den exakten Input geprüft werden können, der sie hervorgebracht hat.
Wir verwenden eine Namenskonvention für häufige Platzhaltertypen: ###postN### für Beitragsinhalte (wobei N eine Sequenznummer ist), ###adjectiveNleft### und ähnliches für qualitative Dimensionen. Die Namenskonvention ist projektspezifisch — entscheidend ist die Konsistenz zwischen den Platzhalter-Tokens im Template und den Feldnamen in den Input-Data-Varianten.
Das häufigste Versagensmuster bei Crowd-Urteilsaufgaben ist Mehrdeutigkeit: Der Worker hat die Aufgabe erledigt, aber es ist unklar, was seine Antwort eigentlich bedeutet. Ein Urteil ist prüfbar, wenn man die Antwort ansehen und eine klare Entscheidung treffen kann — akzeptieren, ablehnen, aggregieren oder eskalieren. Um dorthin zu gelangen, muss das Template-Design den größten Teil der Interpretationsarbeit im Voraus leisten.
Bevorzuge binäre und ordinale Skalen gegenüber Freitext für die primäre Urteilsfrage. "Ist diese Schlagzeile sachlich korrekt? Ja / Nein / Kann nicht beurteilt werden" ist wesentlich einfacher zu aggregieren als "Beschreiben Sie etwaige Ungenauigkeiten." Nutze Freitext für unterstützende Details — ein Kommentarfeld, eine Konfidenzangabe — aber verankere das Haupturteil in einer strukturierten Antwort. Das macht automatische Aggregation, Mehrheitsentscheid und Qualitätsbewertung unkompliziert, ohne Nachbearbeitung.
Halte Templates kurz. Worker-Erschöpfung ist real und beeinflusst die Antwortqualität bei den letzten Fragen eines langen Surveys überproportional. Ein Template mit drei fokussierten Fragen erzeugt bessere Daten als eines mit zwölf Fragen, das alles abdeckt. Wenn zwölf Fragen an Signal nötig sind, führe mehrere kürzere Jobs in Sequenz durch.
Einige praktische Regeln, die wir bei verschiedenen Aufgabentypen durchgängig als nützlich befunden haben:
Diese Regeln gelten unabhängig von den verwendeten SurveyJS-Fragetypen. Die Plattform unterstützt die vollständige SurveyJS-Fragenbibliothek — Radiogruppen, Checkboxen, Matrizen, Dropdowns, Datei-Upload und mehr — aber die oben genannten Designprinzipien betreffen die Urteilsaufgabe, nicht das Widget.
Artikel teilen:
