Hiring Data, Before the Announcement

Postings are clustered by company, normalised title, location, and description similarity, and every duplicate carries a shared cluster ID with the earliest sighting marked as the original. This matters more than it sounds: a company that syndicates aggressively can look like it is hiring five times as fast as one that only posts to its career page, which turns any un-deduplicated comparison between them into nonsense.

Yes, and it is the field that makes the dataset comparable at all. The title as posted is preserved verbatim, and alongside it we deliver a normalised title, a seniority band, and a function drawn from a consistent taxonomy. Without that layer, "Staff Engineer", "Senior Engineer II", and "Engineer III" are three unrelated strings rather than three points on one scale.

Where it is disclosed in the posting, yes — normalised for currency and period so an hourly rate and an annual band can sit in the same column. Disclosure rates vary enormously by jurisdiction, and in markets with pay transparency legislation coverage is high while elsewhere it is sparse. The field is explicitly null when nothing was disclosed rather than estimated, because an inferred salary presented as an observed one is worse than no data.

Yes. Every posting carries first-seen and last-seen dates, so a removal is visible as a last-seen date that stops advancing. That gives you time-to-fill as a derived metric and makes withdrawn roles detectable — a posting that appears and disappears within a week is itself a signal worth having.

Any company with a public career page, which in practice is nearly all of them. Engagements are usually scoped to a named watchlist — your competitors, your customers, a sector, or an index — rather than everything, because a targeted list at daily cadence is more useful than a firehose nobody filters.

No. Job postings describe roles rather than people, which makes this one of the cleanest datasets we deliver from a privacy standpoint. Where a posting names a hiring manager or recruiter, that is handled under the same lawful-basis and DPA framework as the rest of our contact data, and it can be excluded from delivery entirely if you would rather not receive it.

Into the systems you already run. Records land as JSON, CSV, or Parquet in S3, GCS, or Azure Blob, or straight into Snowflake or BigQuery, on whatever cadence you set. Webhooks push new records to your endpoints as they are detected, which is how most customers wire alerting. A solutions engineer sets the schema, cadence, and destination with you during onboarding rather than handing you a docs page and wishing you luck.

Keeping the collectors working is our responsibility, not yours. Extractors are monitored continuously, and when a site changes we patch upstream while the schema we deliver to you stays fixed — so nothing downstream needs to be touched. If a change causes a genuine coverage gap we tell you which window was affected rather than quietly returning fewer records.

Yes, and we would rather you did. Every engagement starts with a free sample run against your own targets — your competitors, your catalogue, your keywords — and we hand back the actual dataset. Judging real output against your real requirements is the only useful evaluation, and it is a much better use of a first conversation than a slide deck.