How job postings are classified by occupation taxonomy and seniority level

A job posting reaches a dataset as an employer's free text, and every chart of hiring by role rests on how that text was turned into categories. This post sets out how job postings are classified: against a public occupation taxonomy, by a provider's machine learning model, and onto a job function and a seniority level. After it you can read any provider's labels, ask which version produced them, and grade fifty of them by hand before you rely on a trend.

How machine learning assigns a job posting to an occupation taxonomy and a seniority level

A job posting is classified in three steps. The employer's title and text are cleaned. The cleaned text is matched, by rules or by a machine learning model, to one entry of a fixed list, the occupation taxonomy. The seniority level is usually a separate label, on each provider's own scale. Every label is a prediction.

Two published methods show the range of designs.

• Nearest title in an index. The UK Office for National Statistics gives each online job advert a four-digit SOC 2020 code. Its user guide describes the steps: the job title is cleaned, turned into numbers by term frequency and inverse document frequency over groups of three letters, and matched by a similarity measure to the closest entry of an index of standardised job titles. An advert that cannot be assigned an occupation is recorded as unknown.
• Rules first, then a model. Lightcast's postings methodology combines machine learning models with rules curated by its taxonomy team. A posting that fits a rule takes that rule's occupation, and the model decides only the postings no rule covers.

The public occupation classifications

The fixed list is often a public classification, or a provider's own list that maps to one.

These classifications sort work by kind. UK SOC 2020 also speaks of level, and means the skill level of an occupation: it groups jobs by skill level and skill specialisation, and approximates skill level by the time a person needs to become fully competent in the tasks. An occupation code names the work, and one code can hold a trainee and an experienced worker. In the US survey of occupational employment and wages, an apprentice or trainee is coded to the occupation being trained for, and a working supervisor to the occupation of the workers supervised.

The markup employers place on careers pages follows the same line. On the JobPosting type of schema.org we found an occupational category property, which prefers a term from a taxonomy such as O*NET-SOC or ISCO-08, and no property for seniority. We found no seniority scale on the pages above either. A seniority level is each provider's own scale, and a job function each provider's own list.

How job data vendors classify postings into a job function and seniority level taxonomy

Job data vendors classify postings against taxonomies of their own. Across the documentation cited below, the labels on a posting are of four kinds: a normalised title, an occupation, a broader function or career area, and a seniority level on the vendor's own scale. The lists differ from vendor to vendor, so compare labels within one taxonomy.

Two design choices in this table decide what a trend can mean. The first is whether seniority is set aside before the role is read, as Revelio Labs describes, so that a senior and a junior title land in one role. The second is whether the employer's own wording travels with the label. In Fokals Job Postings the title, department and team stay as published, the minimum years of experience is a field of its own and a people-manager flag is separate, so each label can be checked against the employer's own wording. The data dictionary lists every function and level.

What the job function and seniority fields hold in Fokals Job Postings

Each record of Fokals Job Postings carries its labels beside the employer's own words, and each label has a fixed definition.

A field left empty carries no value for that posting, so count empty fields apart when you compute a share. A posting keeps the labels it was first written with until it closes, and Hiring Activity gives the open postings of each company by function and by seniority for every closed day.

Lightcast, formerly Emsi Burning Glass: skills, title and occupation taxonomies for job postings

Lightcast is the name taken in 2022 by Emsi Burning Glass, the company formed in 2021 when Emsi merged with Burning Glass Technologies. Its site lists four taxonomies: skills, occupations, titles and tasks. A job posting is coded to a specialised occupation of the Lightcast Occupation Taxonomy, and its raw title is normalised to a Lightcast Title.

The occupation classifier reads a posting's title, description, origin country and language, after common words, company boilerplate and benefits text are removed. It returns names and codes on four tiers: career area, occupation group, occupation and specialised occupation. A posting assigned to a specialised occupation can then be mapped to national codes such as O*NET, UK SOC or NOC. Lightcast describes the taxonomy's purpose as recognising the same role under different job titles, employers and places.

Titles are a separate step. The titles classifier first strips irrelevant information from the raw title, then a vector-based machine learning model finds the best match among the defined Lightcast Titles. For seniority, the changelog of the job postings API records job seniority fields, and a parameter that selects the version of the occupation taxonomy.

Why a label is a model output that carries a version

Every part of the method can change. The classification is revised: the SOC site lists the 2000, 2010 and 2018 systems and a revision for 2028. The index of titles is updated, the model is retrained, a rule is added. Each change moves some postings from one class to another, so a share can move while hiring stands still.

An illustrative case, assuming 1,000 postings of which 300 are senior. A labeller that marks 85 of every 100 senior postings as senior, and 5 of every 100 others, reports 255 + 35 = 290 senior postings, a share of 29.0%. Its successor marks 90 and 8, and reports 270 + 56 = 326 on the same postings, a share of 32.6%. The 3.6 points belong to the labeller.

Providers answer this in two ways, and both are documented.

• Relabel the record. Lightcast's notice of a change to its title normalisation, dated 7 July 2025 for postings, states that all historic postings are normalised with the new process, so that a time series stays consistent, and suggests rerunning analyses because some normalised titles shift.
• Name the version. The changelog of Lightcast's postings API records a parameter for the version of its occupation taxonomy and a change of the default version, in the way a label version names the definition behind a row.

The question to put to a provider is the same either way: which version labelled each row, and was the past relabelled? A sample answers part of it on its own, because a step in the share of empty labels from one month to the next is a sign that the method changed. On Job Postings loaded into PostgreSQL, one query counts the postings first seen in each month and those whose seniority was left empty.

select date_trunc('month', first_seen_at) as month,
       count(*) as postings,
       count(*) filter (
         where coalesce(labels::jsonb ->> 'seniority', '') = ''
       ) as seniority_empty
from job_postings
group by 1
order by 1;

Example: grading fifty labels by hand before relying on a trend

Acme Robotics is an invented company and every figure in this example is illustrative. The method is a hand grade: a person opens each sampled posting and grades each label against the employer's own text.

Assumptions:

• Your sample data holds the postings of the companies you track, Acme Robotics among them, all drawn from one period.
• You draw 50 postings at random across companies, not the newest 50.
• One grader opens each public posting at the address its row carries and marks the job function and the seniority as correct, wrong or unsure, writing the right value beside each wrong one.
• Precision is correct divided by correct plus wrong. An unsure verdict is counted and decides nothing. A field left empty is counted apart.
• Intervals are 95% Wilson intervals, the method the NIST handbook gives for a proportion, with z = 1.96.

Read the wrong labels before the percentage. Of the eight wrong seniority labels, five sit inside the grader's band: senior where the grader read mid, for instance. Grouped into three bands (intern and entry; mid, senior, lead or principal; manager and above), those five become correct and precision rises from 81.8% to 93.2%. The ONS guide of November 2024 reports the same effect for its own method: 65% precision at the four-digit level, rising to 74% when adverts are grouped at the two-digit level, on a random sample of 1,000 adverts coded by three in-house coders, with the method's code compared with that of at least one coder. The coders could not always agree on an advert. That is what the unsure verdict is for.

Fifty labels screen a field. At the full scale the lower end of the interval is 68.0%, too wide to carry a chart of one level, and at three bands it is 81.8%. To keep the full scale, grade more: 164 correct of 200 decided is 82.0%, with an interval of 76.1% to 86.7%. The four empty labels matter too. Coverage of the field is 46 of 50, or 92%, and if that share moves between periods the shares among labelled postings move with it.

Now the trend. Suppose the 30-day window for Acme Robotics' industry shows 120 of 400 opened postings in the management band, 30.0%, against 104 of 400, 26.0%, in the window before. The same formula puts the first share between 25.7% and 34.7% and the second between 21.9% and 30.5%. The intervals overlap, so one pair of windows at these counts does not separate a four-point move from chance. Read the 180-day window, or wait for the move to hold in a second period.

How to track hiring trends by job function and seniority across an industry

To track hiring trends by job function and seniority across an industry, count the postings opened in a fixed window, take the share of each function and each level among them, and compare it with the window before over the same set of companies. Keep to one set of definitions, and read every share beside its count.

Fokals Market Series delivers these as two families of weekly series, the function share and the seniority share: the share of the postings opened in the window that fall in each function or at each level, by industry, country and company size band, over 7, 30 and 180 days. Each row carries the count, the cohort it is over, the rate, the same count over the window before, the growth between the two and an index. The series are built on same-store cohorts, and each as-of date is written once and never revised. Hiring Activity gives the same split per company: open postings by function and by seniority for every closed day.

Before a trend goes into a note or a model, run five checks.

1. One definition: both windows read under the same definitions, or any change of definition marked on the chart.
2. A hand grade: fifty labels at the grain you chart, with the interval, as in the example.
3. The empty share: the share of postings whose label was left empty, steady across the windows.
4. The count: an interval on each share from its own count. A move inside both intervals is not yet a trend.
5. The mix: function and seniority read together, because more senior roles across every function and more roles in one senior-heavy function are different findings.

The guide to sector hiring trends for thematic research takes the series further.

Tools to analyse job postings data by industry, role and seniority level

Three kinds of tool analyse job postings data by industry, role and seniority level. A statistics office publishes measures by occupation. A vendor's postings product applies its own taxonomy to the postings it collects. A licensed dataset arrives by API or bulk file with labels and their version on each row, and you run the analysis in your own SQL.

Profiling a sample file before you load it, labels included, is shown in exploring bulk company data with DuckDB.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.

What this page says about the products it names was checked against their public documentation on 7 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.