Jedes andere Produkt auf der Plattform startet mit einer bekannten, endlichen Menge an Eingaben: Sie laden eine Datei hoch, oder Sie hängen ein Input-Data-Set mit einer festen Anzahl an Varianten an, und die Crowd arbeitet genau diese Menge ab. Content Gathering hat diesen Luxus nicht. Wenn Sie eine Crowd bitten, jeden aktuellen Beitrag zu einer bestimmten Behauptung zu finden, oder jeden Account, der ein bestimmtes Bild verbreitet, wissen Sie im Voraus wirklich nicht, wie viele passende Einträge existieren — könnten drei sein, könnten dreihundert sein.
Diese Offenheit ist der Grund, warum Gathering-Jobs eine eigene gathering-Kategorie in der Job-Engine erhalten, statt das feste Varianten-Modell wiederzuverwenden, das Umfragen und Reviews antreibt. Mitarbeitende bekommen nicht jeweils eine Variante zugewiesen; sie suchen anhand Ihrer Kriterien und reichen so viele passende Einträge ein, wie sie finden — bis zu den konfigurierten Job-Grenzen.
Sie definieren zusammen mit dem Job einen gatheringCriteria-Datensatz: Schlüsselwörter, zu durchsuchende Plattformen, einen Zeitraum, Sprachen, Inhaltstypen und Mindest-Engagement-Schwellen. Mitarbeitende sehen dieses Briefing als Aufgabenanleitung und durchsuchen dann zugewiesene Plattformen und das offene Web, wobei sie jeden Treffer mit Quell-URL, Autoren-Handle, Inhaltstyp und den verfügbaren Engagement-Kennzahlen (Likes, Shares, Views) übermitteln.
Optional kann ein Gathering-Job Mitarbeitenden ein Web-Search-Assist-Werkzeug direkt in ihrer Aufgabe zur Verfügung stellen — eine kleine, proxied Suchbox, mit der sie einen Hinweis überprüfen können, ohne die Aufgabenoberfläche zu verlassen. Es ist dasselbe Widget-Muster, das an anderer Stelle der Plattform für Mitarbeitende verwendet wird, nur auf die allgemeine Websuche statt auf eine bestimmte Referenzdatenbank ausgerichtet.
Das offensichtliche Risiko bei offener Crowd-Suche ist Redundanz: Wenn zehn Mitarbeitende alle nach derselben trendenden Behauptung suchen, werden mehrere von ihnen denselben Beitrag finden. Jeder eingereichte Eintrag erhält einen pro Job berechneten Dedupe-Hash, und ein eindeutiger Index auf (jobId, dedupeHash) sorgt dafür, dass eine doppelte Einreichung schlicht keinen zweiten abrechenbaren Eintrag erzeugt — sie wird automatisch erkannt und zählt nicht gegen Ihr maxAssignments-Budget. Sie zahlen für einzigartige Funde, nicht für redundante Abdeckung.
Einträge verschwinden nach der Einreichung nicht. Jeder startet im Review-Status pending und wechselt zu accepted, rejected oder duplicate, sobald Sie ihn prüfen — entweder manuell oder per automatisierter Regel, falls Ihr Workflow das erfordert.
Gathering zahlt sich nur aus, wenn das Gefundene leicht weiterzuverarbeiten ist. Akzeptierte Einträge werden direkt umgewandelt — entweder in eine Dataset-Version, bereit für die Multimedia-Verifikation, oder in ein Input-Data-Set, bereit für die Quellenrecherche oder einen individuellen Crowdsourcing-Job. Beide Umwandlungen sind einzelne API-Aufrufe gegen den Gathering-Job — dazwischen gibt es keinen manuellen Export-, erneuten Upload- oder Umformatierungsschritt.
Genau diese Übergabe ist der Grund, warum wir Gathering in unserer Roadmap vor die Verifikation gesetzt haben: Eine Redaktion, die eine sich schnell entwickelnde Geschichte beobachtet, kann von „Finde alles, was diese Behauptung erwähnt" zu „Führe Deepfake- und Manipulationserkennung auf allem Gefundenen aus" gelangen, ohne die API der Plattform je zu verlassen.
Für Gathering gibt es keinen festen Plattformpreis — Sie legen die Belohnung pro Eintrag selbst fest, genau wie bei jedem anderen Crowd-Job, und Credits in Höhe von maxAssignments × rewardCredits werden im Voraus blockiert. In der Praxis liegen die meisten von uns gescopten Kampagnen zwischen 0,10 € und 0,50 € pro akzeptiertem Eintrag, abhängig von der Plattform und dem Prüfaufwand, den der Inhaltstyp erfordert. Die vollständige API-Referenz finden Sie in der Content-Gathering-Dokumentation.
Artikel teilen:
