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
- Rules — Optional instructions the agent must follow whenever it uses this feature (see Rules)
How Features Differ from Other Components
Features are not created through the Context Builder. They come from the Event Catalog’s sync process:- An event is approved in the Event Catalog (with a description)
- The event is synced to the Semantic Catalog
- It becomes a Feature, with its parameters as dimensions
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
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.Rules on Features
A feature can carry Rules — named instructions the agent must follow whenever it uses that feature. So can each of its dimensions: a rule on the feature applies whenever the feature is used, while a rule on one of its dimensions applies to that property and is added from that dimension’s own Rules section. For example, on apurchase_made feature:
Exclude sandbox purchases — “Test-store transactions are present in the data before March 2026. Filter them out for any date range reaching back that far.”
And on that feature’s price dimension:
Price is in cents — “Values are stored in cents. Divide by 100 before presenting an amount.”
Because features are managed live rather than versioned, rules on a feature and on its dimensions are edited directly on the page and take effect immediately — there’s no draft or deploy step. This differs from entities, metrics, and segments, whose rule changes go through the Builder and a versioned release.
See Building Features from the Event Catalog for the full workflow, and Syncing Events to the Semantic Catalog for the sync process details.