If you are asking why a company monitoring feed produces no signals, check whether the source can see the event at all before you touch the query. Ours watched 450 companies for a specific operational change and produced 2 signals a month, and none of that was a search problem.
The client wanted to know when a company on their account list called its people back to the office. The feed read news. News is where that kind of change gets reported, so news is where we looked.
The short version
- A feed watching 450 accounts for return-to-office news produced 2 signals a month.
- We tested the obvious fix first: 60 days of added outlet feeds re-found the same stories and returned zero net-new articles.
- The market was not quiet. Most of those 450 companies are too small for anyone to write about.
- The replacement signal is the company's own job postings shifting from remote to onsite in one city, published weeks before any article and at no new scraping cost.
- That replacement is the design we are building now, not a system with results behind it yet.
We tested the obvious fix before building anything
The obvious fix for a thin feed is more sources, and it is worth 60 days of testing before it becomes a roadmap item. We ran direct publisher feeds beside the existing search query for two months and compared what each one caught.
The added feeds re-found the same stories the existing query already had. Zero net-new articles across the whole comparison window.
That result is more useful than it looks. It says the ceiling is not coverage, and no amount of source expansion inside the same medium will move it.
Insight
Why the monitoring feed produced no signals
A watchlist of mid-size companies will always look quiet in the news, because news coverage tracks company size, not company activity. Across the whole country our feed surfaced roughly 2 to 4 reported events a month, and on inspection that was a fair reading of what had actually been written up rather than a gap in the query.
Nobody writes an article when a 40-person company tells its team to come back in on Tuesdays. The event happens. It just never becomes text on a news site.
So the feed was not broken in the engineering sense. It was correctly measuring a thing that was never going to be the signal.
“The feed was not broken. It was accurately reporting how often journalists write about companies this size.”
The signal the company publishes itself
The replacement source is job postings, because a company announcing a location policy to candidates is publishing the same fact the news would have reported later. When a company's listings for one city move from remote to onsite, that shift is the event.
Three properties make it better than news for this job. It exists for small companies, because every company that hires posts listings. It is first-party, so there is no editorial filter between the event and the record.
And it arrives earlier, because hiring reflects the decision before anyone writes it up.
This is the shape we are building now rather than a system with months of history behind it, so treat the steps as the design and not as a track record.
How the signal is detected
Pull the account's live listings
Same 450-company watchlist, no new scraping cost: the postings were already being collected for other fields.
Bucket by city and work mode
Remote, hybrid, onsite, per location, so a policy change in one office is visible on its own.
Compare against the account's own prior weeks
The signal is the shift inside one company, not an absolute onsite count.
Emit one signal per event
Deduped on the underlying event, not on the record that revealed it.
The comparison is deliberately internal to each account. An absolute onsite count says more about what a company does than about what it just changed, and the client's question was about change.
That last step is there because we already learned it the expensive way on the news version of this feed. Dedup was keyed on the article link, so a single return-to-office decision covered by five outlets became five cards on the client's dashboard. Whatever the source is, the unit that gets deduplicated has to be the event.
Why the comparison came before the rebuild
The sequence matters more than the conclusion. Redirecting a live client feed to a new source is a rebuild, and rebuilds compete with everything else on the roadmap, so the case for one has to be evidence rather than instinct.
Running the added feeds in parallel for 60 days cost close to nothing, because both paths wrote into the same store and the comparison was a query at the end. If that test had returned even a modest number of net-new articles, the correct decision would have been to expand sources and leave the architecture alone.
It returned zero, which is the only result that makes replacing the source the cheaper option. The test was not there to confirm what we suspected. It was there to be allowed to fail.
The honest limit
Job postings are a proxy, and a proxy carries failure modes news does not. A company that is not hiring publishes nothing, so a hiring freeze makes the account invisible no matter what it does with its offices.
Listings also go stale. A posting can sit up for weeks after the policy behind it changed, and a single onsite listing at a mostly-remote company is noise rather than a shift. That is why the rule compares an account against its own prior weeks instead of against a threshold.
The news feed stays in place for exactly this reason. It is no longer the primary source, but it covers the large accounts where coverage is dense and hiring is too noisy to read.
What to take from this
Before you fund more sources, spend two weeks measuring whether your current medium can see the event at all. Take the last 20 real events you know happened and ask how many appeared in the source you are paying for.
If the answer is a small fraction, the volume problem is a visibility problem, and the fix is a different source rather than a bigger one. The best candidates are records the company publishes about itself: listings, filings, pricing pages, careers pages, anything where the subject is the author.
Key takeaways
- A monitoring feed that returns almost nothing is usually reporting the coverage rate of the medium, not the rate of the event.
- Run the cheap parallel comparison before funding more sources: ours returned zero net-new articles in 60 days, which decided the rebuild.
- First-party records like job postings work precisely for the small companies news never writes about, and they land earlier.
- Deduplicate on the event, not on the record that revealed it, or one decision covered by five outlets becomes five alerts.
- Keep the old source for the segment it genuinely covers rather than switching wholesale.
Related reading: what an AI recommendation is worth without its denominator is the same failure shape one layer up, where the measurement itself was capped, and the Google Maps result cap is what it looks like when a source silently limits what it will show you. Mapping which of your operational questions are answerable from the data you already collect is the first thing we do when we work inside a company.
Common questions
Why does our company monitoring feed produce almost no signals?
Usually because the source cannot see the event, not because the event is rare. News coverage only exists for companies large enough to be written about, so a watchlist of mid-size accounts will look quiet even when things are happening.
How do you know whether to add more sources or change the source?
Run the cheap comparison first. We ran 60 days of direct outlet feeds beside the existing query and found zero net-new articles, which told us the ceiling was the medium, not the coverage.
What is a better return-to-office signal than news articles?
Job postings. When a company's listings for one city shift from remote to onsite, the company has published the change itself, usually weeks before any article would exist, and it works for the small companies news never covers.