A practical schema for B2B buyer signals

Quick answer: A practical B2B buyer signal schema should answer five questions:

Who is the buyer?

What happened?

What do we know about them?

Does it matter?

What changed?

That requires more than a lead record.

A useful buyer signal event needs separate objects for:

Identity

The person and company behind the activity.

Signal

What actually happened.

Enrichment

The context needed to understand the person and company.

Evaluation

Whether the company fits your ICP, whether the person fits your Persona, and why.

Event context

Whether this is a new buyer, a new signal, or repeat activity.

That separation matters.

If everything gets flattened into name, email, company, page URL, and timestamp, you have stored an event.

You have not built buyer signals infrastructure.

Why a lead record is not a buyer signal schema

Most GTM stacks still represent buyer activity as something close to this:

That works for displaying a contact in a CRM.

It is a poor representation of buyer behavior.

Why?

Because several completely different concepts have been flattened into one row:

Identity.

Company.

Activity.

History.

Fit.

Intent.

Attribution.

Evaluation.

A practical schema should let a system answer these questions independently:

Who is this?

What happened?

What do we know about them?

Do they fit?

Why does this activity matter?

Is this new or repeated behavior?

Where did the buyer first come from?

What happened most recently?

Those are different questions.

They deserve different fields.

Start with one normalized event model

Buyer signals come from many places.

Website activity.

Market intent.

Social engagement.

Forms.

Identity providers.

Enrichment vendors.

Each source naturally produces a different payload.

If you preserve every vendor's native structure all the way downstream, your GTM stack eventually fills up with source-specific logic.

A better approach is to normalize buyer activity into one event model.

Conceptually:

Each object has one job.

buyer tells you who the person is.

company tells you which account they belong to.

signal tells you what happened.

evaluation tells you whether the buyer fits.

first_signal tells you where the journey started.

last_signal tells you what happened most recently.

event_context tells you why this particular event matters now.

That is a much cleaner foundation.

1. Event metadata: what changed?

Every buyer signal should begin with a small event envelope.

For example:

Keep this layer simple.

event_id

A unique identifier for the event.

This is important for webhook retries, deduplication, logging, and replay.

schema_version

Schemas change.

Version them before you need to.

type

The event type should describe what changed.

Examples:

Do not try to encode the entire event inside the event name.

The payload contains the detail.

occurred_at

When the event happened.

This should represent the underlying activity, not simply when a webhook happened to be delivered.

2. event_context: why did this event fire?

This is one of the most useful parts of the schema.

For example:

These fields describe the event at the moment it occurred.

They do not describe permanent properties of the buyer.

is_new_buyer means:

Was this the first time this buyer became known?

is_new_signal means:

Did this event introduce new buyer activity?

is_repeat_signal means:

Does this activity repeat something we have already observed?

That context gives downstream systems a simple way to decide what to do.

For example:

Without event context, every downstream consumer has to reconstruct this logic from history.

That is unnecessary work.

3. buyer: the canonical person

Buyer signals become significantly more useful once activity resolves to one canonical person.

For example:

The most important field here is not the email.

It is the buyer ID.

The same person can appear as:

Those identifiers are observations.

They are not the buyer.

Identity resolution should connect them to one canonical entity:

Otherwise the same person's signal history gets fragmented across multiple records.

Identity confidence should be first-class data

Not every identity resolution has the same certainty.

Some matches are deterministic.

Others are probabilistic.

That difference should survive resolution.

For example:

Why does this matter?

Because these statements are different:

Jane Smith visited pricing.

Jane Smith is likely the person who visited pricing.

Once both become the same CRM contact row, the distinction usually disappears.

It should not.

Every downstream score, workflow, or AI agent is making a decision on top of that identity.

Uncertainty should be represented as data, not hidden as an assumption.

4. company: keep the account separate from the person

The company should be its own object.

For example:

Do not bury company information inside the buyer.

A person and a company are different entities.

People change jobs.

Companies have many buyers.

Signals can exist at the company level even when no individual person has been resolved.

Keeping the objects separate makes account-level intelligence possible.

For example:

How many buyers at Acme are active?

Which Personas at Acme are showing intent?

What was Acme's first signal?

How many signals has the account generated this week?

You cannot model those questions cleanly if person and company are treated as one record.

5. enrichment: what do we know about the buyer?

Identity tells you who.

Enrichment gives you enough context to understand whether that identity is relevant.

Person enrichment can include:

Company enrichment can include:

Why keep enrichment conceptually separate?

Because a resolved identity is not necessarily a qualified buyer.

Imagine two people visit the same pricing page.

Visitor A:

College student
No relevant company

Visitor B:

VP Engineering
800-person software company

The website event may be identical.

The context is not.

Enrichment provides the raw material evaluation needs.

6. signal: what actually happened?

The signal object represents the activity.

For example:

This object answers:

What happened?

Two fields matter particularly:

source

and

type

They are not the same thing.

source

The family of activity.

For 1eye:

type

The specific action.

For example:

Do not collapse every source into one generic intent_event.

Signal type is evidence.

Evaluation logic needs to know what kind of evidence it is evaluating.

Website signals

Website signals can include:

For example:

Keep the raw facts.

Do not reduce the event too early to:

Store:

The URL.

The timestamp.

The duration.

The activity.

Then evaluate what it means.

Facts and interpretation should remain separate.

Market signals

Market signals describe buying activity that may happen completely outside your website.

For example:

Market signals can include:

The surrounding schema does not have to change.

The buyer is still the buyer.

The company is still the company.

The evaluation is still the evaluation.

Only the signal-specific properties change.

That is the benefit of normalization.

Social signals

The same pattern works for social activity.

For example:

Social signals can include:

Again, normalize the structure without flattening away what actually happened.

Signal source should be explicit

This deserves emphasis.

Website, market, and social signals are not interchangeable inputs.

A single blog visit does not carry the same evidence as repeated pricing activity.

A LinkedIn follow does not mean the same thing as category research.

And several independent signals corroborating one another may be more meaningful than any one event.

Your schema must preserve signal source and signal type so evaluation can reason over them differently.

Once ingestion destroys that distinction, evaluation cannot recover it.

7. evaluation: does this buyer matter?

This is where the schema becomes buyer intelligence instead of event storage.

A useful evaluation object should carry the result of reasoning across:

The company.

The person.

The activity.

The surrounding context.

For example:

This answers two fundamentally different questions.

ICP evaluation

Does this company fit who we sell to?

Persona evaluation

Does this person fit who we sell to?

Both matter.

The perfect Persona at the wrong company may not be relevant.

The perfect ICP account with the wrong person may not be actionable.

Buyer intelligence needs both.

Store reasoning, not just scores

A common buyer-signal schema looks like:

What does 92 mean?

Why did the buyer get it?

Which evidence mattered?

Could a rep explain it?

Could an AI agent?

Could an engineer debug it?

Scores can be useful.

Scores without reasoning become black boxes.

A better pattern is:

The reasoning field is not decoration.

It makes the evaluation understandable to humans and usable by AI.

Fit, intent, and readiness are different concepts

Another common mistake is creating one giant intent_score.

That hides several different questions.

Fit

Is this the type of buyer we want?

Intent

Does their activity indicate potential buying interest?

Readiness

Does the activity suggest now may be a useful moment to act?

These concepts can influence one another.

They should not become indistinguishable.

For example:

High fit + low intent

means something very different from:

Low fit + high intent

and:

High fit + high intent + recent activity

A practical schema should preserve those distinctions.

8. Match: connect evaluation to your GTM model

Evaluation determines whether the buyer fits.

Matching tells you exactly where they fit.

For example:

The important part is that the schema stores more than:

It preserves:

Which ICP.

Which Persona.

And why.

That allows the same buyer signal infrastructure to support companies with multiple ICPs and multiple Personas.

Matching and routing are not the same thing

This distinction is useful.

Matching answers:

Which ICP and Persona does this buyer belong to?

Routing answers:

Where should the qualified buyer go?

Do not mix them into one object.

A buyer may match the same ICP and Persona while being routed to several destinations:

HubSpot.

Salesforce.

Slack.

A webhook.

A Target List.

An AI agent.

An ad platform.

Matching describes the buyer.

Routing describes what the system does with the buyer.

Those are different concerns.

9. first_signal: how did the buyer journey begin?

Buyer signals are events.

Buyers accumulate histories.

It is useful to expose the first known signal as part of the current buyer context.

For example:

This answers:

What was the first signal we observed from this buyer?

But there is another important piece:

Attribution.

Attribution belongs to the signal

A buyer should not have one permanent global source.

Real buyer journeys do not work that way.

A buyer might:

First appear through market intent.

Later visit through Google Ads.

Return through organic search.

Then come directly.

So attribution should live with the relevant signal.

For example:

Now the meaning is precise.

Google Ads was the attribution for that signal.

Not a permanent property of Jane Smith.

10. last_signal: what happened most recently?

The last signal provides the other end of the buyer journey.

For example:

Now downstream systems can immediately answer:

How did this buyer first appear?

What did they do most recently?

That provides useful context without forcing every webhook consumer to reconstruct the buyer's full history.

Events and buyer state are different

This is an important architecture principle.

An event describes:

What happened at a particular moment?

State describes:

What is currently true about this buyer?

For example:

That is an event.

That is derived state.

Likewise:

is historical state derived from the event stream.

A practical buyer event can include useful state such as first_signal and last_signal.

But the underlying events should remain immutable.

Do not rewrite history every time the buyer changes.

A complete practical buyer signal schema

Put it together and the event starts to look like this:

The exact fields will vary.

The architecture should not.

Why this schema works

Look at what the event can answer without requiring another system.

Who is the buyer?

Jane Smith.

What company are they at?

Acme.

How certain is the identity?

Deterministic, with confidence preserved.

What happened?

Jane visited Enterprise.

When?

August 31 at 3:05 PM.

Does the company fit?

Yes. Mid-Market ICP.

Does the person fit?

Yes. Engineering Leader Persona.

Why?

The reasoning is attached.

Is this a new buyer?

Yes.

Is this new activity?

Yes.

Where did the journey begin?

Market intent.

What happened most recently?

Enterprise page visit.

That is the difference between an event payload and useful buyer intelligence.

What breaks when the schema skips layers

Every shortcut creates a specific failure mode.

Identity without enrichment

You know Jane Smith visited.

You do not know whether Jane or Acme matters.

Enrichment without signal history

You know Jane is a great buyer.

You do not know why now.

Signal without identity

You know someone visited pricing.

You do not know who.

Identity and signal without evaluation

You know Jane visited pricing.

A human still has to determine whether the activity is worth acting on.

Evaluation without reasoning

You know Jane scored 92.

Nobody knows why.

Evaluation without matching

You know the buyer is relevant.

You do not know which ICP or Persona they belong to.

Matching without routing

You know exactly who the buyer is.

Nothing happens downstream.

Each layer solves a different problem.

Do not collapse them just to save fields.

Preserve facts separately from interpretation

This may be the most important schema principle.

Facts:

Interpretation:

Facts should remain durable.

Interpretation can change.

Your ICP changes.

Your Persona definition changes.

Your scoring model changes.

Your intent model gets better.

But Jane spending 186 seconds on /enterprise at a specific timestamp remains true.

Store the observation separately from the judgment.

That lets you re-evaluate historical events when your models evolve.

Do not flatten the event stream into CRM fields

CRMs naturally want fields like:

Those fields are useful views.

They should not become the source of truth.

For example:

throws away this sequence:

The sequence may be more meaningful than the final field.

Keep the event history.

Derive CRM state from the events.

Not the other way around.

Design the schema to be queried

A practical schema should make important GTM questions easy to answer.

For example:

Which ICP accounts generated signals today?

Which Engineering Leader Personas visited pricing this week?

Which buyers produced both website and market signals?

Which companies have multiple active buyers?

Which buyers returned to the same Target Page?

Which buyers were first seen through market intent and later visited the website?

Which signals came from probabilistically resolved identities?

Which buyers became newly qualified today?

If answering those questions requires bespoke joins across vendor-specific payloads, the schema is working against you.

The goal is not merely to store data.

It is to make buyer context queryable.

Design the schema for AI agents, not only humans

Traditional CRM records were built to be read by reps.

Buyer signal infrastructure increasingly needs to be consumed by software.

Especially AI agents.

An agent needs structured answers to questions like:

Who is this person?

Which company are they at?

How confident are we in the identity?

What just happened?

What happened before?

Does the company match our ICP?

Does the person match a Persona?

Why did they match?

Is the activity new or repeated?

Where did they come from?

What should happen next?

If the agent has to call five APIs and reconstruct all of that before it can act, the buyer signal payload is incomplete.

A good event should carry enough context to make the next decision.

A schema that only renders well in a UI is unfinished

Buyer signals ultimately need to go somewhere.

A qualified buyer may be routed to:

The UI is one consumer.

It should not be the architecture.

The same structured buyer context should be available programmatically so other systems can reason over it.

That means stable IDs.

Predictable objects.

Typed signals.

Explicit timestamps.

Machine-readable evaluation.

Visible reasoning.

Versioned schemas.

And webhook-safe events.

Make the schema additive

The signals you capture today will not be the signals you capture forever.

Today:

Tomorrow you may add:

The entire schema should not need to change.

Keep stable top-level concepts:

Then allow new signal types to extend the model.

Normalize the shape.

Do not erase the differences between sources.

That makes the schema extensible without making it generic to the point of uselessness.

What should not be in a buyer signal schema?

A few anti-patterns are worth avoiding.

One giant intent score

Fit, intent, and readiness are different concepts.

Do not hide all three inside one unexplained number.

Vendor-specific objects everywhere

Normalize vendor data before it becomes your long-term contract.

A global attribution field

Attribution belongs to the event or signal it describes.

Scores without reasoning

If nobody can explain why a score exists, it will eventually stop being trusted.

Mutable historical events

Events should preserve what was true when they happened.

Required fields that do not apply to every signal type

A social signal does not need a page URL.

A website signal does not need an intent topic.

Normalize the architecture, not the facts.

Signal source hidden inside free text

Website, market, and social signals carry different meaning.

Make source explicit and queryable.

The real test: can the event explain itself?

A good buyer signal should be understandable without opening five tabs.

For example:

Jane Smith, VP Engineering at Acme, returned to the Enterprise page. Acme matches the Mid-Market ICP, Jane matches the Engineering Leader Persona, and this is new activity from a buyer first observed through market intent.

That sentence contains:

Identity.

Company.

Signal.

History.

ICP.

Persona.

Event context.

Attribution.

The JSON exists to make that sentence possible.

If your schema cannot explain the buyer that clearly, it probably does not contain enough context yet.

Frequently asked questions

What is a B2B buyer signal schema?

A B2B buyer signal schema is a structured data model for representing buyer identity, company context, activity, enrichment, fit, intent, history, attribution, and evaluation in a consistent format.

It allows buyer activity from different sources to be queried, evaluated, and routed through one common model.

What fields belong in a B2B buyer signal schema?

At minimum, a practical schema should contain:

Event metadata – event ID, type, schema version, timestamp.

Event context – whether the buyer or signal is new or repeated.

Buyer – canonical person identity and identity confidence.

Company – canonical company identity and relevant attributes.

Signal – source, type, timestamp, and source-specific activity.

Evaluation – ICP match, Persona match, and reasoning.

More mature schemas should also preserve first signal, last signal, attribution, history, and evaluation confidence.

What is the difference between a lead record and a buyer signal schema?

A lead record usually represents the current state of a contact.

A buyer signal schema represents what happened, who generated the activity, what context surrounds the buyer, whether they fit, and how the event relates to previous activity.

A lead record is primarily state.

A buyer signal schema preserves events and context.

What are the main types of B2B buyer signals?

Three important categories are:

Website signals – page visits, time spent, repeat visits, Target Pages, clicks, and forms.

Market signals – category research, competitor research, technology research, and account-level buying activity.

Social signals – followers, engagement, comments, reactions, and other social activity.

The schema should preserve the signal source because different types of evidence have different meanings.

Should signal source be a required field?

Yes.

Website, market, and social activity should not be flattened into one indistinguishable event type.

Evaluation logic needs to know what kind of activity occurred in order to interpret it correctly.

What is event context?

Event context describes why the current event matters.

Useful fields include:

These fields let downstream systems understand whether they are seeing a newly identified buyer, new activity from an existing buyer, or repeated behavior.

What is the difference between deterministic and probabilistic identity resolution?

Deterministic resolution uses stronger observed identifiers to connect activity to a known person or company.

Probabilistic resolution infers the most likely identity from available evidence and carries greater uncertainty.

A practical schema should preserve match type and confidence so downstream evaluation can account for that difference.

Why include reasoning in the evaluation object?

A score tells you the result.

Reasoning tells you why.

That matters for sales reps, operators, engineers, and AI agents that need to understand or trust the evaluation.

A schema that stores only scores creates a black box.

Why keep ICP and Persona evaluation separate?

ICP describes whether the company fits.

Persona describes whether the person fits.

A relevant person can work at an irrelevant company, and an ideal company can generate activity from the wrong person.

Both dimensions are necessary to evaluate the buyer properly.

Where should attribution live?

Attribution should live with the signal it describes.

A buyer may first appear through one channel and later return through another.

Storing one global buyer source destroys that history.

Why separate first signal and last signal?

The first signal shows how the buyer journey began.

The last signal shows the buyer's most recent activity.

Together they provide useful context without requiring every downstream consumer to reconstruct the complete event history.

How should buyer signals be delivered downstream?

Buyer signals should be available as structured events through destinations such as CRMs, Target Lists, automation systems, messaging channels, data pipelines, APIs, and webhooks.

The same schema should be usable by both humans and AI agents.

The schema is part of the product

Buyer signals are often treated as a data acquisition problem.

Find more people.

Capture more activity.

Buy more intent data.

But once signals start arriving from multiple sources, acquisition stops being the hardest problem.

The harder problem is making all of that activity mean the same thing downstream.

That is a schema problem.

A practical buyer signal schema connects:

Who

The buyer and company.

What

The signal.

Context

Everything known around the buyer.

Fit

ICP and Persona evaluation.

History

First, last, new, and repeat activity.

Reasoning

Why the buyer matters.

Action

Enough structured context for the next system or agent to decide what to do.

That is the difference between moving buyer data around and building buyer signals infrastructure.