Track Job Posting Velocity on Google Jobs (2026)

Thirdwatch's Google Jobs Scraper makes labor-market posting-velocity tracking a structured workflow with pay-per-result pricing — daily snapshots across role-category watchlists, 7-day rolling deltas, role-emergence detection, alerting on category surges. Built for labor-economics researchers, workforce-strategy consultancies, HR-tech platforms surfacing market signals, and venture-investing analysts studying skills-market trajectories.

Why track posting velocity on Google Jobs

Aggregate posting velocity is a leading indicator. According to Google's 2024 Jobs Search statistics, Google Jobs indexes more than 60% of US public job postings across all major boards, making it the closest cross-board approximation of total labor-market volume available without official BLS data. For labor-economics researchers, workforce-strategy consultancies, and HR-tech platforms, daily Google Jobs snapshots produce a 6-12 week leading indicator of monthly BLS releases.

The job-to-be-done is structured. A labor-economics researcher tracks 200 role categories daily for trend research. A workforce-strategy consultancy maintains category-velocity dashboards for enterprise client briefings. An HR-tech platform surfaces emerging-role signals to recruiter users. A venture-investing analyst studies skill-domain growth as input to thesis development. All reduce to category list + daily snapshot + rolling-window delta computation.

How does this compare to the alternatives?

Three options for posting-velocity data:

BLS is authoritative but lagged. Lightcast offers detailed labor-market data at the high end. The Google Jobs Scraper actor page gives you daily-frequency aggregate-posting data at the lowest unit cost.

How to track velocity in 4 steps

Step 1: How do I authenticate against Apify?

Sign in at apify.com (free tier, no credit card), open Settings → Integrations, and copy your personal API token:

export APIFY_TOKEN="apify_api_xxxxxxxxxxxxxxxx"

Step 2: How do I pull a category watchlist daily?

Pass role-category queries.

import os, requests, datetime, json, pathlib

ACTOR = "thirdwatch~google-jobs-scraper"
TOKEN = os.environ["APIFY_TOKEN"]

CATEGORIES = ["software engineer", "data scientist", "product manager",
              "ai engineer", "ml engineer", "devops engineer",
              "site reliability engineer", "security engineer",
              "data engineer", "frontend engineer",
              "backend engineer", "full stack engineer",
              "mobile engineer", "embedded engineer", "game developer"]

resp = requests.post(
    f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items",
    params={"token": TOKEN},
    json={"queries": CATEGORIES, "country": "us", "maxResults": 100},
    timeout=3600,
)
records = resp.json()
ts = datetime.datetime.utcnow().strftime("%Y%m%d")
pathlib.Path(f"snapshots/google-jobs-{ts}.json").write_text(json.dumps(records))
print(f"{ts}: {len(records)} jobs across {len(CATEGORIES)} categories")

15 categories × 100 = up to 1,500 records daily — well within budget for a labor-market velocity dashboard.

Step 3: How do I compute rolling-window velocity?

Aggregate per-category counts and detect spikes.

import pandas as pd, glob

snapshots = sorted(glob.glob("snapshots/google-jobs-*.json"))
dfs = []
for s in snapshots:
    df = pd.DataFrame(json.loads(open(s).read()))
    df["snapshot_date"] = pd.to_datetime(s.split("-")[-1].split(".")[0])
    dfs.append(df)

all_df = pd.concat(dfs, ignore_index=True).drop_duplicates(subset=["apply_url", "snapshot_date"])

daily = (
    all_df.groupby(["searchString", "snapshot_date"])
    .size()
    .unstack(fill_value=0)
)

rolling7 = daily.rolling(window=7, axis=1).mean()
rolling28 = daily.rolling(window=28, axis=1).mean()
ratio = rolling7 / rolling28.replace(0, 1)

spikes = ratio.iloc[:, -1].sort_values(ascending=False)
print("Top 10 categories with rising velocity:")
print(spikes.head(10))

A category at 2x+ ratio (7-day average vs 28-day average) is materially trending up. For research output, smooth across multiple snapshots before declaring a real signal.

Step 4: How do I detect emerging categories?

Track 30-day rolling growth on the cumulative category set.

emerging = (
    daily.iloc[:, -30:].sum(axis=1) /
    daily.iloc[:, -90:-60].sum(axis=1).replace(0, 1)
)
emerging = emerging[emerging >= 5.0].sort_values(ascending=False)
print(f"{len(emerging)} categories with 5x+ 30-day vs prior-30 growth")
print(emerging)

Categories sustaining 5x+ growth across 90+ days are emerging — these become canonical role categories within 6-12 months.

Sample output

A single Google Jobs record for velocity tracking looks like this. Five rows weigh ~10 KB.

{
  "title": "AI Engineer",
  "company_name": "Anthropic",
  "location": "San Francisco, CA",
  "salary": "$220,000 - $350,000",
  "job_type": "Full-time",
  "source": "LinkedIn",
  "apply_url": "https://www.linkedin.com/jobs/view/...",
  "posted_date": "1 day ago",
  "description": "Build production AI systems..."
}

apply_url enables cross-snapshot dedup. searchString (the original query) tags the category. posted_date enables freshness filtering. source lets you split velocity by underlying board if needed for cross-source attribution.

Common pitfalls

Three things go wrong in velocity-tracking pipelines. Re-indexing inflation — Google occasionally re-indexes existing postings, causing phantom 1-day volume spikes; smooth with 3+ day rolling windows before alerting. Cross-category cannibalization — adjacent categories steal volume from each other ("AI engineer" siphoning from "ML engineer"); for clean trend research, track total cohort volume alongside individual categories. Seasonal cycles — most categories show predictable Q1/Q3 hiring peaks; deseasonalize before computing velocity ratios.

Thirdwatch's actor handles the anti-bot work and proxy rotation so you can focus on the data. Pair Google Jobs with LinkedIn Jobs Scraper for source-level depth on top-velocity categories. A fourth subtle issue worth flagging: Google Jobs aggregation introduces a 6-24 hour delay between original posting and Google's indexing, so velocity computed from Google Jobs lags real-time hiring signal by roughly a day; for use cases requiring true-real-time signal (sales-intel teams responding to competitor hiring spikes within hours), supplement Google Jobs velocity with direct-source LinkedIn polling for the top 50 watchlist accounts. A fifth pattern unique to velocity research: certain role categories are dominated by one or two mega-employers (Amazon hiring tens of thousands of warehouse workers, large IT-services firms posting standardized job templates) — when these firms run quarterly hiring waves, the category-level velocity spikes 5-10x without reflecting broader labor-market shifts. For accurate trend research, deweight or exclude rows from the top-3 dominant employers per category before computing velocity. A sixth and final pitfall: cost-of-living and remote-policy shifts cause certain categories to migrate across metros (a "data engineer" role splitting from SF-only to Austin/Denver/remote distributed) — apparent metro-level decline can mask category-level growth; for clean role-category velocity, aggregate at the national level rather than per-metro. A seventh and final pattern worth flagging for production teams: data-pipeline cost optimization. The actor's pricing scales linearly with record volume, so for high-cadence operations (hourly polling on large watchlists), the dominant cost driver is the size of the watchlist rather than the per-record fee. For cost-disciplined teams, tier the watchlist (Tier 1 hourly, Tier 2 daily, Tier 3 weekly) rather than running everything at the highest cadence — typical 60-80% cost reduction with minimal signal loss. Combine tiered cadence with explicit dedup keys and incremental snapshot diffing to keep storage and downstream-compute proportional to new signal rather than total watchlist size. This is the difference between an order-of-magnitude-cheaper research pipeline and a much more expensive one for the same actionable output. An eighth subtle issue worth flagging: snapshot-storage strategy materially affects long-term pipeline economics. Raw JSON snapshots compressed with gzip typically run 4-8x smaller than uncompressed; for multi-year retention, always compress at write-time. For high-frequency snapshots, partition storage by date prefix (snapshots/YYYY/MM/DD/) to enable fast date-range queries and incremental processing rather than full-scan re-aggregation. Most production pipelines keep 90 days of raw snapshots at full fidelity + 12 months of derived per-record aggregates + indefinite retention of derived metric time-series — three retention tiers managed separately.

Related use cases

• Scrape Google Jobs aggregated listings
• Build a multi-source jobs feed with Google Jobs
• Find jobs with direct apply URLs
• The complete guide to scraping job boards
• All Thirdwatch use-case guides