Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.clarityq.ai/llms.txt

Use this file to discover all available pages before exploring further.

A feature represents a tracked product event that has been promoted from the Event Catalog into the Semantic Catalog. Events like signup_completed, purchase_made, or level_finished become features once synced, making them available to the agent for answering questions.

​
What a Feature Contains

Each feature has:
  • Name — Derived from the event name
  • Description — Carried over from the event’s approved description in the Event Catalog
  • Dimensions — The event’s parameters and user properties, each becoming a dimension that can be used for filtering and grouping

​
How Features Differ from Other Components

Features are not created through the Context Builder. They come from the Event Catalog’s sync process:
  1. An event is approved in the Event Catalog (with a description)
  2. The event is synced to the Semantic Catalog
  3. It becomes a Feature, with its parameters as dimensions
This is different from entities (built from the Table Catalog), metrics (built in the Builder), and segments (built in the Builder).

​
Why Features Exist Alongside the Event Catalog

The Event Catalog and Features serve different purposes. The Event Catalog is a discovery and documentation tool — it catalogs every event your product tracks, helps you describe and approve them, and keeps up with new events as they ship. But the agent doesn’t query the Event Catalog directly when answering questions. It works with the Semantic Catalog. Features are the bridge: they promote approved events from the Event Catalog into the Semantic Catalog, where the agent can find them, understand their parameters as dimensions, and use them in SQL queries. Beyond that, events in the Event Catalog are raw — they only contain parameters and user properties as they arrive from your tracking implementation. The underlying events table is often messy, with implementation quirks, naming inconsistencies, and data quality issues. Features are the modeled, clean version of those events. When an event becomes a Feature:
  • Implementation errors are corrected
  • Only the relevant data is included — noise is stripped away
  • Full SQL definitions explain how to query the event correctly
  • Descriptions provide business context on what the event means and when it fires
  • You can add dimensions beyond just the event’s parameters — from table columns or custom definitions
Think of the Event Catalog as the source of truth for what events exist, and Features as the curated, queryable versions the agent actually uses.

​
How the Agent Uses Features

When someone asks about user behavior — “how many users completed signup last week?” or “what are the top events by volume?” — the agent finds the relevant feature and uses it to build the query. The feature’s dimensions allow breakdowns like “signups by platform” or “purchases filtered to premium plan”.

​
Keeping Features Current

Once an event is synced, new parameters and user properties are added as dimensions automatically as they’re approved in the Event Catalog. You don’t need to re-sync the parent event. See Building Features from the Event Catalog for the full workflow, and Syncing Events to the Semantic Catalog for the sync process details.