Attributes Versus Signals

Outcome: your criteria sorted into two lists — attributes with a refresh cadence, signals with a window — and a decision about which one your first build is about.

Surface: App and MCP server
Level: Beginner
Uses: enrich_organization · company_job_listings
Credits: ~5 for the worked example
Prerequisite: Lesson 01's four-question table

The distinction

	Attribute	Signal
Answers	Who could buy	Who might buy now
Shape	A standing fact	An event with a date
Examples	Headcount, industry, country, tech stack, revenue	Raised a round, posted a role, changed jobs, launched a product, visited pricing
Changes	Slowly, over quarters	Once, then decays
Used for	Filtering the universe	Ordering the queue and timing the send
Goes stale by	Drifting quietly	Expiring on a date you can predict

Both are necessary. Attributes without signals give you a correct list with no reason to act on any particular row this week. Signals without attributes give you urgency about companies you cannot sell to.

Why the architecture differs

Attributes are refreshed; signals are detected

You re-check headcount quarterly because it drifted. You check for a funding round weekly because you need to catch it inside a window. The first is maintenance, the second is the job.

Attributes deduplicate; signals accumulate

A company has one headcount. It can have five job posts, two funding rounds and a product launch — and each is separately actionable. This is exactly the event-grain case from lesson 02.

Attributes have no expiry; signals do

“Uses Salesforce” is true until it is not. “Raised a Series B” is a reason to reach out for roughly a quarter and a historical fact after that. Every signal in your build needs a written window.

Attributes gate; signals trigger

An attribute failing means drop the row. A signal missing means not yet — the row stays in the watchlist and is re-checked next run. Confusing these two is why teams delete accounts they should be watching.

Windows

A signal without a window is an attribute in disguise. These are workable defaults; adjust from your own data once you have any.

Signal	Useful window	Why it closes
Funding round	90 days	Money is allocated in the first quarter
New executive hire	30–90 days	The mandate window; also lesson 04 of Job Changes
Job post for a relevant role	30 days	Posts go stale, roles get filled
Champion changed company	90 days	The buying window closes as their plan sets
Product launch	60 days	Attention and budget both move on
Pricing page visit	7 days	Evaluation windows are short
Tech stack change	180 days	Slow to implement, slow to regret

Windows are also your dedupe rule. If the same company posts a matching role twice inside 30 days, that is one signal, not two — otherwise the same account gets sequenced repeatedly for what a human would call one event.

Sorting your own criteria

Run each criterion through one test: can I put a date on it?

“50–500 employees” — no date. Attribute.
“Hired a VP of Sales in the last 60 days” — has a date. Signal.
“Uses HubSpot” — attribute.
“Migrated off HubSpot recently” — signal.
“Has an engineering team” — attribute.
“Is hiring engineers” — signal.

Notice the pairs. Most attributes have a signal twin, and the twin is almost always the more valuable criterion — it carries the same qualification plus a reason to act now. Lesson 01’s “why now” question is asking you to find these twins.

Worked example

The developer-tool build, sorted:

Attributes — refresh quarterly, use to gate

50–500 employees
Engineering org above 20
Uses a competing CI tool

Signals — check weekly, use to trigger and order

Two or more platform/infra roles posted in last 30 days (window: 30 days)
Engineering leader started in role under 90 days ago (window: 90 days)

The attributes define a watchlist of maybe 1,200 companies that changes slowly. The signals decide which 30 of them get worked this week. That split is the pipeline — and it is why the weekly run is affordable, because it only pays for signal checks against a list the attributes already qualified.

Do this now

Split lesson 01’s “who counts” answers into two lists: attributes and signals.
For each attribute, write a refresh cadence — monthly, quarterly, never.
For each signal, write a window in days and a dedupe rule.
For any attribute with an obvious signal twin, add the twin to the signal list. This is usually where the build gets good.
Run one signal check by hand on five known companies — company_job_listings is the cheapest to test with — and confirm the result is dated and recent enough to act on.

Check your work

Every signal has a window in days, written down
Every attribute has a refresh cadence, written down
No item is on both lists
You have at least one signal, or you know your first build is a list build and not a pipeline

Where this breaks

Treating a signal as a permanent attribute is what produces the “we already emailed them about their funding round — eight months ago” problem. Once a signal is stored as a plain true/false column, the window is lost and every future run treats a stale event as fresh. Store the date the signal fired, never just the fact that it did, and compute the window at run time.

Further automation

Signals are the natural thing to schedule. A weekly re-run over an attribute-qualified watchlist, writing only newly-fired signals to a work queue, is the core loop of Signals & ABM. Everything else in this course is in service of making that loop cheap enough to run forever.

Next lesson

06 — Scoring and gating, where the two lists become one number that decides who gets the expensive columns.

Reference for this lesson: Signals, Company, company_job_listings, Signals & ABM.