Track Headcount Changes at Target Accounts (2026)

Thirdwatch's LinkedIn Company Employees Scraper makes headcount-velocity detection a structured workflow with pay-per-result pricing — monthly per-account snapshots, department-specific velocity tracking, buying-intent signal alerts. Built for B2B SaaS ABM teams, sales-development, intent-data SaaS builders, and B2B sales-intelligence functions.

Why track headcount-velocity at target accounts

Headcount-velocity is the canonical leading buying-intent signal. According to LinkedIn's 2024 State of Sales report, companies adding 20%+ headcount in 90 days are 3-5x more likely to purchase new SaaS tools than steady-state companies — and headcount typically leads funding announcements by 2-4 weeks. For ABM + sales-development teams, monthly headcount-velocity tracking surfaces material buying-intent before mainstream public signals.

The job-to-be-done is structured. A B2B SaaS ABM team monitors 200 target accounts monthly for headcount-velocity-tier scoring. A B2B sales-development function alerts SDRs when target accounts cross 20% headcount-growth threshold. An intent-data SaaS builder offers customer-facing headcount-velocity scoring as differentiated signal. A B2B sales-intelligence function maps cross-account hiring-velocity for territory-planning. All reduce to per-account monthly employee-count + cross-snapshot delta computation.

How does this compare to the alternatives?

Three options for headcount-velocity data:

The LinkedIn Companies actor page gives you raw real-time headcount data at materially lower per-record cost.

How to track in 4 steps

Step 1: Authenticate

export APIFY_TOKEN="apify_api_xxxxxxxxxxxxxxxx"

Step 2: Pull monthly headcount snapshots for target accounts

import os, requests, datetime, json, pathlib

ACTOR = "thirdwatch~linkedin-company-employees-scraper"
TOKEN = os.environ["APIFY_TOKEN"]

TARGET_ACCOUNTS = [
    "https://www.linkedin.com/company/stripe/",
    "https://www.linkedin.com/company/notion/",
    "https://www.linkedin.com/company/figma/",
    # ... 200 target accounts
]

resp = requests.post(
    f"https://api.apify.com/v2/acts/{ACTOR}/run-sync-get-dataset-items",
    params={"token": TOKEN},
    json={"companyUrls": TARGET_ACCOUNTS, "maxResultsPerCompany": 100},
    timeout=3600,
)
records = resp.json()
ts = datetime.datetime.utcnow().strftime("%Y%m%d")
pathlib.Path(f"snapshots/headcount-{ts}.json").write_text(json.dumps(records))
print(f"{ts}: {len(records)} employees across {len(TARGET_ACCOUNTS)} target accounts")

Step 3: Compute per-account headcount-velocity by department

import pandas as pd, glob

snapshots = sorted(glob.glob("snapshots/headcount-*.json"))
all_dfs = []
for s in snapshots:
    df = pd.DataFrame(json.loads(open(s).read()))
    df["snapshot_date"] = pd.to_datetime(s.split("-")[-1].split(".")[0])
    all_dfs.append(df)
combined = pd.concat(all_dfs, ignore_index=True)

# Department classification by title
def classify_dept(title):
    t = str(title).lower()
    if any(k in t for k in ["engineering", "developer", "engineer", "architect", "sre"]): return "Engineering"
    if any(k in t for k in ["sales", "account exec", "sdr", "bdr", "revops"]): return "Sales/RevOps"
    if any(k in t for k in ["marketing", "growth", "content", "demand gen"]): return "Marketing"
    if any(k in t for k in ["finance", "accountant", "cfo", "controller"]): return "Finance"
    return "Other"

combined["dept"] = combined.title.apply(classify_dept)

velocity = (
    combined.groupby(["company", "dept", "snapshot_date"])
    .person_id.nunique()
    .unstack(level="snapshot_date")
)
velocity["growth_90d_pct"] = (velocity.iloc[:, -1] / velocity.iloc[:, 0] - 1) * 100
print(velocity[velocity.growth_90d_pct >= 20].sort_values("growth_90d_pct", ascending=False).head(20))

Step 4: Buying-intent scoring + alerts

import requests as r

# Score by department-specific velocity matching your offering
# Example: selling RevOps tools → weight Sales/RevOps growth heavily
def buying_intent_score(row):
    score = 0
    if row.get("Sales/RevOps", 0) >= 25: score += 50
    if row.get("Engineering", 0) >= 20: score += 20
    if row.get("Marketing", 0) >= 20: score += 15
    return score

velocity_pivoted = velocity.pct_change().fillna(0) * 100
velocity_pivoted["intent_score"] = velocity_pivoted.apply(buying_intent_score, axis=1)
high_intent = velocity_pivoted[velocity_pivoted.intent_score >= 50]

for company, row in high_intent.iterrows():
    r.post("https://hooks.slack.com/services/.../...",
           json={"text": (f":dart: High buying-intent: *{company}* — "
                          f"Intent score {row.intent_score:.0f} "
                          f"(Sales {row.get('Sales/RevOps', 0):+.0f}%, "
                          f"Eng {row.get('Engineering', 0):+.0f}%)")})

print(f"{len(high_intent)} target accounts with high buying-intent score")

Sample output

{
  "company": "Notion",
  "snapshot_date": "2026-04-28",
  "total_headcount": 612,
  "headcount_90d_ago": 528,
  "growth_90d_pct": 15.9,
  "engineering_count": 245,
  "engineering_90d_ago": 198,
  "engineering_growth_pct": 23.7,
  "sales_revops_count": 87,
  "sales_revops_growth_pct": 32.4,
  "buying_intent_score": 75
}

Common pitfalls

Three things go wrong in headcount-velocity pipelines. LinkedIn-profile staleness — recently-departed employees may show the company as "current" for 30-60 days; for accurate counts, exclude profiles with last-update >180 days. Department-classification noise — title-pattern matching has false-positives (e.g., "Sales Engineer" → Sales or Engineering?); for accurate research, build canonical title-mapping. Acquisition-driven headcount jumps — M&A absorbs target-company employees overnight (10x growth in one snapshot); flag M&A events to avoid false buying-intent signals.

Thirdwatch's actor uses a lightweight HTTP path so you pay only for the data, not for proxy or compute overhead. Pair with Career Sites Scraper for active-job-postings cross-validation + [Crunchbase / Pitchbook] for funding-context. A fourth subtle issue worth flagging: post-2024 layoff cycles distorted historical-baseline; for accurate trend research, use Apr-2024+ baseline rather than pre-2023 highs. A fifth pattern unique to ABM at scale: enterprise accounts (5000+ employees) show muted percentage-growth even with 1000+ new hires — for enterprise targets, track absolute hire counts alongside percentages. A sixth and final pitfall: regional headcount-velocity differs (US headcount expanding while EU/APAC contracting); for global enterprise ABM, segment per region.

Operational best practices for production pipelines

Tier the cadence: Tier 1 (active deal-cycle accounts, weekly), Tier 2 (broader ABM list, monthly), Tier 3 (long-tail discovery, quarterly). 60-80% cost reduction with negligible signal loss when watchlist is properly tiered.

Snapshot raw payloads with gzip compression. Re-derive department-classification + intent-scoring from raw JSON as your title-pattern logic evolves. Cross-snapshot diff alerts on per-account headcount-velocity catch buying-intent inflection points.

Schema validation. Daily validation suite asserting expected core fields with non-null rates above 80% (required) and 50% (optional). LinkedIn schema occasionally changes during platform UI revisions — catch drift early. A seventh pattern at scale: cross-snapshot diff alerts for material headcount-velocity shifts (>20% department-growth in 90 days) catch buying-intent signals before public funding announcements. An eighth pattern for cost-controlled teams: implement an incremental-diff pipeline that only re-processes records whose hash changed since the previous snapshot. For watchlists where 90%+ of records are unchanged between snapshots, hash-comparison-driven incremental processing reduces downstream-compute by 80-90% while preserving full data fidelity.

A ninth pattern unique to research-grade data work: schema validation should run continuously, not just at pipeline build-time. Run a daily validation suite that asserts each scraper returns the expected core fields with non-null rates above 80% (for required fields) and 50% (for optional). Alert on schema breakage same-day so consumers don't degrade silently.

A tenth pattern around alert-fatigue management: tune alert thresholds quarterly based on actual SDR-action rates. If SDRs ignore 80%+ of alerts at a given threshold, raise the threshold. If they manually surface accounts the alerts missed, lower the threshold.

An eleventh and final pattern at production scale: cross-snapshot diff alerts. Beyond detecting individual changes, build alerts on cross-snapshot field-level diffs — name changes, role transitions, status changes. These structural changes precede or follow material events and are leading indicators of organization-level disruption. Persist a structured-diff log alongside aggregate snapshots: for each entity, persist (field, old_value, new_value) tuples per scrape. Surface high-leverage diffs to human reviewers; low-leverage diffs stay in the audit log.

A twelfth pattern: cost attribution per consumer. Tag every API call with a downstream-consumer identifier (team, product, feature) so you can attribute compute spend back to the workflow that drove it. When a downstream consumer's spend exceeds projected budget, you can have a precise conversation with them about the queries driving cost rather than a vague "scraping is expensive" debate.

Related use cases

• Scrape LinkedIn company employees for org mapping
• Build account-based marketing from LinkedIn companies
• Track startup hiring velocity on Wellfound
• The complete guide to scraping business data
• All Thirdwatch use-case guides