A job posting exists in one place before it exists anywhere else: the board where the employer published it. Fokals sources Job Postings there, first-party, from each employer's own careers page. This post explains what that gives you on the three things every count of postings depends on: how many records one role produces, which company a posting belongs to, and what its dates mean. The same three points will serve you in judging any source of postings.
Where a posting starts and where it travels
An employer writes a role once, in its applicant tracking system or on its own careers page. The system shows the role on the employer's public board and offers the board as a feed, so that job sites and search engines can pick the postings up. From there a posting travels: job sites list it, other sites copy those listings, and recruiters advertise the same role under their own names.
A dataset built from the copies has to work its way back to the original. It must decide which listings are one role, who the employer is and when the role opened. A dataset sourced at the board starts from the original.
Job Postings is sourced at the board. Its sources are public and first-party: the employer publishes the information itself, on the job board it runs and on its own careers page. Every record is our own observation of that publication, processed in-house.
One posting, one record
On an aggregated feed the same role can arrive several times: once from each site that lists it, again when a listing is published a second time, and again under a recruiter's name. Removing the copies means ruling that two listings with similar titles, places and employer names are one role. Any such rule errs in both directions. It merges roles that are distinct, such as two openings for one title in one office, and it keeps copies that differ by a word.
At the source there are no copies from other sites to reconcile. Each posting is one record of Job Postings, with a stable posting ID and the address of the public posting, so any record can be opened and checked against the original.
What remains is repetition the employer chose. Some employers publish one posting for each location of the same role, and some keep a posting open all year to collect applications. These are on the board, so they are in the data as published. The query below lists the titles a company has open more than once, which is where to look before you treat postings as roles.
select
company_id,
title,
count(*) as open_postings,
count(distinct country) as countries
from job_postings
where closed_at is null
group by company_id, title
having count(*) > 1
order by open_postings desc;Whether five postings for one title in five countries are five roles or one role advertised five times depends on your question. The data keeps them apart so that the decision is yours.
The company is known at the source
A job site names the employer in a text field. The name may be a trading name, a subsidiary or a recruiter acting for a client, and sometimes it is withheld. Turning that text into a company means matching names, which is where postings are assigned to the wrong company or to none.
A posting sourced from a company's own careers page needs no such match. The tie between the posting and the company is one the company itself published, so entity resolution is settled at the source and every posting arrives already attributed.
Every record then carries the company's stable company ID. When the company or its parent is listed, the record also carries the listing's ticker, MIC, ISIN, LEI and FIGI, so the postings of a brand or subsidiary can be added to those of its listed parent or kept apart. The same company ID joins Job Postings to Technology Stack, Intent Scores and Company News, so a hiring pattern can be read beside the stack and the announcements of the same company.
Dates that were observed
A listing on a job site can carry the day the employer published the role, the day the site found it or the day the listing was last refreshed, and it is not always clear which one you hold. A listing can also outlive the role it advertises. A record of Job Postings keeps the dates apart by who vouches for them.
| Field | Who says so | What it means |
|---|---|---|
| The posting date | The employer | The date the employer's board gives for the role |
| The first-seen date | Our observation | The first observation of the posting |
| The last-seen date | Our observation | The latest observation of it |
| The close date | Our observation | The close of the role, confirmed before it is written |
| The baseline flag | Our observation | The posting was already published when the company's postings were first observed, so its first-seen date is a baseline |
Three properties of the record stand behind these fields.
- A first observation is a baseline. A posting already published when a company's postings are first observed carries the baseline flag and is never counted as new, so a newly covered company brings its open roles and no false wave of openings.
- A close is confirmed before it is written. A close date marks a role that has left the employer's board, and a board that is briefly unavailable closes nothing.
- A day is written once. Hiring Activity holds each company's open, new and closed postings for every closed UTC day. Each day is written once, after it closes, and is never revised.
Together they let you ask what was known on a given day, which a back-test needs. For that question use the first-seen date and not the posting date, because the employer's date can be earlier than the day the posting could be observed. Why we write each table once covers the design, and the guide to hiring data in equity research puts Hiring Activity to work.
What a posting delivers
A careers page is public, and the employer publishes it so that candidates, job sites and search engines can find its roles. Each record of Job Postings carries the title, department, team, locations, work mode, employment type and dates of the role. From the text of the posting come the pay it advertises, stated on one annual US-dollar scale, the experience, degree and languages it asks for, whether a visa is sponsored, and the software tools it names. Each posting is then labelled by job function, by seniority and with ten role flags, under a named, frozen label version that is carried on the record.
The data is company-level throughout. What reaches you is structured data about a company's hiring: the role, where it is based, what it pays and what it asks for.
For a compliance review the chain of sources is short. A posting has one party behind it, the employer that published it. A source that passes through job sites adds a party at each step, each with terms of its own to examine. The sourcing statement is the document to give a reviewer.
What each kind of source is built for
An aggregated source is built for breadth: the widest count of vacancies across a labour market, collected from every site that lists them. A first-party source is built for the company question: which company is hiring, for what, where, at what pay and from which date, with every answer traceable to the employer's own publication.
That question is the one the Fokals hiring dataset is built around, and four datasets answer it at different grains.
- Job Postings holds every role a company publishes, labelled and dated as described above.
- Hiring Activity holds each company's open, new and closed postings for every day.
- Sales Team Metrics describes each company's sales organisation week by week.
- Sales Pay Benchmarks gives pay quartiles for sales roles by role and country.
Market Series then states hiring as weekly series by industry, country and company size band, on same-store cohorts, for the reader whose question is about a market and not one company.
Read a posting for what it is: a posting records an intention to hire, stated by the employer on the day it was published. Counted per company and per day, those intentions show where a company is building, which is what the guides to timing outreach with hiring signals and reading competitor strategy from hiring put to work. The dataset is refreshed daily and delivered by REST API or as bulk files.
Frequently asked questions
What is the difference between a company job board and a job aggregator?
A company job board is the public list of roles an employer publishes itself, usually from its applicant tracking system. A job aggregator gathers listings from many boards and job sites into one search. The board holds each role as the employer published it, under the employer's own name and with its own dates. An aggregator is built for breadth across a labour market, and the same role can appear in it several times, under different names and dates.
Why do job posting datasets contain duplicate postings?
Duplicates arise because one role is advertised in many places. The employer publishes it on its own board, job sites list it, other sites copy those listings and recruiters post it under their own names. A dataset collected from job sites receives each copy and has to decide which ones are the same role. A dataset sourced from the employer's own board receives the role as the employer published it, though an employer may still post one role once for each location.
How can you tell when a job posting was opened or closed?
You can tell when the source records its own observations. A board may give a posting date, and a closed posting simply disappears from it. Fokals Job Postings carries a first-seen date, a last-seen date and a close date on every posting, and the close is confirmed before it is written. A posting already published when a company's postings were first observed carries a baseline flag, so its first-seen date is never mistaken for an opening.
How is a job posting matched to the right company?
In first-party data the match is made at the source: a posting taken from a company's own careers page belongs to that company by the company's own publication. Fokals carries one stable company ID on every posting and, for a listed company or a brand it owns, the ticker, MIC, ISIN, LEI and FIGI of the listing. Postings therefore join to a CRM or a security master on a key, with no matching on employer names.
Do job posting datasets contain personal data?
The text of a posting can name a recruiter or give an address for applications, so ask any source what it keeps from the text. Fokals Job Postings is company-level data throughout. Each record describes a role: its title, location, work mode, advertised pay, labels and dates, under the company ID of the employer that published it.
The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.