If you want the overview of where signals sit in a Clay architecture, start with What is Clay?. This article goes deeper: what each signal type actually detects, how to judge whether a signal is worth acting on, and the contract we write before turning one on.
What Clay actually monitors
The four default signals
Clay documents four built-in monitors (Clay docs):
| Signal | What it detects | Why it can matter |
|---|---|---|
| New hires | New hires at target companies within the last three months | A new person owns a problem and has a mandate to change something |
| Promotions | A contact promoted inside their current company | Scope and budget authority just changed |
| Job changes | A contact moving to a new company | Your former champion is now a stranger's prospect — or yours |
| News & fundraising | Significant company events | Capacity to spend, or a public reason to talk |
Setting one up is mechanical: start from a table of companies or contacts that carries professional social URLs or company identifiers, use Actions → Monitor for…, pick the identifier column, set filters and a run frequency, optionally chain enrichments, and save. Clay notes most signals are available on any paid plan, and that you adjust signals by frequency — you cannot pin them to a specific time of day.
Custom signals: the interesting half
Clay's Custom Signals let you monitor websites, social platforms and other digital sources on a schedule, added from a workbook (+ Add → Custom signal) or a table (Actions → Import → Custom signal), and the results can trigger downstream actions such as CRM updates (Clay docs). Clay's marketing page for Signals makes the scope explicit: any Clay enrichment or AI agent query can be turned into a signal (Clay).
That is the sentence worth re-reading. A custom signal means "run this research question on a schedule and tell me when the answer changes." Which turns a Claygent column into a monitor:
- Did this company's site start listing a new location?
- Did the careers page add a role that only exists when a specific problem does?
- Did the pricing page change?
- Did a directory listing switch to a competitor's booking widget?
Those are signals nobody can buy, because they come from your understanding of the market rather than a vendor's dataset. Building them well is a direct application of the Claygent research contract — same rules on output shape, evidence and the "unknown" floor, just running weekly.
One scheduling constraint to design around: Clay's docs state you cannot set a specific time for a scheduled run, and a custom signal runs every 24 hours from when you first schedule it. So the signal's freshness window is a day, not an hour. Anything that needs minutes — an inbound form, a reply — is not a signal problem, it is a speed to lead problem, and it belongs in a workflow tool.
Web intent, and what it costs
Clay's Web intent works the way most visitor-identification tools do: a JavaScript snippet placed before the closing </body> tag (loaded asynchronously so it doesn't block the page), installed directly, through Google Tag Manager, or through Twilio Segment (Clay docs).
Three details from those docs change how you design around it:
- It identifies accounts, not people. Clay tracks company activity; finding the right person at that company is a separate enrichment step. So "a named account read your pricing page" is the real output — never "Maria read your pricing page."
- De-anonymisation has two modes with very different costs. A waterfall stops after the first match; Best Match tests all providers, and Clay's docs say it costs 5–10 times more. Each successful enrichment consumes 1 action plus the provider's data credits, and results are cached for 30 days so the same IP isn't charged repeatedly.
- It can switch itself off. The docs note the connection disables if credit or spend limits are hit, and requires manual re-enabling. If your visitor data goes quiet, check that before you debug the snippet.
The MitHub signal taxonomy
Vendors sort signals by data source. We sort them by what has changed in the buyer's world, because that is what determines the play.
| Type | What changed | Examples | Typical half-life |
|---|---|---|---|
| Relationship | Who you know moved | Job change, promotion, a former customer in a new seat | A quarter |
| Capacity | Their ability to act changed | Funding, expansion, new locations, new leader with a mandate | Weeks to a quarter |
| Process | How they operate changed | Job posts for roles that only exist with your problem, tech stack changes, a new booking or intake tool | Months |
| Behaviour | They came to you | Repeat pricing-page visits, content engagement, product usage | Days |
Two operating consequences. Behaviour signals are the shortest-lived and the highest-value, which is why they deserve the fastest routing and the smallest queue. And relationship signals are the only ones where you already have permission — a champion who has moved knows you, which is a different conversation from cold outbound and should never be run through the same sequence.
Three tests before a signal earns a play
Most "intent data" disappointment comes from acting on signals that never passed these.
1. Relevance — can you state the mechanism in one sentence? Not "they're hiring." "When a lender opens a new branch, one person inherits follow-up for a book they didn't build, and that is the exact moment our system pays for itself." If you cannot write that sentence, the signal is trivia dressed as insight.
2. Precision — of the last 20 times it fired, how many were real? Pull the last 20 firings and grade each one by hand: real opportunity, plausible but wrong, or noise. Under 25% real and the signal is costing your reps more attention than it returns. This is the number nobody measures, and it is the one that decides whether people keep opening the alerts.
3. Half-life — how long is it still true? Store the event date. Let the timing component of your score decay from it. A funding round from last week is a conversation; the same round eighteen months later is a fact about history. If your scoring model treats them the same, your "hot" list is an archive — see lead scoring in Clay for how to keep the timing axis separate so it can decay.
The Signal-to-Play Contract
Before switching a signal on, fill in seven fields. It fits on a Post-it and it is the difference between a monitor and a system.
| Field | Example |
|---|---|
| Signal | New operations leader hired at a target-list account |
| Mechanism | New ops leaders are expected to fix inherited process problems in their first 90 days |
| Claim we can make | Only what is public: the hire itself. Never an inferred problem |
| Play | Research call brief + one call attempt + one email, referencing the public post only |
| Channel & capacity | 15 per rep per week, maximum |
| Owner & SLA | Named rep, contacted within 3 business days of the signal |
| Kill criterion | Reviewed after 20 firings; retired if fewer than 5 produce a conversation |
Two of those fields do most of the work.
"Claim we can make" is a compliance and credibility rule. A signal is evidence for you, not a statement to the prospect. "I saw you're hiring a branch operations manager" is fine, because the post is public. "I saw you're struggling with follow-up" is a guess presented as knowledge, and buyers detect it instantly.
"Kill criterion" is what stops signal sprawl. Signals accumulate — every one ever switched on keeps firing, and nobody removes them, so the alert channel becomes noise. Writing the retirement rule before launch is the only version of this that ever actually happens.
Capacity is the constraint nobody plans for
Signals scale instantly. The humans who act on them do not. A monitor across 3,000 accounts can produce more qualified moments in a week than a three-person team can work in a month, and the failure mode is not too few signals — it is a backlog that makes every signal stale before anyone touches it.
Three ways out, in order of preference: raise the bar (require two signals stacked on the same account within a window before it becomes a play), bundle (one prioritised digest per account per week rather than an alert per event), or add capacity in a channel that scales. MitHub's pioneers have built AI voice campaigns that ran across 28 live branches of a multi-location lending business, including a 10-branch pilot with 13,159 AI calls — the kind of capacity layer that makes a signal backlog workable, and the kind of system design covered in AI voice agents for sales and follow-up.
Whichever you choose, decide it before you turn the signals on. A queue that has already gone stale is very hard to rescue.
What to measure
Signals are easy to run and hard to justify, so instrument them from day one:
- Firings per week, per signal. Sudden spikes usually mean a source changed, not that the market moved.
- Precision, re-graded quarterly on 20 firings.
- Time from signal to first human touch. This is the number that most often explains disappointing results.
- Lift: conversion on signal-triggered accounts versus a matched set without the signal. Without the comparison group you are measuring your best accounts, not your signal.
- Cost per acted-on signal, including the Actions and Data Credits behind it (Clay docs).
If a signal cannot show lift after a quarter, retire it. That is not a failure — it is the scientific loop from Operate working as intended: observe, hypothesise, measure, adjust. The teams that get value from intent data are not the ones with the most monitors. They are the ones who kill monitors on schedule and keep the three that pay.