01Job data

Jobs guide 02 · Job data

How to Use Glassdoor Job Data for Market and Hiring Research

Turn public Glassdoor job listings into defensible hiring signals with a source-first schema, freshness controls, employer grouping, and sample validation.

Glassdoor job data is most useful as evidence of visible hiring activity—not as a complete picture of an employer’s workforce plans. A reliable workflow keeps the public source URL, collection time, search parameters, and missing fields attached to every listing.

The Glassdoor Jobs Scraper is the focused AgentX route for collecting current listing data from that source. Validate the live input and output schemas before building a recurring monitor because source behavior and Actor contracts can change.

What questions can Glassdoor listings answer?

Public job listings can support several concrete research questions:

  • Which roles is a company visibly recruiting for?
  • In which cities or countries is hiring activity appearing?
  • Which skills recur across similar roles?
  • How do displayed compensation ranges differ by location or seniority?
  • How long do listings remain visible in repeated snapshots?

They cannot prove headcount growth, filled positions, budget approval, or the absence of unlisted recruiting. Present the result as “observed public listings,” not as a complete hiring ledger.

Which fields should be preserved?

The raw layer should retain every field returned by the current Actor contract. The analytical layer should prioritize:

AreaFields to retain
Provenancelisting URL, source ID, collected timestamp, query
Employerdisplayed company name, company URL or identifier
Roletitle, description, seniority, employment type
Locationdisplayed location, normalized country/region/city, remote signal
Timingdisplayed posting age/date, first seen, last seen
Compensationminimum, maximum, currency, pay period, displayed text

Keep the displayed value beside every normalized value. If “$80K–$110K” becomes two numbers, the original text is the audit trail for currency and period assumptions.

How should employer names be normalized?

Normalize for grouping, but never overwrite the source label. Remove harmless punctuation and legal suffix differences in a separate comparison field. Do not automatically merge companies only because their cleaned names are similar.

A defensible employer key may use:

  1. a stable source identifier when available;
  2. a verified company URL;
  3. a normalized name plus location or domain evidence;
  4. a manual review queue for ambiguous matches.

This is particularly important when a parent company, subsidiary, recruiter, and staffing agency can all appear in the same result set.

How do repeated snapshots become trend data?

One crawl is a discovery snapshot. A sequence of snapshots can show changes, but only if collection conditions remain stable.

Use the same query, geography, result limit, and normalization version on each run. Store firstSeenAt and lastSeenAt separately from the source’s displayed posting date. When a listing disappears, mark it unobserved; do not claim it was filled or cancelled without another source.

Useful weekly measures include:

  • new listing count by employer and function;
  • active observed listing count;
  • median observed listing duration;
  • share of roles with salary information;
  • location and workplace-type distribution;
  • newly appearing skill phrases.

How should compensation be compared?

Never compare salary values until currency and pay period are normalized. Hourly, monthly, and annual values should remain separate unless a documented conversion policy exists. Ranges with missing currencies belong in an “unknown” bucket rather than inheriting the query country by assumption.

Also separate employer-provided ranges from estimates when the source distinguishes them. The exact live Actor output determines which distinction is available.

What does a good pilot look like?

Run one narrow employer-and-location query first. Manually open a sample of source URLs and compare visible fields with the dataset. Record:

  • false matches caused by keywords;
  • duplicate URLs or repeated roles;
  • missing or ambiguous locations;
  • dates that cannot be converted confidently;
  • descriptions truncated upstream;
  • any gap between visible content and returned fields.

Only then expand to multiple employers or regions.

When should a multi-source Actor be used instead?

Use Glassdoor alone when source specificity matters. Use All Jobs Scraper when the primary goal is a common schema across several boards. The multi-source route is better for coverage comparisons; the dedicated route is often better for source-level debugging and depth.

Continue with LinkedIn vs. Indeed vs. Glassdoor Job Data or browse every AgentX job-data Actor.

Continue in the directory

Turn the guide into a real sample run.

Open the current AgentX contract, check pricing and fields, then validate a narrow output.

Open the Actor