Signal schema
A minimal, consistent set of fields for capturing signals so Product, Sales, and Support can act without losing context (source, ICP segment, lifecycle stage, tags, severity, status, and link).
Last updated: December 12, 2025
Definition
A minimal, consistent set of fields for capturing signals so Product, Sales, and Support can act without losing context (source, ICP segment, lifecycle stage, tags, severity, status, and link).
In practice
- Keep the schema small enough that operators can tag every significant thread within 24 hours.
- Reuse schema fields across teams (no “support-only” categories and “growth-only” categories).
Common mistakes
- Over-designing the schema (too many fields means nobody fills it).
- Using free-text-only tagging so signals can’t be clustered or routed reliably.
Related terms
- Shared schema — The cross-functional contract: a shared set of fields and definitions that represent reality consistently across GTM30, without team-specific terminology or parallel tagging systems.
- Entity model — A small, stable set of entities (problems, use cases, roles/personas, industries, etc.) and their fields/relationships that power content, analytics, automation, and LLM retrieval.
- Signal — A meaningful observation from community, ambassadors, support, or content performance (friction, requests, language patterns, objections) that can be tagged, routed, and acted on.
- ICP (ideal customer profile) — A definition of who a message, page, and motion is for — operationalized in GTM30 as shared schema fields used across content, community, and systems.
- Lifecycle stage — Where a customer is in their journey (e.g. awareness → evaluation → activation → retention), used as a shared field to align content, sales plays, and support responses.
- Intent level — A shared signal of how close someone is to action (low/medium/high), inferred from patterns like page types viewed, depth, and CTA behavior — used for routing and prioritization.