Einen Crowd-Job zu erstellen dauert nur einen Schritt. Man verknüpft eine Survey-Vorlage (die das Task-UI und die Fragen definiert, die Worker beantworten) sowie optional ein Datenset, das bestimmt, was jeder Worker zu sehen bekommt. Danach legt man ein paar einfache Einstellungen fest: wie viele Credits ein Worker pro akzeptierter Antwort erhält, wie viele akzeptierte Antworten insgesamt gesammelt werden sollen, in welchem Zeitraum der Job offen sein soll und wie viele verschiedene Worker dasselbe Element beantworten dürfen, bevor es als abgedeckt gilt.
Nach der Erstellung ist ein Job zunächst unveröffentlicht. Durch die Veröffentlichung wird er zuweisbar, das heißt, er wird für berechtigte Worker sichtbar. Von dort durchläuft ein Job einen einfachen Lebenszyklus: zuweisbar, dann pausiert oder unveröffentlicht, falls man ihn zurückzieht, dann ausgeschöpft, sobald alle Slots belegt sind, und schließlich abgeschlossen, wenn er geschlossen wird – entweder manuell oder automatisch. Jederzeit lässt sich der aktuelle Fortschritt einsehen: wie viele Slots noch offen sind und welche Worker gerade aktiv sind, direkt im Job-Dashboard.
Bevor man einen Job für echte Worker veröffentlicht, lohnt sich ein Dry-Run: den Job als Test markieren, ein paar E-Mail-Adressen hinterlegen, die ihn sehen dürfen, und optional einen privaten Link für Tester teilen. Ein Dry-Run-Job verhält sich hinsichtlich Task-Zuweisung und Antwortsammlung identisch wie ein Live-Job, bleibt aber für den allgemeinen Worker-Pool unsichtbar. So lassen sich Survey und Reward-Einstellungen validieren, ohne Produktionsdaten zu beeinflussen.
Worker erreichen Jobs über ihr eigenes Dashboard. Registrierte Worker verfügen über Accounts, in denen sie ihr Guthaben einsehen, Auszahlungen anfragen und Dateien zusammen mit ihren Antworten hochladen können. Auch anonyme Teilnehmer können mitmachen, über Gastsitzungen, mit denen sich ihr Einreichungsverlauf verfolgen lässt, ohne dass ein Konto nötig ist.
Wenn ein Worker eine Aufgabe annimmt, wird der entsprechende Slot als zugewiesen markiert und erhält eine Frist. Der Worker sieht dann die Survey, befüllt mit dem Element, das ihm zugewiesen wurde. Reicht der Worker nicht rechtzeitig ein, läuft der Slot ab und kehrt in den Pool zurück, damit ihn jemand anderes übernehmen kann. Worker können eine Aufgabe auch explizit zurückgeben, wenn sie es sich anders überlegen. In beiden Fällen wird der Slot wieder verfügbar, sodass die angestrebte Zahl akzeptierter Antworten eine Obergrenze für abgeschlossene, akzeptierte Arbeit ist – nicht für jeden einzelnen Versuch unterwegs.
Eingereichte Antworten landen in einer Prüfwarteschlange mit dem Status „ausstehend". Man kann eine paginierte Liste aller Antworten zu einem Job abrufen, jeweils mit dem vollständigen Inhalt der Einreichung, dem Element, auf das der Worker geantwortet hat, sowie Metadaten wie dem Einreichungszeitpunkt. Dateien, die ein Worker als Teil seiner Antwort hochgeladen hat, stehen zur Prüfung und zum Download bereit.
Für eine übergeordnete Sicht zeigt dasselbe Live-Dashboard, das auch den Fortschritt verfolgt, wie viele Antworten zur Prüfung anstehen, wie viele akzeptiert oder abgelehnt wurden und welche Worker gerade aktiv sind. Im Platform-UI treibt das ein nahezu in Echtzeit aktualisiertes Job-Dashboard an, das alle paar Sekunden aktualisiert wird, solange der Job offen ist. Die genauen Schnittstellen dazu finden sich in der API-Referenz unter docs.crowdee.ai.
Jede ausstehende Antwort kann einzeln akzeptiert oder abgelehnt werden. Bei einer Ablehnung lässt sich optional ein Grund angeben, der gespeichert und dem Worker als Feedback angezeigt werden kann. Abgelehnte Antworten zählen nicht gegen die angestrebte Zahl akzeptierter Antworten und schaffen so effektiv Platz für eine Ersatzeinreichung.
Credits werden erst bei Akzeptanz übertragen. Der Verdienst eines Workers für eine Antwort bleibt zunächst offen, bis die Antwort akzeptiert wird – erst dann werden die Credits gutgeschrieben und das Guthaben des Workers entsprechend erhöht. Credits werden bereits bei der Zuweisung einer Aufgabe reserviert und im Ablehnungsfall wieder freigegeben oder im Akzeptanzfall an den Worker übertragen. Dieses Modell aus Reservierung und späterer Abrechnung hält sowohl Auftraggeber als auch Worker auch dann in einem konsistenten Zustand, wenn ein Job mitten im Lauf pausiert wird.
Mit einem Satz akzeptierter Antworten stehen mehrere nachgelagerte Wege offen. Man kann alle Antworten als JSON oder CSV exportieren, was sich für Offline-Analysen, Qualitätsaudits oder die Weiterleitung an ein externes System eignet. Die genauen Exportoptionen sind in der API-Referenz dokumentiert.
Für Workflows, die innerhalb der Plattform bleiben, überspringen zwei Abkürzungen den Exportschritt vollständig. Man kann akzeptierte Antworten – zusammen mit allen angehängten Dateien – direkt in ein neues Dataset verpacken, das bereit für Cleaning oder Verifikation ist. Oder man wandelt textbasierte Antworten in ein neues Input-Set um, das einen Folge-Crowd-Job speist – nützlich für mehrstufige Annotationsarbeiten, bei denen die Ausgabe einer Crowd zur Eingabe der nächsten wird.
Schließlich lässt sich die Konfiguration eines Jobs jederzeit als neuer Entwurf klonen. Der Klon startet unveröffentlicht und übernimmt Survey, Datenset, Reward-Einstellungen und alle weiteren Einstellungen – jedoch nicht die bereits gesammelten Antworten. Klonen ist der schnellste Weg, um einen weiteren Batch mit angepassten Parametern zu starten.
Artikel teilen:
