How to Enrich Clay Data with Website Change Signals

To enrich Clay data with website change signals, monitor a defined website source with Clay Custom Signals, or schedule an enrichment and save each run to a history table. Keep a stable company identifier, compare each result with the prior result for that company, and route only changes that meet a clear business rule. Clay documents scheduled monitoring and this run-history pattern; the schedule is periodic, not real-time.

A useful signal connects observable evidence to an action. For example: “The company added or materially changed compliance information on its trust center; review the account and notify the security-focused sales owner.” Define the page or evidence, what counts as a change, and the follow-up before you configure the workflow.

1. Define the website change you want to detect

Start with a narrow condition that a teammate can verify. “The website changed” is too broad to guide follow-up. “A trust-center page now lists a new compliance certification” is more actionable. Clay’s Custom Signals guide uses compliance changes as an example.

Source: name the page, section, or website content to monitor.
Evidence: specify the new or changed information that qualifies.
Business meaning: explain why the change matters to your team.
Action: decide who reviews it and what should happen next.

Website access and the shape of a site can affect what a monitoring workflow observes. Treat a signal as a lead for review, not proof that every relevant change will be detected.

2. Choose a Clay monitoring approach

Clay documents two related ways to monitor changes: use a Custom Signal to monitor a website or other digital source on a recurring schedule, or schedule an existing enrichment and compare its outputs over time. [Clay Custom Signals documentation](https://university.clay.com/docs/custom-signals)

Approach	Use it when	What to plan for
Custom Signal monitoring	You want Clay to monitor a website or another source for a defined change on a recurring frequency.	Specify the source, change condition, and follow-up. The documentation does not promise exact-time or real-time detection.
Scheduled enrichment plus run history	You already have an enrichment whose output can reveal the change you care about.	Store each run, retain a stable company identifier, and compare the new output with prior output.

Choose based on the signal and the data you need to preserve, not on an assumed detection speed. The documented workflow does not establish coverage, latency guarantees, or accuracy benchmarks for every site.

3. Build an enrichment run-history table

This pattern preserves recurring outputs so you can compare a company’s current enrichment result with its earlier results. Clay describes scheduling the enrichment, sending its identifier and output to a separate table, retaining a row for each run, and comparing those rows. [Clay Custom Signals documentation](https://university.clay.com/docs/custom-signals)

Prepare the company table. Add the target companies and create the enrichment that produces the information you want to monitor. Choose a stable identifier, such as the company’s domain or name.
Schedule the enrichment. Enable recurring reruns for the enrichment. Clay’s schedule runs every 24 hours from when it was first scheduled; it is frequency-based rather than a selectable clock time.
Write each result to a separate history table. Send the company identifier and enrichment output to that table. Include a creation-time field so the sequence of runs is visible.
Retain one row per run. In the destination table, turn off Update existing rows on re-run. Otherwise, a later run can replace a prior result instead of preserving the history needed for comparison.
Expose the comparison fields. Make the company identifier, enrichment output, and creation time available in the history table.
Look up earlier runs. Use a lookup table or lookup workflow to find prior outputs for the same company identifier, then configure the comparison condition. For numeric outputs, Clay’s guide says to run the change logic when the change is not 0.
Sequence dependent schedules. Match the lookup schedule to the source schedule and leave a short delay between the first table’s scheduled job and the dependent lookup job, so the new history row is available when the comparison runs.

Identifier choice matters. Use the same normalized value on every run. A domain is often a practical key when company names may vary, but the workflow needs whichever identifier is stable in your data. If the identifier changes or is missing, the lookup can treat one company as multiple records or fail to find its earlier output.

Choose a comparison rule that fits the output

Numeric output: compare current and previous values and trigger only when the difference is not zero, as in Clay’s documented numeric example. Add a minimum threshold if small movements do not merit action.
Text output: compare normalized text or use a defined analysis to identify a meaningful difference. Formatting changes, reordered text, and wording edits can create differences without changing the underlying business fact.
Presence or absence: explicitly handle a value appearing, disappearing, or becoming blank. A missing result may mean the source could not be reached, rather than that the company removed the information.
Evidence-based signal: retain the page or evidence summary used to support the signal when your workflow provides it, so a reviewer can assess the change before acting.

4. Turn a change into a useful signal

Clay describes converting an enrichment or AI query into a signal, including Claygent analysis of website content changes. Signals can optionally trigger additional enrichments, such as Slack notifications or Salesforce updates, and broader signal workflows can connect to CRM and other destinations. [Clay Custom Signals documentation](https://university.clay.com/docs/custom-signals) · [Clay signals](https://www.clay.com/signals)

Keep the decision rule explicit. A practical workflow can separate detection from action:

Compare the new and previous results.
Apply a threshold or condition that filters trivial changes.
Send qualifying changes to a review queue or notify the responsible team.
After review, update customer-facing CRM fields or trigger a downstream action when appropriate.

For consequential updates, include human review rather than automatically overwriting customer-facing records. A page change may be ambiguous, temporary, or unrelated to the business fact your team tracks.

5. Account for schedule and data freshness

Clay Custom Signals schedules are periodic: the guide describes runs every 24 hours from initial scheduling, not a user-selected clock time. A dependent lookup should follow the source schedule with a short delay. This workflow should not be treated as real-time monitoring. [Clay Custom Signals documentation](https://university.clay.com/docs/custom-signals)

Freshness also depends on the specific enrichment action. Clay’s Enrich CRM documentation says the following actions search fresh each time: Enrich contact, Reverse email lookup, Find work email, and Get homepage content. It says company firmographics and certain French registry actions can reuse results for up to 30 days; Latest funding, Monthly website traffic, and Website tech stack can reuse results until the end of the calendar month. The same documentation notes that a live technology scan may return no data if it cannot reach the site. These freshness details apply to the named actions in Clay’s Enrich CRM integration; they are not a universal rule for all Clay workflows. [Clay Enrich CRM documentation](https://university.clay.com/docs/enrich-crm)

Before relying on an enrichment for change detection, check the freshness behavior for that specific action. A scheduled workflow cannot reveal a new source result if that action reuses an earlier result during its reuse window.

6. Common problems and fixes

Symptom	Likely cause	What to check
Every run appears to replace the previous result.	The destination is updating existing rows on rerun.	Turn off Update existing rows on re-run in the run-history table so recurring outputs are retained as separate rows.
A company has no prior result to compare.	The identifier is missing, changed, or formatted differently between runs; the initial run may also have no history yet.	Use one stable company name or domain consistently, normalize it, and allow the first run to establish a baseline.
The lookup runs before the new result is present.	The source table and dependent lookup are scheduled too close together or in the wrong order.	Run the source first and add the short scheduling delay recommended in Clay’s guide.
No change is detected although the page changed.	The enrichment may be reusing a recent result, the source may not have been reachable, or the changed content may not be represented in the enrichment output.	Check the freshness rules for that exact action, confirm the monitored source and output, and inspect the result rather than assuming the schedule guarantees a fresh scan.
Too many changes trigger follow-up.	The comparison catches formatting, minor numeric movement, or other noise.	Normalize the output, add a threshold or more specific condition, and route uncertain cases for human review.
A website technology result is empty.	Clay documents that a live technology scan can return no data if it cannot reach the site.	Treat the missing value as unavailable evidence, not proof that the technology or page was removed.

7. Performance, reliability, and cost considerations

Frequency: the documented Custom Signals cadence is every 24 hours from initial scheduling. Plan follow-up expectations around periodic runs, not immediate alerts.
Workflow reliability: preserving one row per run and using a stable identifier makes comparisons auditable. Schedule dependent jobs with a delay, and treat missing or unreachable source data as an unknown state.
Signal quality: narrow conditions and thresholds reduce avoidable review work. Keep the evidence and previous value accessible to the person receiving the alert.
Freshness: action-specific reuse windows can limit how quickly a scheduled enrichment reflects source changes. Confirm the documented behavior for the action you use.
Cost: the research materials do not establish Clay pricing or the cost of this workflow. Check current Clay plan and usage terms before scaling scheduled enrichments or downstream actions; do not assume each scheduled run has the same cost.

8. Or skip the browser setup

If the workflow needs a screenshot as visual evidence, ScreenshotNeo is a website screenshot API and MCP server for developers. It can capture a page as PNG, JPEG, WebP, or PDF. Its screenshot response can help preserve what a page looked like when the signal was reviewed; it does not replace Clay’s comparison and routing logic.

One GET request returns a capture. See the ScreenshotNeo API documentation for parameters and setup.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and responses identify the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan.

Start with 1,000 free screenshots a month, with no card required.

9. FAQ

Can this workflow alert me immediately when a page changes?

The documented Custom Signals schedule is periodic, every 24 hours from when it is first scheduled. The sources do not establish real-time detection.

Should I monitor a company name or its domain?

Use a stable identifier that stays consistent across runs. Clay’s run-history guidance identifies the company name or domain as essential for finding prior results.

Does a changed enrichment result prove the website changed?

No. It indicates the output differs. Review the source evidence and account for freshness behavior, unavailable data, and output noise before taking action.

Can I notify a team or update a CRM after a change?

Clay documents optional follow-up enrichments such as Slack notifications and Salesforce updates. Use a specific signal condition and human review when an automatic update could misstate a customer-facing record.