Monitor New Employees at Target Accounts Without Fake Headcount Math

Public LinkedIn search can tell you that a profile became newly visible for a company. It cannot tell you the company's exact headcount, and it cannot prove somebody left because a search result disappeared.

That distinction matters. A lot of "headcount intelligence" is just arithmetic performed on two incomplete search samples. The numbers look precise. The underlying data is not.

The LinkedIn Company Employees Scraper takes the narrower, defensible route: establish a baseline and alert only when an unseen profile appears in two consecutive complete snapshots.

Run the ready-made Task: Monitor confirmed new employees at target accounts.

What the monitor can and cannot prove

It can help you find:

• newly visible sales, engineering, product, or leadership profiles at named accounts;
• people to review before an ABM or recruiting campaign;
• changes worth checking against job postings, company announcements, or a CRM;
• a repeatable feed that emits no profile rows when nothing new is confirmed.

It cannot reliably provide:

• exact company headcount;
• a complete organization chart;
• confirmed departures or layoffs;
• a person's private email address;
• an exact-match guarantee for title and location search refinements.

Missing search results are ignored. That is intentional. Public search ranking is too volatile to treat absence as evidence of departure.

The two-snapshot confirmation rule

The first scheduled run creates a baseline and returns the profiles it found. After that:

1. An unseen profile appears once and becomes a candidate.
2. The next complete run finds the same profile again.
3. The Actor returns it with changeType: "new_employee".
4. If the candidate disappears before confirmation, it is dropped without an alert.

Any incomplete or unexpectedly empty company search fails closed. The saved baseline is not replaced by a partial response.

This delays an alert by one schedule interval, but the trade is worth it. Weekly monitoring produces fewer false positives than treating every SERP rotation as a new hire.

Create the monitor

Use company URLs when you have them. Plain company names also work, but ambiguous names can introduce unrelated profiles.

{
  "queries": [
    "https://www.linkedin.com/company/stripe/",
    "https://www.linkedin.com/company/datadog/",
    "https://www.linkedin.com/company/cloudflare/"
  ],
  "mode": "basic",
  "jobTitle": "Sales",
  "maxResults": 100,
  "monitorMode": "new-employees",
  "monitorStoreName": "target-account-sales-hires"
}

Keep monitorStoreName stable between runs. A different name creates a separate baseline. Do not overlap runs that share one store name.

The jobTitle and location inputs refine public search; they are not strict database filters. Review the first baseline before scheduling it.

Schedule it on Apify

Save the input as a Task, then attach a weekly Schedule in Apify Console. The API version looks like this:

import os
import requests

actor = "thirdwatch~linkedin-company-employees-scraper"
token = os.environ["APIFY_TOKEN"]

response = requests.post(
    f"https://api.apify.com/v2/acts/{actor}/run-sync-get-dataset-items",
    params={"token": token},
    json={
        "queries": [
            "https://www.linkedin.com/company/stripe/",
            "https://www.linkedin.com/company/datadog/",
        ],
        "mode": "basic",
        "jobTitle": "Sales",
        "maxResults": 100,
        "monitorMode": "new-employees",
        "monitorStoreName": "target-account-sales-hires",
    },
    timeout=1800,
)
response.raise_for_status()

for person in response.json():
    print(person["sourceCompany"], person["fullName"], person["url"])

The baseline contains changeType: "baseline". Confirmed later additions contain changeType: "new_employee", plus firstSeenAt and confirmedAt.

Route useful alerts, not every alert

A newly visible profile is a research prompt, not proof of a hiring event. A practical workflow adds a short qualification step:

SENIOR_TERMS = (
    "chief", "vp", "vice president", "head", "director", "founder"
)

def is_senior(person):
    title = (person.get("currentTitle") or person.get("headline") or "").lower()
    return any(term in title for term in SENIOR_TERMS)

priority = [person for person in response.json() if is_senior(person)]

For sales intelligence, compare a priority profile with current job openings and a company announcement before changing an account score. For recruiting, verify the current role on the public profile before outreach. For CRM work, match on the canonical LinkedIn URL rather than name alone.

Basic versus Full mode

Basic mode is usually enough for a monitor. It returns the name, profile URL, headline, normalized current role, source company, and observation time.

Full mode attempts public-profile enrichment for work history, education, skills, certifications, languages, location, and other fields LinkedIn exposes anonymously. In a monitor, it enriches only the baseline or confirmed-new rows that will be returned, not the unchanged roster on every schedule. If enrichment fails for a restricted profile, the Actor returns and charges a Basic row instead of pretending the Full data exists.

Use Basic mode for broad watchlists. Run Full mode later on the smaller set of people worth deeper research.

Cost model

Pricing has three transparent events:

Event	FREE	GOLD
Basic profile	$0.003	$0.0015
Full public profile	$0.008	$0.005
Completed company search	$0.020	$0.015

An unchanged monitor still performs the company searches, so the search events apply. It returns no profile rows, which means there is no profile charge for that run.

Common mistakes

Calling the result a headcount

If a run finds 87 profiles, the company does not necessarily have 87 employees. Say "87 public profiles discovered," not "headcount: 87."

Treating disappearance as departure

Search rank, indexing, privacy settings, and profile edits can all remove a result. Confirm departures through another source.

Creating a new baseline every run

Changing monitorStoreName resets state. Keep one name per watchlist and environment.

Scheduling before checking the baseline

Inspect the first dataset for false positives. A precise LinkedIn company URL and a narrower title phrase usually help.

Running overlapping schedules

Two runs writing the same state store can race. Give each watchlist one schedule and wait for a run to finish before starting the next.

Pair it with other public signals

The useful product is rarely "a new LinkedIn profile appeared." It is the combination:

• new employee profile plus several open roles from the LinkedIn Jobs Scraper;
• new senior sales profile plus a recent funding or expansion announcement;
• shortlisted profile plus lawful work-email enrichment from the LinkedIn Email Finder.

That gives a human something worth checking without inventing precision the source cannot support.