# The Job Alert Query Set, One Role Carried to a Measured Daily Feed

*Write a query set for each job source, collapse duplicates by requisition ID, and measure your feed's weekly precision and miss rate on your own target role.*

- Canonical URL: https://www.refolk.ai/candidates/guides/job-alert-query-set-daily-feed
- Pillar: Applying at volume
- Format: Teardown
- Published: 2026-10-17
- Last reviewed: 2026-10-17
- Reading time: 20 min
- Keywords: how to set up job alerts that are actually relevant, boolean search string for job boards, find jobs on company career pages before linkedin, same job posted on multiple job boards, too many irrelevant job alerts, saved job search filters not working

## Key takeaways

- In Refolk's index, US Product Owner profiles (14,533) are 17.7% of the combined Product Manager plus Product Owner pool, so a query on "product manager" alone misses roughly a fifth of the market by construction.
- A NOT term like junior or intern drops senior postings that mention mentoring junior PMs or managing interns, so every exclusion needs a logged list of the postings it removed.
- Google's after: operator and Greenhouse's updated_at both track the last edit, not the posting date, which is how an old requisition arrives in a daily feed looking new.
- Deduplicate on the ATS job or requisition ID first, fall back to normalized company plus title plus location, and flag the same company and title reappearing within 30 days as a likely repost.
- A 25-posting weekly review carries a margin of about ±19.6 points at 95% confidence, so label about 100 postings, pooled over two weeks if needed, before changing a query.
- If misses cluster in one source, change the source; if false positives cluster on one term, change the query.

This is the build sheet for a job alert feed that sends you only new postings you would actually apply to, written for anyone running a search across many companies at once. I carry one target role, Product Manager in the US, through every revision, including three wrong turns, and finish with a weekly precision and miss-rate check you can run on your own feed. You end with a written query set per source, a duplicate-collapse rule, and a log showing which exclusion terms dropped which qualifying postings.

## What does a working job alert set consist of?

A working alert set is five written artifacts, not a pile of saved searches: a title synonym list, one query string per source, an exclusion log, a duplicate-collapse rule, and a weekly measurement. If you have too many irrelevant job alerts, the cause is almost always that one of these five was never written down.

Four terms carry the rest of the guide:

- **ATS (applicant tracking system):** the software an employer uses to post and manage openings. Greenhouse, Lever and Ashby all publish public job boards.
- **Requisition:** one approved opening inside an ATS, carrying its own ID.
- **Precision:** the fraction of postings your feed returned that you would actually apply to. This is the standard information-retrieval definition from Manning, Raghavan and Schütze's *Introduction to Information Retrieval*.
- **Miss rate:** the share of qualifying postings your feed failed to return. It is one minus recall, where recall is the fraction of relevant items that were retrieved.

The four sources this guide covers are a major job board (Indeed), a networking site (LinkedIn), an aggregator, and Google searches restricted to ATS board domains. Each one honors different syntax, lags the employer by a different amount, and fails in its own way. That is why one string copied across all four never works.

#### The alert build, start to measured feed

1. **Titles** - List 5 to 10 synonyms, each with a pool count
2. **Base query** - One string per source, run once for a baseline count
3. **Exclusions** - Add one term at a time, log what each one dropped
4. **Alerts and ATS searches** - Save daily alerts, run dated site: searches
5. **Dedupe** - Collapse one requisition seen across sources to one row
6. **Measure** - Label a sample for precision, count misses per source

*Every stage produces a written artifact, and the weekly measurement decides which earlier stage gets revised.*

A note on the numbers in the worked case. Posting counts shift by the hour and differ by account and location setting, so I do not print a snapshot of posting counts you could not reproduce. The fixed numbers below are title-pool counts from Refolk's index of professional profiles. Your own posting counts go in the blanks in the templates, and the method is the same either way.

## Which titles belong in the OR group?

The OR group should hold every title employers actually use for the job you would take, each checked against how many people hold it. The first wrong turn in the worked case was running "product manager" alone, which misses roughly a fifth of the market by construction.

Title-holder pools are built from whatever titles employers hand out, so they show you which synonyms the market actually uses. In Refolk's index, 67,698 US profiles carry "Product Manager" in the title and 14,533 carry "Product Owner". The Product Owner pool is 21.5% the size of the Product Manager pool.

**17.7% - US Product Owner share of the combined Product Manager plus Product Owner pool**

In Refolk's index, a query on "product manager" alone structurally excludes this slice of the US title market.

| Title query | Country | Profiles (Refolk's index) | Exact-title share, 25-profile sample |
|---|---|---|---|
| Product Manager | US | 67,698 | 22/25 (88%) |
| Product Manager | UK | 15,778 | 20/25 (80%) |
| Product Owner | US | 14,533 | 16/25 (64%) |

Two derived figures follow from the table. The US Product Manager pool is 4.29x the UK pool. Product Owner is 17.7% of the US combined pool. If you search in the UK, the smaller pool is a reason to cast a wider title net, not a narrower one.

### How to build the list

1. Pull the alternate titles for your occupation from the O*NET Job Titles file. Across O*NET, 59,634 entries (45,472 distinct titles) cover 1,110 occupations, an average of 54 alternate titles per occupation, and most occupations fall between 10 and 100. I did not establish a count for the product-management family specifically, so treat 54 as the scale you should expect, not a target.
2. Shortlist the 5 to 10 titles you would genuinely accept.
3. Check each one's pool size in Refolk's index and write the count next to it.
4. Drop titles with tiny pools unless you know your niche uses them.

**What a pool count proves:** that employers use the title at meaningful scale. **When it lies:** the pool is profiles, not postings, and it is noisy. In the 25-profile Product Owner sample, only 16 held exactly that title; the rest included Founder, CEO and CTO. Treat every pool count as an upper bound on the real title market.

## What syntax does each job source actually honor?

Each source documents a different, partial set of operators, and anything outside that set may be silently ignored. Write each query in the syntax its own source documents, then prove it works by watching the count change.

| Source | Exclusion | Title-field operator | Date control |
|---|---|---|---|
| LinkedIn | NOT (no official + or -) | Title filter (Recruiter) | Not in help docs |
| Indeed | Dash | title: | Not established |
| Google | Minus | intitle: (not in Google help) | before: and after:, on last updated |

What each row means in practice:

- **LinkedIn.** Its only Boolean help page covers Recruiter, where "+" and "-" are not officially supported and LinkedIn says AND and NOT guarantee correct handling. There is no official help page for operators in job-seeker search. Third-party guides say AND, OR, NOT, quotes and parentheses work there, but LinkedIn has not confirmed it.
- **Indeed.** Its help page documents title: (for example title:"product manager"), quotation marks for exact phrases, and a dash before a word to remove it.
- **Google.** Its help documents site:, quotes, minus, and the date operators before: and after:. The after: operator works on documents last updated after a date, not on the date a job was posted.
- **ATS boards.** The public board URL patterns are boards.greenhouse.io/{company} or job-boards.greenhouse.io/{company}, jobs.lever.co/{company}, and jobs.ashbyhq.com/{company}.

Three things are not publicly established, so do not assume them: whether operators carry into saved alerts on LinkedIn or Indeed, whether free accounts have a per-query operator cap, and what operators aggregators support. If your saved job search filters are not working, one of these unknowns is the likeliest culprit.

> **Rule:** No operator counts until the count moves
>
> Before you save any query, change one operator and rerun it. If the result count does not change, the source is ignoring that operator, and your alert is not doing what the string says.

### OR group or separate searches?

Sources disagree. One Indeed guide says to run related titles as separate searches rather than OR-grouping them. LinkedIn's cap of 20 alerts at once pushes you the other way. My rule: group titles where alerts are capped, and split them where they are not, because separate searches show you what each title contributes. Here is the worked case's query set, written to that rule.

**Query set, one target role across four sources**

```
TARGET ROLE: Product Manager, US
TITLE SET: "product manager" | "product owner" | plus 3 to 8 from O*NET, each with a pool count

LINKEDIN (job search box, saved as a daily alert)
v1 (wrong turn): "product manager" NOT junior NOT intern
v3 (kept): ("product manager" OR "product owner") NOT <only terms whose dropped-postings list is empty>
Baseline count: ____  Date: ____

INDEED (one search per title)
Baseline counts: ____ / ____

AGGREGATOR
"product manager"   (add operators only after the count-moves test passes)
Baseline count: ____

GOOGLE, ONE DATED QUERY PER ATS (no space after the colon)
site:boards.greenhouse.io "product manager" after:YYYY-MM-DD
site:job-boards.greenhouse.io "product manager" after:YYYY-MM-DD
site:jobs.lever.co "product manager" after:YYYY-MM-DD
site:jobs.ashbyhq.com "product manager" after:YYYY-MM-DD
Counts: ____ / ____ / ____ / ____
```

*Replace the titles with your own list and YYYY-MM-DD with the date of your previous run; fill every blank count before saving.*

## The build procedure, step by step

The build takes about four hours the first time and 30 to 45 minutes a week after that. The time estimates are mine, not measured. Follow the steps in order, because each one produces the input the next step needs.

#### Building and maintaining the alert feed

1. **Build the title synonym set** - Pull alternate titles from O*NET and check each one's pool in Refolk's index. Done is 5 to 10 titles, each with a pool count. About 30 minutes.
2. **Write the base query per source** - OR group of titles, then AND for required skills, then NOT for exclusions, in each source's documented syntax. Run it and note the result count. About an hour.
3. **Add exclusions one at a time** - Add a single term, rerun, log the count, and read every posting in the difference. Done is every exclusion having a dropped-postings list. About an hour.
4. **Save the alerts** - Save each query as a daily alert and budget against LinkedIn's cap of 20. About 15 minutes.
5. **Run dated ATS site searches** - Run site:{ats-domain} "title" after:{date} for each ATS. Done is one dated query per ATS with its count.
6. **Collapse duplicates** - Key on the ATS requisition or job ID, fall back to normalized company plus title plus location, and flag same company plus title within 30 days.
7. **Run the weekly review** - Hand-label a sample for precision and count misses per source against the pooled union of all sources. 30 to 45 minutes.
8. **Decide whether to change the query or the source** - Misses clustered in one source mean change the source. False positives clustered on one term mean change the query.

### Where the worked case went wrong at step 3

The first LinkedIn string excluded junior and intern, which looks like obvious hygiene for a mid-level search. Running the query with and without NOT junior and reading the difference showed the problem. The excluded postings included senior roles whose descriptions said things like "mentor junior PMs" or "manage interns". Those were exactly the postings the search existed to find.

The 20-alert cap makes this worse. Fewer alerts means longer OR groups, and one NOT term then applies to every title in the group. So one bad exclusion drops qualifying postings for all of them at once. In the worked case the fix was to remove both terms from the full-text query and let the weekly review measure the noise. I would only bring an exclusion back if its dropped-postings list came up empty.

### The 20-alert budget

The LinkedIn cap of 20 alerts per member is documented, and alerts deliver daily or weekly by email, app notification, or both. On mobile, a new alert defaults to daily with both. The platform has not publicly documented whether a single alert email caps its results, or whether filters persist into the alert. Spend the budget on title groups first and locations second, and keep a written list of every saved alert with its exact string, so you can audit it later.

## How do you collapse the same requisition seen across five sources?

Collapse duplicates with an ordered key: the ATS job or requisition ID first, then normalized company plus title plus location when no ID is visible. Then run a separate check for reposts, because the same job posted on multiple job boards and the same job reposted under a new number are different problems.

#### Duplicate-collapse keys, strongest first

1. **ATS job or requisition ID** - Exact match, e.g. a composite key like greenhouse:{board}:{id}
2. **Normalized company + title + location** - Fallback when an aggregator or board strips the ID
3. **Company + title within 30 days** - Repost flag, not an automatic merge
4. **Manual read** - Same text, different number, different city

*Try each key in order and stop at the first one that matches, then run the repost check regardless.*

### Where the IDs come from

Greenhouse's Job Board API gives each job an id, internal_job_id, title, updated_at, requisition_id, location and absolute_url. Its GET endpoints need no authentication. Practitioners build a composite key in the form "greenhouse:{board}:{id}" so IDs from different employers cannot collide. Lever exposes postings at api.lever.co/v0/postings/{company}?mode=json.

> **Tip:** Read the ID off the ATS, not the board
>
> When a networking site or aggregator listing links out to boards.greenhouse.io or jobs.lever.co, the ID in that destination URL is your primary key. Two listings that resolve to the same ATS URL are one requisition.

To normalize the fallback key, lowercase everything and strip legal suffixes from the company name. Strip seniority and level markers from the title only if you search across levels. Reduce location to city, or to "remote".

### Why ID keys and stale detection pull against each other

About 1 in 10 closed postings come back under the same title, in one analysis. If the repost carries a new requisition ID, a strict ID key counts it as new. A company-plus-title key collapses it, but that key also hides a genuine second opening for the same role. So I do not auto-merge on the 30-day check. I flag the match and read it by hand.

### The third wrong turn: aggregator mirrors

In the worked case, the aggregator kept serving requisitions after the employer's own board had dropped them. I do not have a measured figure for how long mirrors lag. One vendor claims networking-site "Just Posted" listings are indexed 18 to 48 hours after the careers page posts, but that is unverified. The structural point is enough to act on. A mirror only learns a job closed when it next re-crawls, and the employer's board is the source of truth. When a posting appears on an aggregator but not on the ATS board, treat it as closed until proven otherwise.

The scale of stale inventory is why this matters:

| Source | Figure | Basis |
|---|---|---|
| Greenhouse | 18 to 22% ghost jobs | Its own platform, per quarter |
| Jobfinder AI | 45% live 90+ days | 79,000 open postings |
| Jobfinder AI | About 10% reposted, same title | Closed postings |
| ResumeUp.AI | 27.4% likely ghost | LinkedIn US listings |

None of these is an official statistic. The Congressional Research Service has said "there are no official statistics on the magnitude of ghost jobs." In one survey of 1,011 US job seekers, 32% said they verify openings on employers' career websites. In my view, that check belongs inside the dedupe step, not left to habit.

## How do you measure precision and miss rate each week?

Precision comes from hand-labeling a sample of your deduplicated feed as apply-worthy or not. Miss rate comes from counting, for each source, the qualifying postings in the pooled union of all sources that this one failed to return. Both numbers need enough labels behind them to mean anything.

### Precision, and why 25 labels are not enough

Relevance judgments are expensive to make, which is the standard warning in information-retrieval evaluation. The temptation is to label a couple of dozen postings and act on the result. The margins below are derived with the normal approximation at 95% confidence and p = 0.5, the worst case.

| Postings labeled | Margin of error |
|---|---|
| 25 | ±19.6 points |
| 50 | ±13.9 points |
| 100 | ±9.8 points |

A ±19.6 point swing is wider than most query edits move precision. So with a 25-posting sample, you cannot tell a real improvement from noise. Label about 100 postings, pooled over two weeks if your feed is small, before you change a query because of precision. No public source recommends a weekly sample size for one person's feed. This is the arithmetic, not a published standard.

Labeling goes faster if you score fit against your own history rather than gut feel. [Refolk](/candidates) scores how well you fit a posting, which gives you a consistent first pass. The label is still yours, though. Overrule the score whenever you would not actually send the application.

### Miss rate, estimated against the pooled union

You cannot know every posting that exists, so estimate misses against everything any of your sources found. Run these steps each week:

1. Deduplicate the week's postings from all sources into one list. This is the pooled union.
2. Mark which ones qualify, using your labels.
3. For each source, count the qualifying postings in the union that it did not return.
4. Divide by the qualifying total to get that source's miss rate.

This undercounts true misses, because a posting no source found is invisible to you. It is still the right number for deciding which source is pulling its weight.

**Weekly feed review log**

```
WEEK OF: ____
Pooled union after dedupe: ____   Qualifying in union: ____
Labeled n: ____   Margin at this n (25 = ±19.6, 50 = ±13.9, 100 = ±9.8): ____

SOURCE              Returned  Labeled  Apply-worthy  Precision  Qualifying missed  Miss rate
LinkedIn alert      ____      ____     ____          ____       ____               ____
Indeed              ____      ____     ____          ____       ____               ____
Aggregator          ____      ____     ____          ____       ____               ____
Google site: ATS    ____      ____     ____          ____       ____               ____

EXCLUSION AUDIT
Term     Count without  Count with  Dropped, read  Qualifying among dropped
____     ____           ____        ____           ____

DEDUPE
Merged by ID: ____  Merged by company+title+location: ____  Repost flags (30 days): ____
Aggregator-only, absent from ATS board: ____

DECISION: change query / change source / hold   REASON: ____
```

*One block per week; if you labeled fewer than 100, carry the counts into next week's block and decide then.*

## Where does an alert build go wrong?

Most failures in an alert build are silent. The feed still arrives every morning, and it looks plausible. Every failure below has a check you can run in a few minutes, and the exclusion check is the one I would never skip.

### NOT junior, NOT intern

- **What happens:** senior postings that say "mentor junior PMs" or "manage interns" are dropped.
- **Why it hides:** the count goes down, which feels like the noise you wanted gone.
- **Check:** run the query with and without the term and read every posting in the difference.

### A title-only OR group that is too short

- **What happens:** a PM-only query misses Product Owner, which is 17.7% of the combined US pool in Refolk's index.
- **Check:** add one synonym and count the new unique postings it brings in after dedupe. If the number is not trivial, the synonym stays.

### Treating after: as the posting date

- **What happens:** after: filters on the date a page was last updated or indexed. Greenhouse similarly exposes updated_at. Editing an old requisition refreshes it on both, and that is how postings live 90 days or more (45% of open ones in one 79,000-posting dataset) reach a daily feed.
- **Check:** read the date on the employer's board itself, or first_published in the API.

> **Watch out:** Updated is not new
>
> A posting that just appeared in your after: search may be months old with a fresh edit. Before you treat anything as new, open the ATS board and read its own date.

### Deduping on requisition ID alone

- **What happens:** the same text reappears under a different requisition number, and an ID key counts it twice.
- **Check:** also match company plus title within 30 days, and read the flagged pairs.

### site: blind spots

- **What happens:** many enterprises disable the public Greenhouse board, host jobs on a vanity careers domain, or embed them in an iframe. None of those appear in a site: search.
- **Check:** for your top target companies, compare the site: results against the company's own careers page once.

### Syntax errors that fail silently

- **What happens:** "site: x" with a space after the colon fails, as Google's own help notes. So do a lowercase "or" and a "-" on LinkedIn. The source returns results anyway, just not the ones you specified.
- **Check:** change the operator and confirm the result count changes.

### Profile-pool noise

- **What happens:** you size a title by its pool and over-invest in it.

**36% - Share of a 25-profile US "Product Owner" sample who were not product owners**

In Refolk's index, 9 of 25 held other titles such as Founder, CEO and CTO, so pool counts are upper bounds.

> An exclusion you have not audited is a filter you have never seen working.

## When do you change the query, and when the source?

Change the source when misses cluster in one source. Change the query when false positives cluster on one term. When neither clusters, hold the setup and keep labeling, because a single noisy week is not evidence.

#### Query or source

Horizontal axis runs from Misses spread across sources to Misses cluster in one source. Vertical axis runs from False positives spread across terms to False positives cluster on one term.

| Quadrant | What it means |
| --- | --- |
| Term problem | Narrow or drop that term, then audit what the change drops |
| Both broken | Fix the query first, then reassess the source next week |
| No signal yet | Hold and pool labels until you reach about 100 |
| Source problem | Replace the source or add a site: search for its gap |

*Where the errors cluster tells you which part of the build to revise.*

Here is how to read your log against the matrix:

- **False positives cluster on one term.** Most rejected postings share a word that pulled them in, such as a second meaning of a skill term. Edit that term only, rerun, and audit the drop.
- **Misses cluster in one source.** For example, the networking-site alert keeps missing postings that the ATS site: searches find. A query edit will not fix a source that has not indexed the posting yet. Lean on the faster source instead.
- **Aggregator-only postings keep turning out closed.** That is a source problem too. Demote the aggregator to a discovery channel and verify against the ATS board every time.

### Keeping the feed current

The syntax rules above describe how the sources work, not permanent values. Re-check them whenever the feed changes character:

- Rerun the count-moves test on each saved query monthly and after any visible change to a search interface.
- Recheck the platforms' help pages for alert limits before rebuilding, since the 20-alert cap is a platform setting.
- Refresh the title set when a new synonym shows up in three or more postings you labeled apply-worthy.

Once the feed is clean, the bottleneck moves downstream to applying. Refolk tailors your resume and drafts the cover letter for each posting that survives the review, so a precise feed turns into applications at the same pace.

#### Before you call the feed done

- [ ] Every title in the set has a pool count written next to it.
- [ ] Every source has one written query string with a dated baseline count.
- [ ] Every query passed the count-moves test after an operator change.
- [ ] Every exclusion term has a dropped-postings list, and no qualifying posting appears on it.
- [ ] Saved LinkedIn alerts are listed with their strings and total 20 or fewer.
- [ ] Each ATS domain you rely on has its own dated site: query.
- [ ] The dedupe rule names its primary key, fallback key, and 30-day repost check.
- [ ] Aggregator-only postings are verified against the employer's board before you apply.
- [ ] The weekly log shows precision with its sample size and margin, and misses per source.
- [ ] The last query change was made on about 100 labels, not 25.

## Frequently asked questions

### Do Boolean operators work in LinkedIn job alerts?

It is not officially established. LinkedIn documents Boolean search only for its Recruiter product, where AND, OR and NOT are supported and "+" and "-" are not. Third-party guides say the same operators work in job-seeker search, but LinkedIn has not published that, and nothing public confirms operators survive into a saved alert. Test it yourself: change one operator and confirm the result count changes before you trust the alert.

### Why does the same job show up on multiple job boards?

Because one requisition on an employer's applicant tracking system gets syndicated or scraped by job boards, networking sites and aggregators, each with its own listing. Collapse them with a key: the ATS job or requisition ID first, then normalized company plus title plus location as a fallback. Also flag the same company and title within 30 days, since reposts often arrive under a new requisition number.

### How do I find jobs on company career pages before LinkedIn?

Search the applicant tracking system boards directly with Google, for example site:jobs.lever.co "product manager" after: followed by a date, and repeat for Greenhouse and Ashby domains. Remember after: filters on last-updated date, not posting date. This misses companies whose boards sit on a vanity careers domain or inside an iframe, so check those companies' careers pages by hand.

### Why are my saved job search filters not working?

Usually a syntax error that fails silently: a space after site:, a lowercase or, or a minus sign on LinkedIn, which does not officially support it. Whether filters persist into saved alerts is not publicly documented by the platforms either. Change one operator, rerun, and check the count moves; if it does not, the operator is being ignored.

### How many postings should I label each week to judge my alerts?

About 100 if you want a precision figure you can act on. At 25 labeled postings the 95% margin is about ±19.6 points, wider than most query edits move precision; at 100 it falls to about ±9.8 points. If your feed is smaller, pool two weeks of labels before deciding to change a query.

### Should I OR my job titles together or run separate searches?

Sources disagree, and the answer depends on the cap. Indeed's guidance suggests running related titles as separate searches, which shows each title's contribution. LinkedIn caps you at 20 alerts, which pushes you toward OR groups. Group where alerts are capped, split where they are not, and remember a NOT term in an OR group applies to every title in it.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/candidates/guides/job-alert-query-set-daily-feed*