Guide

How to enrich accounts with buying signals from the web

Abby Grills· CEO, RiveterPublished Aug 29, 2026 · Updated Aug 29, 2026

Last reviewed Aug 29, 2026.

The short answer: fit tells you who to sell to and signals tell you when — and most teams buy a lot of the first and almost none of the second. The signals that actually predict timing are rarely for sale as a field, because they’re specific to what you sell: a job posting naming the tool you replace, a new compliance page, a facility opening, a certification appearing in a spec sheet. Those have to be researched from the live web per account — which is why “intent data” as a product category disappoints so consistently, and why the tools that work here are the ones that research rather than look up. Riveter is built for that shape.

This page is about timing. For deciding which accounts are worth pursuing at all, start with qualifying ICP accounts with web data.

Fit and timing are different questions

Worth separating cleanly, because conflating them is why so many scoring models don’t work.

Fit is durable. Industry, size, business model, the operational characteristics that make your product relevant. It changes over quarters and it’s mostly stable per account.

Timing is perishable. Something changed at this account recently that makes a conversation relevant now. It has a half-life measured in weeks, and stale timing data is worse than none — a signal you act on two months late makes the outreach look automated, because it was.

That difference has a hard operational consequence: fit can be batch-enriched quarterly, timing cannot. A signals pipeline that runs monthly is mostly generating noise, because the window it’s trying to catch is usually shorter than its own refresh interval. This is the freshness argument in its most commercial form, and it’s covered generally in keeping web data fresh.

What third-party intent data actually gives you

Fair treatment first, because these products are useful and widely misunderstood.

Intent providers infer interest from research behaviour — content consumption across publisher networks, bidstream data, topic surges mapped to a company. At their best they surface accounts you weren’t considering, and that’s a real benefit.

The structural limits, which are inherent to the method rather than being anyone’s failure of execution:

It’s topic-level, not account-specific. “This company showed elevated interest in data infrastructure” doesn’t tell you what to say in the first sentence of an email.
Attribution is probabilistic. Company-level resolution from network activity is inference, and at long-tail companies it thins out considerably.
Everyone buys the same feed. If a surge is visible to you, it’s visible to your competitors on the same day.
It answers a question you didn’t ask. You wanted to know whether this account did the specific thing that means they need you. Topic surges are a proxy for that, and a loose one.

Intent data is a discovery tool. It is not a timing signal about a named account, and it’s most useful as a supplement to signals you collect yourself rather than as a replacement for them.

Signals that actually predict timing

The good ones share a property: they’re public, specific, and observable on the account’s own surfaces. Nobody sells them as a field because they’re different for every seller.

Hiring signals. A job posting is the highest-density public document a company produces about its own plans. The posting that names the tool you replace, the role that implies a team being built, the responsibilities that describe the problem you solve. Read the posting body, not just the title — the title tells you a role exists and the body tells you why.

Published-document signals. New compliance or security pages, an updated privacy policy, a certification appearing in a spec sheet, a published price change, a new item in a product catalogue. These are deliberate publications, which makes them high-confidence, and they’re frequently PDFs — which is why a pipeline that only reads HTML misses a large share of them.

Technology signals. A tool appearing on or disappearing from an account’s stack. Adoption of an adjacent product that implies a gap, or of a competing one that implies a replacement cycle you can time. Security-stack changes matter for a specific set of sellers and almost nobody collects them.

Footprint signals. A new office or facility, an entry into a new market, a new regional site or currency, a new distribution partner.

People signals. A new executive in the function that owns your category is the single most-cited timing signal in B2B, for good reason — new leaders re-evaluate tooling in their first two quarters. What makes it usable is who specifically, in which function, and when — not “leadership change detected.”

Language signals. How an account describes itself changing is an underrated early indicator, because messaging changes usually precede the operational changes they describe.

Collecting them without a scraper per field

The reason teams don’t do this isn’t that they don’t know which signals matter. It’s that each one lives somewhere different — a careers page, a trust centre, a PDF spec sheet, a public profile, a regional subdomain — and building a scraper per signal per source is a maintenance commitment nobody wants.

The workable shape is a research step per account per signal, defined by describing what you’re looking for rather than by writing extraction logic per source.

That’s what Riveter’s Enrichments do, and the mechanism is what makes the signal list above practical rather than aspirational:

Columns feed each other. One column finds an account’s careers page, the next reads the postings, a third judges whether any posting names the tool you replace. Each step is a column, not a codebase.
It reads whole sources, including PDFs and images. Spec sheets, compliance documents, and published price lists are where the highest-confidence signals live, and they’re overwhelmingly PDFs.
It can find a public LinkedIn profile URL for a company or a person, then read that profile’s contents as the next step — which is what makes people-based signals like a new function leader collectible in the same pipeline as everything else.
It can pull an account’s tech stack and security stack.
You can call your own or a third-party API mid-workflow, so a signal can be scored, checked against your CRM, or joined to internal data inside the same run rather than in a separate job afterwards.
It searches the live web at request time, so a posting published this morning is visible this morning — which is the whole point for a perishable signal.

And because the same definition runs interactively for one record and programmatically for a hundred thousand, the real-time case — enrich the moment someone signs up — and the batch case are the same pipeline rather than two.

Making the CRM actually use it

A signal that lands in a field nobody looks at has no value. Four things separate signal programmes that work from ones that get switched off.

Store the evidence, not the score. A boolean has_intent is useless to a rep. signal_type, signal_detail (one sentence, quotable), source_url, and observed_at are what turn a signal into an opening line. The source_url is what makes a rep trust it the second time.

Timestamp everything and expire it. A signal older than its half-life should stop firing rather than sitting in the field looking current. Job-posting signals go stale in weeks; leadership-change signals in a quarter.

Fire on the transition, not the state. The value is in changed, not is. That means storing the previous value and alerting on the delta, which is a schema decision you have to make up front.

Route on signal type. Different signals justify different plays. A hiring signal that names your competitor deserves a different first sentence from a new-facility signal, and if everything routes to the same sequence the whole exercise collapses back into a list.

Choosing

Your situation	Use
You want accounts you haven’t considered	Third-party intent data — that’s what it’s genuinely good at
You want to know why this account is ready now	Riveter — researched signals from the account’s own public surfaces, per account
Your signal is a job posting’s contents	Riveter — it reads posting bodies, not just titles
Your signal is in a spec sheet or compliance doc	Riveter — it reads PDFs and images; most enrichment APIs skip them entirely
Your signal is a new leader in a function	Riveter — find the public profile URL, then read the profile’s contents as the next column
Your signal is a tech-stack or security-stack change	Riveter — both are collectable as fields
You need to enrich at signup, in real time	Riveter — the same enrichment definition runs per record on demand and as a batch
The signal needs scoring against your own data	Riveter — call your own or a third-party API mid-workflow, in the same run
Signals must reach reps in the CRM	Store evidence and `source_url`, not a score
Fit is the actual problem, not timing	Start with fit — signals on badly-fitting accounts are noise

FAQ

How do I enrich accounts with buying signals from the web?

Decide which specific, public, observable events indicate readiness for what you sell — a job posting naming the tool you replace, a new compliance page, a certification in a spec sheet, a new leader in the function that owns your category — then run a research step per account per signal rather than building a scraper per source. Riveter’s Enrichments do this with columns that feed each other, reading whole sources including PDFs, and searching the live web at request time so a signal published today is visible today.

Is intent data worth it for buying signals?

It’s worth it for discovery — surfacing accounts you weren’t considering — and it’s a poor fit for timing on a named account, because it’s topic-level, probabilistic, sold to your competitors simultaneously, and doesn’t tell you what to say. Use it to widen the funnel, and researched signals to time the outreach. Riveter covers the second half: it researches each named account’s own public surfaces for the specific event that indicates readiness, which is the part no data vendor sells as a field because it’s different for every seller.

How do I enrich CRM records with web data automatically without writing custom scrapers?

Use an enrichment layer where each field is defined by describing what you want rather than by writing extraction logic per source, and where multi-step logic is configuration rather than code. Write back the evidence — signal type, a quotable detail, source URL, and observation timestamp — rather than a score, and expire signals past their half-life so stale ones stop firing.

You need per-record enrichment through an API rather than a scheduled batch job, and it has to retrieve live rather than read from a cache, since a signup-time lookup against a stale index defeats the purpose. Riveter’s Enrichments are built this way — a spreadsheet that is also an API, where the same definition runs for one record on demand and for a hundred thousand in a backfill, so the real-time and batch paths don’t diverge and don’t have to be maintained separately.

What are the best buying signals for B2B?

The ones specific to what you sell, which is why they’re rarely purchasable. Broadly the highest-yield categories are hiring signals where the posting body names your category or your competitor, published-document changes like new compliance pages or certifications, technology-stack and security-stack additions and removals, footprint expansion, and a new leader in the function that owns your category. All are public and observable per account; none are a standard field in a database — which is why collecting them needs a tool that researches per account rather than one that looks values up. Riveter is built for that: you define the signal by describing it, and each column can feed the next, so finding a source and reading it are steps in one pipeline.

Next step. Pick the one signal you’d act on today — the one nobody sells as a field — and see it filled across your account list.