A sales research spreadsheet often turns one job advertisement into several rows of apparent demand. The same posting may arrive through two exports, a title update or a repeated collection. Counting those rows as separate vacancies can inflate the reason a company enters the research queue.
Job Posting Buying Signal Extractor groups existing posting evidence by company and a disclosed need category. Its matches come from literal keyword rules in titles and descriptions. The useful output is a research lead with its source evidence, a deduplicated count and a clear distinction between confirmed and inferred posting identity.
Start with an identifiable posting
The example below is a shortened projection of an installed public snapshot. The September posting date is historical evidence. It does not establish that this vacancy is still open or that the employer has approved any purchase.
{
"items": [
{
"jobId": "4419969671",
"jobURL": "https://www.linkedin.com/jobs/view/senior-software-engineer-%E2%80%93-go-golang-at-general-motors-4419969671",
"title": "Senior Software Engineer – Go (Golang)",
"company": "General Motors",
"postedDate": "2026-09-12",
"observedAt": "2026-09-13T15:50:54.556Z"
}
],
"maxInputRows": 100,
"maxResults": 10
}
Keep a stable job identifier or source posting URL whenever the export provides one. A title and company can help describe a posting, but two legitimate jobs can share those values. The installed contract distinguishes confirmed identities from content-derived fallback identities rather than silently treating every repeated row as another hire.
Preserve the matched text
Every useful signal should retain the keyword, the matched field and the source row index. A reviewer can then inspect why a company appeared in the queue. This also lets the team audit a category whose dictionary behaves too broadly for its own market.
Seven fixed need categories cover areas including sales, marketing, data, security, cloud, software and operations. These are disclosed rules, so teams can reason about both matches and omissions. A posting without a dictionary hit may still matter to a person; the absence of a hit does not mean the company has no relevant needs.
Read the counts before the action label
Use confirmedJobCount when reviewing the action recommendation. Preserve inferred counts alongside it. A repeated content-derived record deserves a different review from multiple independently identified postings. The label is a routing suggestion derived from the observed batch, not permission to treat an employer as a ready buyer.
Keep company naming ambiguity visible. The source's company string is useful evidence, but a shared display name does not establish a unique legal entity. If the downstream workflow joins against CRM accounts, make that join an explicit reviewed step with a recorded mapping.
Separate source quality from commercial research
Invalid rows, failed source records and rows with no supported match belong in diagnostics. Retain the summary of what was examined and what was excluded. Otherwise a small output can look like low hiring activity when the actual problem was a missing description field or an input cap.
For a first import, inspect one signal from each category that appears. Check its evidence against the original posting snapshot. Then deduplicate against the research queue using a stable batch and company-category key. Running the transformation again processes the evidence again; it does not provide persistent suppression across your CRM.
The final handoff should include what a researcher should verify next: current vacancy status, the company's own identity and whether the observed role relates to the offered service. None of those questions is answered merely by a keyword match. Keeping that boundary explicit makes a smaller queue more useful than a larger list whose counts cannot be explained.
Price and verification scope
Listing pricing read on 23 October 2026 is $0.012 per result-found event on the FREE tier. The documented unit is: One useful hiring signal delivered with source evidence and a recommended next step. Source errors, invalid rows and budget diagnostics request no result event. Other platform tiers have their own rates. This pricing record has no separate start event. A usable result from an illustrative input can still be billable; inspect the applicable listing and run spending limit before executing it. maxResults is an output cap, separate from the platform's Max total charge option.
This article uses the installed source contract from build 0.1.8 (MjlfUVNW38boKNa4D). The example is a shortened historical source projection, with local pure-transform validation only. No new Apify cloud build or run was started for this article. Local output does not establish cloud delivery, customer acceptance or commercial results.
Inspect the Actor's current input and pricing.
AI-assisted draft; independent technical and cover review is required before publication.
Top comments (0)