Your Feature list is how Chameleon knows what your product actually does, and every Agent reads from it. Compass uses it to describe what a user did in terms you recognize and to attribute friction to the right place. Copilot uses it to suggest relevant Experiences instead of generic ones. Prism uses it to personalize around what someone has and hasn't used. It also unlocks a set of targeting filters and user properties you get without any setup.
Chameleon detects your Features from real sessions and suggests a name and description for each. Confirming them is the highest-leverage setup step if you're using Agents, because everything downstream is only as accurate as this list.
👉 Features used to live inside Data Management - Product Context. If you reviewed and confirmed your Features there, nothing changed for you.
Availability & usage
🔓 Available on all plans
🧑💼 Admin and Engineer roles can confirm, edit, reject, and add Features.
📍 Covers your whole product
⚙️ Features in the left navigation
Confirming your features
The page opens in two sections. Features to review come first, with a count of how many are waiting, so you can see at a glance when something needs a look. Confirmed Features sit below it.
Each Feature awaiting review displays a suggested name and description. For each one:
Do this | When |
Confirm | The name and description are right as they are |
Edit (pencil) | It's a real feature, but the description is vague or uses an internal name that your users wouldn't recognize |
Reject (red ✕) | It isn't a feature; a UI fragment, a page section, or something detected in error |
ℹ Editing a Feature that's still waiting for review confirms it in the same step; the button reads Save & Confirm. You don't need to fix the wording and then confirm separately.
Once you review and approve your Features, Agents echo these names back to you in suggestions and session summaries.
Add New covers what detection can't see: a feature behind a flag, something only some users can reach, or a capability that isn't visually obvious. Add a name and a description, and optionally a URL. Anything you add yourself is confirmed straight away, so it won't join the review queue.
🎯 Detection is automatic, but confirmation deliberately isn't. Until you confirm a Feature, Chameleon doesn't use it anywhere. So a full review queue on your first visit is expected, not a backlog you've fallen behind on.
⚠️ Rejecting or removing a Feature can't be undone from the Dashboard. Chameleon stops tracking data for it and for any sub-Features underneath it, and it disappears from menus and filters. If you're unsure, edit the name and description instead.
What each confirmed Feature shows you
Once confirmed, a Feature moves into the Confirmed Features table, with a column for each signal Chameleon has gathered about it:
Column | What it shows |
Research | Microsurveys that asked users about this feature |
In-apps | Experiences tagged to this Feature |
Friction | Friction signals detected on it (requires Compass) |
Sub Features | Smaller capabilities grouped underneath it |
Click any row to open the Feature in detail, with tabs for Overview, Sessions, In-apps, Friction, Research, and Users. You can go from "this is one of our features" to "here's who uses it, who's struggling with it, and what we've shipped for it" without leaving the page.
Sub-features
A large Feature can hold smaller ones underneath it, Dashboards with Filters, Sharing, and Exports, for example. Sub-features let you keep targeting and friction attribution at the level your team actually works at, rather than lumping everything into one name.
To add one, choose Add New, switch the toggle from Feature to Sub-Feature, and pick its parent. Where a feature has sub-Features, the Sub-Features column shows a count you can click to see them.
What a confirmed list enables you to use
Sessions read in your own product's language rather than generic descriptions
Friction is attributed to the right feature, so you know which team it belongs to
Copilot is suggesting Experiences for Features people use
Insights → Sessions and Insights → Friction both filterable by feature, so you can narrow either view to the part of the product you care about
Segments targetable by how people use each Feature
Targeting users based on how they use a Feature
Once a Feature is confirmed, it becomes available in segmentation. Add a Product Features filter, choose is or is not, pick the Feature, and pick a usage pattern:
Pattern | Who it catches |
Power User | Well above average usage |
Regular User | Uses it consistently right now |
Regular User (ever) | Has been a regular user at any point — useful when you care about experience rather than current activity |
Occasional User | Has used it, but infrequently |
Lapsed User | Used to use it, and stopped |
Experienced friction | Their sessions suggest they're struggling with it (requires Compass) |
👉 Lapsed User and Experienced friction are the two most people reach for first: one finds users you're losing on a feature, the other finds users who want it and can't get it to work.
Combine a Feature filter with any other Segment condition to get specific: power users of your reporting Feature, on a Startup plan.
Three properties you get without setting anything up
Every user is automatically assigned three properties based on their session activity. You don't configure anything to get them.
Property | Values | What it tells you |
Product Session frequency | Daily, Weekly, Monthly, Occasional | How often someone comes back |
Product Engagement level | None, Low, Medium, High | How much they do once they're in |
Product Lifecycle stage | Onboarding, Ramping, Established, At Risk, Dormant | Where they are in adopting your product |
These update on their own: someone who was Established and stops logging in moves to At Risk, then Dormant, with nothing from you.
💡 Try targeting At Risk or Dormant users with a re-engagement Tour, or keep an onboarding flow showing only while someone is still Onboarding.
In segmentation, these appear with the names above. In API and webhook payloads, they're prefixed: chameleon_session_frequency, chameleon_features_engagement_level and chameleon_lifecycle_stage.