Competitor activity becomes a Clay enrichment column that names the buyer and the competitor

Competitor activity as a Clay column names the buyer and the competitor

Competitor activity as a Clay column is an enrichment that takes an account domain and returns a confirmed event: a named buyer at that account accepted a reachout from a named competitor. The column reports the buyer, the buyer's role, the competitor, the scenario, the confidence, and the date the activity was observed. Deal Intelligence confirms both sides at 0.95 or higher confidence and refreshes the data daily.

Set that against the signal most Clay tables carry. Intent enrichment returns an anonymous, account-level guess that someone might be researching a topic. This column returns a person you can name and a competitor you can name.

Intent says an account might be looking. Competitor activity says a named buyer accepted a reachout from a named competitor.

That distinction is the whole reason to add the column. A GTM engineer is not enriching for firmographics here. The column is a filter that surfaces the rows where a deal is forming, in play, reopening, or at risk. Read it alongside competitor activity in your accounts.

Clay's built-in competitor data returns market rivals, not evaluations in your accounts

The phrase "Clay competitor data" maps to two existing features, and neither answers which of your accounts is evaluating a competitor. It helps to name both and set them aside.

• Clay's competitor data point. Enrich a company and get its market competitors back: revenue, headcount, parent company, Owler-style firmographics. This describes the rival landscape of a company. It does not say anyone at the account is in a deal with a rival.
• Clay intent signals. Probabilistic, account-level inference piped in from a third party or a website-change webhook. It models that someone at the account might be researching a topic. It does not name the buyer or confirm the competitor.
• Deal Intelligence competitor activity. A confirmed, person-level event. A named buyer accepted a reachout from a named competitor, verified on both sides. This is the evaluation happening in your account.

The first two are useful for what they are. They just answer a different question. For the full breakdown see intent data vs competitor activity.

An HTTP API enrichment column wires Deal Intelligence into Clay directly

The direct route uses Clay's HTTP API enrichment. The account domain already in your table becomes the input, and the returned JSON maps to new columns. A GTM engineer can stand this up in a few steps.

1. Add an enrichment column. On the table, add a column and select the HTTP API enrichment.
2. Point it at the endpoint. Set the request to GET /v1/competitive_activity on the Deal Intelligence REST API.
3. Pass the domain dynamically. Reference the table's domain column as a dynamic value in the query, so each row sends its own account.
4. Store the key at workspace level. Put the API key in a workspace secret and send it as a header, not inline per row.
5. Map the response. Expand the returned JSON and map buyer_name, competitor, scenario, confidence, and observed_date to their own columns.

The column fires per row, so it runs against the accounts already in the table rather than pulling a new list. Most rows return empty, because activity is the exception, not the norm. The rows that return populated are the ones worth a play. See the endpoint shape in verified competitor activity.

Routing through the CRM lets the Clay column read the same fields the rest of GTM uses

The second route reads from the CRM instead of calling the API directly. Deal Intelligence writes custom fields on Account, Contact, and Lead in Salesforce and HubSpot. Clay reads those fields through its CRM source, so the column stays identical to what your Slack alerts and dashboards already show.

• One source of truth. The Clay column reflects the same field the rep sees on the record and the same value that fires the Slack route. Nothing drifts between surfaces.
• No separate key in Clay. The CRM connection already carries the data, so there is no per-table API setup to maintain.
• Consistent scenario tags. The scenario written to the CRM, new_business, open_opportunity, closed_lost_revival, or churn_risk, reads straight into Clay.

Pick the API route for an ad-hoc list that lives only in Clay. Pick the CRM route when the column should match what every other surface shows. For the field definitions, see verified competitor activity.

The Deal Intelligence Clay column returns named buyer, named competitor, role, and date

When a row matches, the column returns a defined set of fields. A GTM engineer maps each one to its own column so the table can filter, route, and sequence on them.

• Buyer name. The named contact at the account who accepted the reachout, not an anonymous session.
• Role. The buyer's title, so a rep knows where in the committee the activity sits.
• Competitor. The named rival who reached the buyer, not a topic inferred from traffic.
• Scenario tag. One of new_business, open_opportunity, closed_lost_revival, or churn_risk, so the row routes to the right play.
• Confidence. Deal Intelligence reports activity at 0.95 or higher confidence.
• Observed date. When the reachout was accepted, refreshed daily so the row stays current.

Those six fields are enough to act without leaving the table. Across Deal Intelligence customers, about 3 percent of monitored accounts show competitor activity in a given month, so the populated rows are a short, specific list rather than a wide net.

Daily refresh keeps the Clay competitor-activity column current without burning the whole table

Deal Intelligence refreshes competitor activity daily. The Clay column reflects new activity on the next pull, whether that pull comes from the HTTP API column or the CRM sync. There is no need to re-run the entire table on a tight loop to stay current.

The operational concern with Clay enrichment is usually credit burn and table-wide refreshes. This column behaves differently because activity is rare by design. About 3 percent of monitored accounts surface activity in a given month, so most rows return empty.

• It is a filter, not a firehose. The empty rows are the expected case. Filter to populated rows and you have your working list.
• Daily is the cadence that matters. A buyer in an active evaluation is moving now, and daily refresh keeps the observed date honest.
• Route the populated rows out. Send the rows that return a competitor to Slack, a sequence, or a Claude query over MCP, so a person acts while the window is open.

From there the column behaves like any other Clay output: filter, route, and sequence. For querying the same data conversationally, see Claude MCP server. Most rows stay empty, and the ones that fill are the ones to work.

Questions, answered.