Every other product on the platform starts from a known, finite set of inputs: you upload a file, or you attach an input data set with a fixed number of variants, and the crowd works through exactly that set. Content Gathering doesn't have that luxury. When you ask a crowd to find every recent post mentioning a claim, or every account spreading a particular image, you genuinely don't know in advance how many matching items exist — could be three, could be three hundred.
That open-endedness is why gathering jobs get their own gathering category on the job engine instead of reusing the fixed-variant model that powers surveys and reviews. Workers aren't assigned one variant each; they search against your criteria and submit as many matching items as they find, up to the job's configured limits.
You define a gatheringCriteria record alongside the job: keywords, which platforms to search, a date range, languages, content types, and minimum engagement thresholds. Workers see this brief as their task instructions, then search assigned platforms and the open web, submitting each match with its source URL, author handle, content type, and whatever engagement metrics (likes, shares, views) they can find.
Optionally, a gathering job can grant workers a web-search-assist tool right inside their task — a small proxied search box that lets them verify a lead without leaving the task interface. It's the same worker-facing widget pattern used elsewhere on the platform, just pointed at general web search instead of a specific reference database.
The obvious risk with open-ended crowd search is redundancy: if ten workers are all looking for the same trending claim, several of them will find the same post. Every submitted item gets a dedupe hash computed per job, and a unique index on (jobId, dedupeHash) means a duplicate submission simply doesn't create a second billable item — it's automatically recognized and doesn't count against your maxAssignments budget. You pay for distinct discoveries, not for redundant coverage.
Items don't disappear once submitted. Each one starts in a pending review state and moves to accepted, rejected, or duplicate as you review them — either manually, or by an automated rule if your workflow needs one.
Gathering only pays off if what you find is easy to act on. Accepted items convert directly into either a dataset version — ready for Multimedia Verification — or an input data set, ready for Source Research or a custom crowdsourcing job. Both conversions are single API calls against the gathering job; there's no manual export, re-upload, or reformatting step in between.
That handoff is the whole point of sequencing gathering before verification in our roadmap: a newsroom monitoring a fast-moving story can go from "find everything mentioning this claim" to "run deepfake and manipulation detection on everything we found" without ever leaving the platform's API.
There's no fixed platform price for gathering — you set the reward per item yourself, exactly like any other crowd job, and credits equal to maxAssignments × rewardCredits are blocked upfront. In practice, most campaigns we've scoped land between €0.10 and €0.50 per accepted item, depending on the platform and how much verification the content type demands. See the Content Gathering documentation for the full API reference.
Share this article:
