Build an Employer Watchlist Without Mixing Agencies and Clients

Define the company roles before you start

An advertiser is the organization presented as posting the job. A recruitment agency is an organization that recruits for a client. The stated end employer is the company that the listing identifies as the employer for the role. These roles can belong to different organizations. One organization can also appear in more than one role.

Keep a separate field for each role. Do not replace an agency name with its client's name. That change would remove evidence about who advertised the role.

A company identity is the public business you have checked behind a name. A company relationship records how two businesses are connected in the evidence. Checking an agency's identity does not confirm its relationship with a particular client.

This distinction matters when several agencies appear to advertise one job. In a public discussion published 7 December 2023, retrieved 25 October 2026; unverified question context, a reader describes agency postings with different pay, engagement wording, and contract lengths. That concern supports checking who makes each claim. It does not establish that the postings concern one opening or identify the employer.

The watchlist answers a narrow question: which named companies appear, in which roles, with what evidence? It does not establish how many people those companies plan to hire.

Save the source fields and your review fields separately

Keep an unchanged copy of the export. Add review notes in a separate working table. Give each source row a reference that lets another reader find it again.

For the Google Jobs Scraper, the checked public build declares these fields. A declared field can still have a missing value where the source or field rules permit it.

A URL is a web page address. An identifier is a value used to refer to a record. Keep `jobId` with the source name and the observation reference. Do not use it as a company identifier.

These fields come from the public default build 0.2.30, checked 25 October 2026; field declarations and static validation only, no live run. The check does not establish data availability, complete coverage, or successful collection.

Create three small review tables. A register is a saved list with stable references. Keep a company register, a relationship table, and a source-row review table.

These are proposed review fields. They are not additional Actor output fields. An Actor is a hosted data collection program.

An alias is another name used for a company. Store an alias with evidence that connects it to the checked identity. A similar spelling is only a reason to investigate.

For each evidence note, retain the page address, the date you checked it, the relevant wording, and the conclusion it supports. Separate identity evidence from relationship evidence. One page may support only one of those conclusions.

Follow eight steps to build the watchlist

1. Preserve each original company label

Copy `companyName` into the source record exactly as supplied. Retain the listing URL, description, and observation time beside it.

If a field is missing, record that state. Do not replace a missing company name with the search phrase or the name of a website that carried the listing. If the URL is missing, retain the import reference and mark the URL as unavailable.

Do not rebuild listing matching during this review. Company identity and job identity are separate decisions. Use the guide to duplicate listings and possible reposts when you need that separate review.

2. Assign roles from explicit wording

Read the company label and the description together. Record which organization appears as advertiser, which acts as recruiter, and which is named as the end employer.

Keep the evidence wording beside each assignment. A description that names a client supports a stated client relationship. It does not independently confirm that relationship.

If the description says only “our client,” leave the employer identity unknown. If the organization’s role is unclear, mark the role unresolved. Do not force every company label into an employer field.

Also preserve `via` as source information. The checked field declaration does not justify treating its value as proof of a recruiter or employer role.

3. Find candidate official company pages

Search manually for the named organization’s official website. Treat each result as a candidate until its content supports the connection.

Check the business name and the locations stated on the site. Compare them with the listing. Read the relevant company, contact, or careers page when available. Record which facts agree and which remain missing.

A familiar name or plausible web address is not enough. Do not treat a website address as proof of a separate legal company. If the public evidence supports only a trading name or brand, describe that public identity without adding a legal claim.

4. Check the company identity and the job reference separately

A requisition reference is an employer’s code for an opening. If one appears in the listing or on an official company page, retain it as a review note. It is not one of the declared output fields used here.

Compare names, locations, and any available requisition reference together. Write down the exact agreement. Also write down conflicts, such as a location that does not agree or an official page that identifies a different business.

An official company page can support the company identity without supporting the advertised role. An official careers page that names the opening can provide more direct evidence about the listing’s employer claim. Keep those conclusions separate.

If you cannot find supporting public evidence, keep the claim unresolved. Lack of a matching page does not prove that the company or job is false.

5. Group only identities that the evidence confirms

Give each checked company one stable `entityRef`. Link a name variation to that reference only when the evidence supports the connection.

Do not combine companies because they share a name. Do not combine an agency with its client. Do not combine several unknown clients into one unnamed company.

If the same name appears in two rows but identity checks remain incomplete, retain candidate references and explain the uncertainty. Name repetition does not establish one unique company.

When you confirm an alias, keep the old label and its source. Another reviewer should be able to see why you connected the labels.

6. Retain each agency-to-client claim

Store the agency and the stated client as separate references in the relationship table. Link that relationship to the listing that supports it.

Do not extend one listing’s client claim to every listing from the agency. A named client in row A does not identify the unnamed client in row B.

Use a small set of review states with clear meanings. For example, “listing claim only” means that the listing supplies the relationship. “Publicly supported” means that you saved separate public evidence for that relationship. “Unresolved” means that the evidence does not support a decision.

These states are analyst choices. They are not claimed Actor classifications. Keep the supporting reason beside every state.

7. Count the units you actually reviewed

Report listing observations, named company candidates, checked company identities, and unresolved client relationships separately. State which unit each count uses.

Do not include an anonymous client in a precise count of known unique employers. That client might already appear elsewhere in the watchlist. You do not have the evidence to decide.

A missing client name is not zero clients. It means that the client identity is unknown. A failed public check is not zero employers. It means that the check did not resolve the question.

Listing volume also does not measure hiring intent. Keep repeated observations and trend analysis in the separate guide to repeated job snapshots.

8. Choose the next check before making an account decision

An account decision is a decision about a company, such as adding it to a research list. Review every unresolved identity or relationship that could change that decision.

Give each unresolved record a specific next check. Examples include checking an official careers page, resolving a conflicting location, or seeking confirmation of a named client relationship.

Keep research candidates separate from publicly supported employer relationships. A watchlist entry can justify more research while its employer claim remains unresolved.

Use the Actor to collect source rows

The manual identity check remains the main method. The Google Jobs Scraper has documented input and output fields that fit the collection part of this work. That fit is not a test of identity accuracy or proof that it completes the watchlist.

A Task is a saved input configuration for an Actor. The Company Hiring Monitor with Google Jobs Task, checked 25 October 2026; page presence only, saved settings and runtime unverified is a starting point. Its exact Task ID is `lc9Xg20bumfb452dl`.

Use this small proposed input:

{
  "market": "US-en",
  "maxItems": 3,
  "queries": ["data analyst"]
}

Replace `data analyst` with the role you want to research. Replace `US-en` with a supported market value if your intended market differs. The supplied value is included in the checked input rules. Keep `maxItems` at 3 for the proposed small test.

The input passed a static check. A static check compares settings with declared input rules without collecting data. No Actor run occurred for this brief. The sample is a proposed replacement input, not a copy of the Task’s current saved settings. The limit of 3 does not promise three returned rows or three employers.

After your own collection, inspect the returned fields before starting identity review. Preserve `status` and `statusReason` as supplied. Do not invent their meanings or treat a saved row as proof of a complete collection.

The method uses public listings and public company pages. It does not require owner-only records, such as private applicant status, inbox messages, or internal hiring approvals. Keep any later private confirmation separate from the public evidence and identify its restricted scope.

Work through an original fictional example

Original fiction for teaching. This is not an Actor run, customer result, or observed company finding.

Three fictional listing observations contain these claims. A, B, and C are teaching labels, not actual source identifiers.

Preserve Birch Talent as advertiser and recruiter for A and B. Preserve North Mill as the stated end employer for A and C. Keep B’s client unknown.

In C, “not stated” does not mean that no recruiter exists. It means that this fictional evidence does not identify one. Likewise, B’s missing client name does not mean that B has no client.

The watchlist has two named entities in different roles, plus one unresolved client relationship. The repeated names provide candidate links for checking. They do not replace official identity checks.

The arithmetic uses these units:

1. Listing observations: 1 for A + 1 for B + 1 for C = 3 observations.
2. Distinct names supplied in the fiction: Birch Talent + North Mill = 2 named entities.
3. Observations naming North Mill as end employer: A + C = 2 observations with an employer claim.
4. Observations with an unnamed client: B = 1 unresolved client relationship.

Do not add 2 named entities and 1 unknown client relationship to report 3 confirmed employers. The quantities describe different things. Birch Talent has an agency role. The unknown client could be North Mill or another organization. The example does not decide that question.

Official identity checks are not supplied in this example. Therefore, a confirmed employer count remains undetermined. Do not fill that gap with zero. No count of employees, vacancies, or completed hires follows from these three observations.

The next review should check the public identities of Birch Talent and North Mill. It should then seek separate support for A’s client claim and retain B as unresolved until evidence identifies its client. Checking North Mill’s identity would not, by itself, confirm either agency relationship.

Check failure states before using the result

Review the full watchlist before you use it for company research.

Never turn a failed check into a claim that a job closed or that a company stopped hiring. Keep old evidence dated. A later page change does not erase what the retained listing said at the observation time.

Keep the scope of the export visible too. A small search is a collection sample. It is not a complete company directory. If you later compare collection sources, use the separate guide to job source coverage rather than treating a longer file as a more accurate employer list.