User Traits
Configure and manage user traits
User traits are the attributes that describe your users in Encatch. You can think of them as columns in a spreadsheet: each trait holds one kind of information (e.g. email, plan, country). Traits are used for segmentation, personalization, and for including user context in feedback responses.
Traits are created in two ways:
- Automatically when you identify users and send data (e.g. via SDK or API), if Allow new traits from clients is enabled for the project.
- Manually in the User Traits table by clicking Create Trait, so you can define traits before connecting a data source or use them in segments.
You can view and manage all traits for a project under User Data → User Traits in the dashboard.
Trait properties
Each trait has the following properties:
| Property | Description |
|---|---|
| Slug | System identifier used in API/SDK and storage. Lowercase letters, numbers, and underscores only (e.g. plan, phone_number). For system-generated traits, the slug cannot be changed. |
| Name | Display name shown in the dashboard (e.g. "Plan", "Phone Number"). You can rename this at any time. |
| Data type | The kind of value the trait holds: Text, Numeric, Datetime, or Boolean. |
| Finite data set | When Yes, the trait is treated as having a limited set of possible values (e.g. plan tier, country). This enables better filter options when building data-driven segments. When No, values are treated as free-form (e.g. name, notes). |
| Include in feedback response | When enabled, this trait is included in feedback response payloads so you can filter or group feedback by it in Reports. A project limit applies (see below). |
Data types
Encatch supports these data types for traits:
- Text – String values (e.g. name, email, free text).
- Numeric – Numbers (e.g. login count, score).
- Datetime – Dates/times (e.g. first seen, last login). Use ISO date format or Unix timestamp when sending via API.
- Boolean – True/false values.
When creating a trait manually, you choose the data type. For traits created from client data (identify calls), the type is inferred from the payload.
System-generated traits
Each project is initialized with a set of system-generated traits. These represent core user and activity metadata:
| Slug | Name | Description |
|---|---|---|
user_name | Username | User's username |
display_name | Display Name | Display name |
email | Email address | |
first_seen_at | First seen at | When the user was first seen |
last_seen_at | Last seen at | When the user was last seen |
feedback_views_count | Feedback Views Count | Number of times the user saw a feedback form |
last_feedback_view | Last Feedback View | When the user last saw a feedback form |
last_feedback_submission | Last Feedback Submission | When the user last submitted feedback |
feedback_response_count | Feedback Response Count | Total number of feedback submissions |
For system-generated traits:
- The slug is fixed (locked) and cannot be changed.
- The name can be edited.
- Finite data set cannot be changed.
- Include in feedback response can be toggled only where the trait is available for feedback response.
- System traits cannot be deleted or disabled.
Allow new traits from clients
At the top of the User Traits page, the Allow new traits from clients option controls whether new traits can be created automatically when user data is sent (e.g. via identify calls from your app or API).
- Enabled – Any attribute you send when identifying a user can create a new trait if it does not already exist.
- Disabled – Only values for existing traits are stored; unknown attributes are ignored. Use this when you want strict control and no new columns from client data.
You can still create traits manually regardless of this setting.
Managing traits
Create a trait
- Go to User Data → User Traits for the project.
- Click Create Trait.
- Enter:
- Slug – Lowercase, letters, numbers, and underscores only. Must be unique in the project (including deleted traits).
- Name – Human-readable label.
- Data type – Text, Numeric, Datetime, or Boolean.
- Finite data set – Yes or No.
- Include in feedback response – Optional; subject to the project limit (see below).
- Click Create.
Rename a trait
Edit the Name field in the table and save. The slug (system identifier) does not change. System-generated traits can be renamed; only the display name is updated.
Change finite data set
For custom (non–system-generated) traits, use the Finite Data dropdown in the table and save. System-generated traits do not allow this change.
Include in feedback response
Use the Feedback Response checkbox for each trait to include it in feedback response payloads. This is useful for filtering or grouping feedback in Reports.
- A maximum number of traits per project can be included in the feedback response (e.g. 25). Once the limit is reached, you must uncheck another trait before checking a new one.
- Some system traits may not be available for feedback response.
Usage information
The In Use column shows whether a trait is referenced in:
- Segments – Used in segment filters.
- Feedback – Used in feedback-related configuration.
Click the usage indicator to see details. Traits that are in use cannot be disabled or deleted until they are removed from those usages.
Disable a trait
For traits that support it, use the Pause (disable) action. Disabled traits are ignored for new incoming data and are not shown in some parts of the dashboard. System-generated traits and traits that are in use cannot be disabled. Use Play to enable again.
Delete a trait
Use the Delete action for custom traits that are not in use. Deleting removes the trait from the project; if new data later arrives with the same slug (and new traits from clients are allowed), a trait with that slug can be created again. System-generated traits cannot be deleted.
Feedback response limit
Only a limited number of traits per project can be marked as Include in feedback response (for example, 25). This keeps response payloads manageable and performant. Choose the traits that are most useful for filtering and reporting. You can change which traits are included at any time within the limit.
Best practices
- Slugs: Use clear, stable slugs (e.g.
plan,country,signup_date). Avoid changing them in your app after traits are in use. - Finite data: Mark traits with a fixed set of values (e.g. plan, role, country) as Finite data set so segment filters work better.
- Allow new traits: Turn Allow new traits from clients off if you want to restrict which attributes are stored and avoid accidental trait proliferation.
- Feedback response: Only include traits you actually need in reports and integrations to stay within the feedback response limit.