Clay custom signals for GTM engineers: a buying signal your competitor’s team can’t get

Clay custom signals watch a data source for every row of a Clay table, daily to quarterly, and add a row when the result changes, turning any enrichment into a trigger. Most run on public sources, such as job posts, funding news and website changes, that any team with the same tools can watch. Obsession adds what each account sends its own customers, such as whether its welcome email arrives, as dated facts with the email or screenshot on the same Clay rows.

Clay custom signals are scheduled checks that watch a data source for every company or person in a Clay table and add a row when the result changes. GTM engineers use them to turn any enrichment into a trigger, such as a Slack alert, a CRM update or a step in a sequence. A GTM engineer builds a sales team’s data, automation and routing, and Clay’s own blog describes the role as people who “build revenue engines using AI and automation”.

When Clay launched the feature in May 2025, it told teams to “Track custom signals that your competitors aren’t looking for”. A signal is as rare as the source behind it. Job posts, funding news and website changes are public, so a competitor’s GTM team with the same tools can watch the same accounts for the same change on the same day.

One kind of buying signal sits in no public source: what each account sends its own customers. That covers whether its welcome email arrives, whether its basket reminder still fires after a site change, which platform sends its emails and when its last offer went out. Those facts reach a customer’s inbox and phone, never a page a crawler can read. They matter most to vendors whose product touches those messages. That means email and SMS platforms, loyalty apps, checkout and payments, help desk and AI support, messaging, and identity and onboarding tools.

How Clay custom signals work

As of 11 November 2026, Clay’s Signals docs describe signals as “automated tracking systems that notify you of important changes related to your contacts and target companies”. Every signal starts from a table of the companies or people to watch, with a column holding the identifier the signal reads. News and fundraising reads a company domain, new hires and job postings read a domain or a company profile address, and job changes and promotions read a person’s profile address. The pre-built signals cover:

• Topic intent: companies and people researching the topics you choose.
• New hires, promotions and job changes: people starting, moving up or leaving.
• Job postings: the roles a target company opens.
• News and fundraising: significant events at companies you watch.
• Web intent: the companies visiting your own website, on Growth and Enterprise plans.

A signal runs Quarterly, Monthly, Biweekly, Weekly or Daily, and a new one starts at Monthly. It can’t be set to a specific time. Signals run on Clay credits, charged for each result returned or each record checked depending on the signal, and Clay shows the estimated cost for the chosen cadence before a signal starts. The docs list them on every paid plan except Flex.

Custom signals in Clay

Clay’s custom signals page says they “let you monitor data sources for specific changes on a regular schedule”. It names websites and social media, technology adoption, hiring profiles and new feature rollouts as sources. It also covers compliance changes, such as a company adding GDPR to its trust center, RSS feeds for web mentions and scheduled runs of Clay’s AI tool. Setting one up takes 6 steps:

1. Add it: in a workbook, + Add and then Custom signal; in a table, Actions, Import and then Custom signal.
2. Pick a source to monitor, with Clay’s estimated cost per result beside each one.
3. Configure the source. Some need your own account, and others use one Clay provides.
4. Set how often it runs.
5. Add enrichments if you want them, such as a Slack notification or a Salesforce update that fires when the signal runs.
6. Save it.

Turning any Clay enrichment into a signal

For a change no pre-built signal covers, the same page walks through a pattern of 4 tables:

1. The enrichment table: the companies, the enrichment to watch, and Re-run columns on a schedule turned on. Send table data copies each run to a second table, with Update existing rows on re-run turned off, so every run adds a new row.
2. The run history table: one row per company per run, with its Created At date shown.
3. The lookup table: Lookup Multiple Rows in Other Table pulls each company’s runs, and a Use AI step compares the 2 most recent and returns what’s new, plus true or false. For structured or numerical data, the docs suggest a formula instead.
4. The signal table: rows arrive only when the comparison finds a change, and Created At becomes the time the signal was detected.

A custom signal is a comparison between 2 snapshots of the same enrichment. Scheduled columns run every 24 hours from the moment they were first scheduled, so the docs advise a short gap between the 2 scheduled runs. The signal fires no faster than its schedule, and it sees no more than its enrichment can. If the enrichment reads a public page, the signal is a change to that page, and any team that builds the same 4 tables gets it too.

Where most teams’ Clay signals come from

Most sales teams use similar data, from contact databases and intent tools to Exa’s search of the public web. Clay’s signals page lists dozens of kinds, from job changes, funding and tech stack changes to product usage, website changes, web intent, news, and LinkedIn, YouTube and Reddit activity. It says any of Clay’s 200+ enrichments, or a query to its AI agent, can become one.

Exa’s use case page for GTM teams offers “One company data API for finding accounts, enriching your CRM with cited sources, and tracking signals that win deals”. Its Monitors run searches on a schedule, as often as hourly, for new job postings, funding rounds, leadership changes and product launches. The page lists Clay as an integration through custom API columns. Search starts at $4 per 1,000 Lite searches, with $10 of free credit each month.

These are strong tools for finding accounts and reading what each one publishes, and a team that runs them gets real value from them. Their reach is also their limit for uniqueness: a public source is open to everyone, so a signal built on it reaches every competitor that builds the same check. Obsession vs Exa sets out what each one holds.

Buying signals from what each account sends its customers

Every company that sells online sends its customers a stream of messages after they sign up. That stream includes a welcome series, reminders after a basket or a trial day, texts after an opt-in, offers and codes, and replies from support. None of it is published. Each message reaches one inbox or one phone and changes with the customer’s country, plan and day of trial. A crawler with no account sees none of it, and the history has to be kept the day each message arrives, which makes it point-in-time data nobody can collect later.

For a vendor whose product sits in that stream, these are the buying signals that count, because each one is a dated fact about the problem the product fixes:

• Welcome email stopped or slowed: the last one arrived on Monday, or it now takes 7 hours. It matters to email and SMS platforms and onboarding tools.
• Basket reminder gone quiet: an abandoned cart email that fired before a site change and doesn’t after it. It matters to email, SMS and cart recovery vendors.
• No texts after an opt-in: the account took a phone number and consent, then sent nothing. It matters to SMS and messaging vendors.
• A new sending platform: the platform behind each email, with its sender checked, and the week that changes. The week an account’s emails start coming from a new platform is the week an email platform’s rep calls.
• A new offer or a code that fails: what the account emailed and when, and whether its code worked at checkout. It matters to loyalty, checkout and payments vendors.
• Support slower than its own promise: for example, a 31-hour reply where the help page promises 24. It matters to help desk and AI support vendors.
• A sign-up form that breaks on a phone: the step where it fails, with a screenshot. It matters to identity and onboarding tools.

Buying signals examples sets these beside the familiar ones, with how an SDR opens on each, and sales trigger events gives the play to run for each change.

Clay API enrichment: a domain in, dated facts out

Obsession collects what companies show only to customers, step by step: their screens, emails and texts, member prices, trial limits, quotes and cancel offers, each dated with a screenshot. Teams and AI agents look up any company through the API or MCP, and a company not yet covered is added on request. MCP, the Model Context Protocol, is the standard way AI agents such as Claude call tools. Exa and search APIs like it give agents the public web, what any visitor can read. Obsession gives them what a company shows only to its customers, dated and kept for as long as anyone follows the company, as a column beside the ones a team already runs.

Obsession’s agents have run 1,500 sign-ups, baskets and checkouts at real companies, and counting. Facts reach a Clay table 3 ways, each described on the developer page:

• Pull, row by row. Clay’s HTTP API enrichment adds API data to existing rows, one row at a time, by GET, POST, PUT or DELETE. Point it at Obsession’s facts call with the row’s domain. Keep the key in an HTTP API (Headers) account, which Clay encrypts at the workspace level, and use Field paths to return to pick the fields you map. A conditional run skips rows without a domain.
• Push, as each fact lands. Obsession’s notify call posts each new fact as JSON to a webhook, an address that receives data the moment it is sent. A Clay table started from Monitor webhook gives that address. Clay’s webhook docs cap a webhook source at 50,000 submissions, even after rows are deleted, unless an Enterprise plan turns on Auto-delete.
• Ask, before you build. Claude, ChatGPT, Codex and Cursor call the same 5 verbs over MCP: lookup, facts, evidence, index and notify. A GTM engineer can ask what an account sent its customers this month before wiring a column.

Each fact carries the same fields whichever way it arrives, as the webhook example on the developer page shows:

• company: the domain, such as larkfield.example.
• kind: what the fact is about, such as an email or an offer.
• sentence: the fact in one plain sentence.
• seen_at: when it was seen, as a timestamp with its time zone.
• receipt: the journey it came from, such as welcome or basket, the DKIM result and a link to the raw email or page as captured. DKIM is a signature checked on arrival to prove which company sent an email.

The whole outbound flow on those columns, from a filtered view to the first line of the email, is the Clay prospect research workflow. The signal itself rests on which fields a team keeps and what it does when one changes.

The fields to map, with data quality rules

A signal needs a stable field to compare, so turn each fact into a column with one type and one rule. A starting set for vendors whose product touches their accounts’ customers:

• 3 values, never 2. A yes or no counts once the sign-up is confirmed, the spam folder is checked and the full window has passed. Until then the field reads No verdict, the same rule Prospect intelligence uses before it calls a gap.
• Date the fact, never the run. Write seen_at into the field’s date column, so a re-run doesn’t make an old fact look new.
• Never overwrite with a blank. When an HTTP API column writes on to your CRM, turn on Remove empty fields from request, which Clay’s docs say prevents overwriting existing data with blank values.
• Keep the receipt beside the value. A rep trusts a field they can open, and the link settles a disagreement in one click.

RevOps (revenue operations, the team that owns the CRM and its data) can take the same columns into the CRM. CRM data enrichment fields gives the full field spec, with update rules and the scores each field feeds.

Worked examples by kind of vendor

The same table serves 6 kinds of vendor, each watching the field that maps to what it sells:

Routing a change to the right owner

With a pull column, the change is found the way Clay’s 4-table pattern finds it: compare today’s value with the last one. For a structured field such as Welcome sent or Sending platform, a formula does it, as Clay’s docs advise, and a run condition sends the row on only when the value differs. With the webhook, each fact.created event is already the change, with its date, so the run history and lookup tables aren’t needed.

The last rule protects reply rates and trust. When an account fixes the gap, the field changes back, the run condition pauses the sequence, and no rep opens on a problem that’s gone. Churn risk indicators covers the customer success side of the second rule, and cold email first line examples shows how an SDR writes the opener once a row arrives.

For accounts a team already sells to, Account watch runs the same check every morning. Each change lands on the account’s record in the CRM, with public news and job posts beside it.

Building the signal by hand

A team can collect these facts itself. For each account:

1. Give it its own inbox and phone number, used for that account alone, so every message traces back to one sign-up.
2. Sign up the way a customer would: the newsletter, a text opt-in, a basket left before payment, or a trial if the account sells software.
3. Log every message with the time it arrived, and keep the original email beside the screenshot.
4. Read the sending platform from the headers. The DKIM signature’s d= tag names the domain that signed the email, often the platform’s, and the Received lines show the servers it passed through.
5. Wait out the window before calling anything missing: 48 hours for a basket reminder, 14 days for texts, or whatever your rule says.
6. Write the result to the row, with the date and a link to the evidence.

The work grows with the list. At an example 10 minutes per account per week to check inboxes, log messages and update rows:

The hours are the smaller cost. Sign-ups break when a site changes, a phone number gets flagged, and a missing email can be proved missing only by the inbox it should have reached. By hand suits a few dozen key accounts. Across a few hundred, the column needs a source that stays signed up at every account and dates each message as it lands.

Options for account signals in Clay

We make Obsession, so every other option is described from its provider’s own pages as of 11 November 2026.

Use Obsession for the buying signals that live in customers’ inboxes and phones. It returns what each account sends its own customers as dated fields in the same Clay table, for every account a team names. Use Clay’s pre-built signals for people and company moves, custom signals for changes to pages, posts and filings, and Exa for finding accounts and reading what they publish. They sit side by side on one table, and the sales page shows the same facts behind briefs and battlecards.

How GTM engineers start

Start with the accounts your reps care about most, map 3 or 4 of the fields, and route one change to one owner. Open the sample data to see one real store’s record in every format it comes in, including the columns a sheet or Clay receives. Early access includes API and MCP access, lookups of every company already covered, and up to 5 companies added for you. From there you can see it in conversion rates from the fields your reps use, in data quality and in the adoption of every column your team builds. Sales intelligence from behind the login shows the same view for every role on a revenue team, with an example for each.

Questions about Clay custom signals