How to find buying signals in public data

A buying signal is something a person or company said or did in public that makes a purchase in your category more likely. Not a score. Not a guess. A thing that happened, on a date, at a URL.

That definition is the whole method. Intent data vendors sell a number that says an account is “surging”. You cannot open it, cannot check it, and cannot tell a salesperson what to say about it. A signal with a link can be read, argued with, and quoted.

Rank signals by what they prove

Not all signals are equal, and treating them as equal is how a signal list turns into a spam list. Rank by what the signal actually proves:

Asking to buy. “What is the best tool for X?” in a community, a forum, or a comment thread. This is the strongest public signal there is.
Leaving a competitor. A review or thread explaining why they are switching away from something you replace. They have a budget and a reason.
Hiring for the problem. A job post that names your category, a competitor, or the work your product does. Companies hire before they buy tools for the new hire.
A trigger event. New funding, a launch, a new leader in the buying role, a move into a new market. These create needs; they do not prove one.
Talking about the problem. A complaint or question about the pain itself, with no mention of buying anything.

The top of the list is small and valuable. The bottom is large and useful for something else.

Every signal needs a URL and a date

Write this down as a rule before you collect anything: a signal without a URL is not a signal. It is a memory, or a hallucination, and you cannot tell which.

The date matters just as much. Someone asking for a recommendation last week is a lead. Someone who asked two years ago bought something already. Set a recency window, usually the last week or the last month, and drop anything outside it.

A worked example. Say you sell scheduling software for clinics. A scan turns up:

a thread in a practice managers’ community asking which booking tool handles no-shows, posted this week
a review of a competitor complaining that reminders fail, posted this month
a job post for a “patient experience coordinator” at a clinic group
a blog post about clinic no-show rates, published last year

The first three go in the log, each with its link, its date, and its type. The fourth is outside the window. It might still be a useful source for content, but it is not a signal.

Split demand themes from account signals

Here is the part most teams miss. The same scan produces two different things, and they belong to two different people.

Account signals name a company or a public profile: the clinic group hiring, the reviewer who is leaving a competitor. These go to sales, as a reason to look closer.

Demand themes are what many people are asking, with no single account attached: “no-show reminders fail” came up in a dozen threads across three communities. These go to content. Write the page that answers it, in the words people used.

Over time, the demand themes are worth more. Account signals decay in a week. A theme that keeps appearing tells you what the market wants to read about for the next quarter.

What not to do

Do not scrape behind a login. If the page needs an account to read, it is not public, and the platform’s terms almost certainly forbid it.
Do not guess emails or names. If the source shows a handle, log the handle. An agent that fills in firstname@company.com is making up contact data, and the verifier should fail it.
Do not enrich people from data brokers in the same loop. Keep the log to what the source shows.
Do not auto-send anything. A signal is a reason to look, not permission to message.

Put it on a schedule

The buying-signals template is this guide as a loop: read an ICP file, scan the sources you list, log every signal with its URL and date, and split themes from accounts. Its verifier drops any row whose link does not load or whose date falls outside the window.

If you would rather run it by hand first, the buying-signal-scout skill does one scan on request.

How to research content ideas for a niche, which is where the demand themes go.
How to write a verifier that fails, for the checker that keeps the log honest.