Building a Signal Taxonomy

Every signal source names things differently: RB2B reports a de-anonymized visit, Koala reports a session, Cognism reports a job change, and a social listener reports a mention. Bolt them together without a shared schema and you get a pile of incompatible events nobody can score consistently. A signal taxonomy is the data model that normalizes all of this into a common vocabulary: a defined set of signal types, sources, and attributes. It is the difference between a warehouse you can query and a junk drawer of integrations.

Treat the taxonomy like a code artifact you own and version, not a spreadsheet that drifts. Define it once, store it in your warehouse alongside HubSpot or Salesforce, and make every channel read from it. This is what lets allbound work: inbound, outbound, paid, and content all reference the same signal language and the same identity graph. Add a new tool, map it into the existing taxonomy, and it instantly speaks to the rest of the stack instead of creating another silo.

Start with a small set of categories: fit, intent, engagement, and lifecycle. Fit covers firmographics from Clearbit or Cognism, intent covers research like topic surges and competitor views, engagement covers direct interaction in Smartlead or Koala, and lifecycle covers stage transitions in your CRM. Under each category, define specific signal types with stable names, so 'pricing_page_view' means the same thing whether it came from Koala or your own analytics. Resist the urge to create a unique type per tool; map tools into shared types instead.

Give every signal a consistent set of attributes: source, timestamp, account, contact, raw payload, and a normalized strength. Those attributes are what make recency weighting, account roll-ups, and routing possible downstream. Keep a clear separation between the raw event you ingest and the normalized signal you store, so you can re-derive signals when you change the schema. A well-attributed event log is what turns marketing into something observable and queryable rather than a black box.

A taxonomy is only useful if it stays consistent, so assign ownership and a change process. New signal types should go through a lightweight review, get a stable name, and be documented before they enter the queue, the same way you would review a schema migration. Without governance, two people add 'demo_request' and 'requested_demo' and your scoring silently splits in half. Version the taxonomy and log every change so you can explain why a score moved.

Plan for deprecation and source churn. A tool like Leadfeeder or Snitcher may change how it fires, or you may swap providers, and the taxonomy should absorb that without breaking downstream scoring. Map each source to its taxonomy types in one place, so replacing a vendor is a remapping rather than a rebuild. Review the taxonomy on a regular cadence, retire dead signal types, and keep it lean enough that the whole team understands the vocabulary.