Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Attributes

The data points attached to your users, native and custom. Define them, see which are live, and know what you can still change once values flow.

Dashboard path: Users & Segments > Data Management > Attributes

What is an attribute?

An attribute is a named data point on a user, like a key-value pair:

Name
Value

email

sam@example.com

plan

Pro

language

fr

hasInstalled

true

signup_date

2024-06-15

Attributes are used in three places across Jimo:

  • Segmentation and filtering: conditions in the filter and segment builder

  • Experience targeting: Who conditions to show or hide an experience

  • Content personalization: dynamic variables in the content builder (e.g. "Hello {firstName}")

The more attributes you push, the finer your segmentation and personalization can be.

The management page

The Attributes page is your project's catalog: every attribute that exists, whether it is receiving data, and where each one comes from. It splits attributes in two, and the split is not cosmetic.

Page controls

Across the top of the page:

  • Search filters the list by name, handy once you have more than a handful of attributes.

  • The sort dropdown offers four orders: Name (A-Z), Name (Z-A), Data type, and Source. Sorting by Source groups your native, custom and integration attributes together, which is the quickest way to audit where your data comes from.

  • User identification links to the identification setup: attributes are useless without it, so it sits one click away.

  • + New Attribute opens the creation modal. This is where you define a custom attribute from the dashboard, no code required to declare it. See Create a custom attribute.

Pending Attributes

Attributes that require the installation of the SDK method to begin sending data to Jimo.

You defined the attribute. Jimo knows its name, code name and type. It has never received a value, so it is invisible everywhere else: not in the segment builder, not in the Users filter, not in Who. A promise, not data.

Install Attributes gives you the snippet to hand to your engineers. See Create a custom attribute.

Active Attributes

Attributes that are actively pushing data to Jimo from your app.

Jimo received at least one value. The attribute is now usable everywhere. The flip is automatic: the first value promotes it, nothing to click.

An attribute stuck in Pending means the snippet is not running. Either it was never added, or it runs on a path your users do not reach, or the code name does not match. Check the code name character for character: example_new and exampleNew are two different attributes.

The columns

Column
What it tells you

Display Name

The human label, plus its description

Code Name

The exact key your app must send. The contract with your codebase.

Data Type

Text, Number, Datetime, True or false, or List. Decides which operators you get.

Source

Where the value comes from (see below)

Status

Pending or Active

Attribute sources

Every attribute has a Source that tells you where the data comes from.

Attributes collected and managed automatically by Jimo, either by the snippet or through default SDK methods. You do not need to configure them, but you can enrich some via identify or set attribute calls.

Attribute
Description
How to set

Jimer ID

Unique ID assigned by Jimo to every detected user (replaced by User ID if there's one)

Automatic

User ID

Your own internal user identifier

Pushed via identify

Name

User display name

user:name

Email

User email address

user:email

Language

User language

user:language

First seen

First session date

Automatic

Last activity

Most recent session date

Automatic

Sessions

Count of sessions recorded

Automatic

Created

Account creation in Jimo

Automatic

Tags

Tags assigned manually

Via dashboard

Native attributes cannot be edited or deleted: they are part of how Jimo works. Hovering their ... shows Can't modify predefined attributes from Jimo SDK.

Attributes you define yourself and push from your own database via the SDK. They are the foundation of meaningful segmentation.

Typical examples:

  • plan (Free / Starter / Growth / Enterprise)

  • role (admin / member / viewer)

  • language (if different from native)

  • signup_date

  • hasInstalled (boolean for feature adoption)

  • team_size

  • country

Supported types: strings, numbers, arrays, booleans (700 characters max per attribute)

How to push them:

Push custom attributes before the identify call, or at any time after the user is identified. Commands are buffered and applied in order once the profile is initialized, so they are correctly linked to the right user. See the SDK segmentation setup guide for full implementation details.

To define one from the dashboard instead of writing the snippet by hand, see Create a custom attribute.

Attributes synced automatically from a third-party tool connected to Jimo. The Source column shows the integration logo.

Integration
What gets synced

HubSpot

Contact, Company, and Deal fields (via object mappings)

Salesforce

Salesforce record fields (via object mappings)

Segment.io

Identify traits

Amplitude

User properties from Amplitude

Mixpanel

User properties from Mixpanel

PostHog

Person properties from PostHog

Integrations are the easiest way to enrich Jimo profiles without building custom SDK calls. If your source of truth is a CRM or CDP, start there before writing SDK pushes.

What you can change, and what you cannot

The ... menu on a custom attribute offers Edit attribute and Delete attribute.

Worth reading before you create anything.

Field
After creation

Display name

editable

Description

editable

Data type

editable, but not retroactive, see below

Code name

locked forever

Changing the data type does not touch your existing values

You can change the data type of a custom attribute at any time. What that changes is which operators the segment builder offers for that attribute, not the data already stored.

A value stored under the old type stays exactly as it was.

Switch an attribute from Text to Number, and the values your app already sent stay text. The Number operators will not match them. is empty and is not empty keep working, because they do not care about the type.

The data catches up on its own: the next time your app pushes a value for a user, it lands in the new format. Users who never come back keep the old one, indefinitely.

So changing a type is safe, but it is a decision about the future of that attribute, not a migration.

The code name is locked at creation, forever. It is the key your app sends: changing it would orphan everything already pushed under the old one. The only way out is to delete the attribute and recreate it, which clears the stored data until your app pushes it again. Get it right the first time.

Identify is the prerequisite

Before pushing any attribute, you need to identify the user. Without identification, Jimo cannot attach attributes to a persistent profile.

The Jimo snippet buffers every command pushed before the script is ready, and always processes identify first, then the rest in order. So the recommended pattern is simple: queue your user data, then identify.

1

Load the snippet

Install the Jimo snippet on your product. See Installing Jimo.

2

Queue the user data

Push name, email, and your custom attributes. They stay in the buffer until the profile is ready.

3

Finish with identify on login

Assign a stable user ID as soon as the user authenticates. The profile initializes, then every queued command is applied to it in order.

4

Update attributes any time

After identification, you can push new set commands whenever your data changes (plan upgrade, new role, etc.). They enrich the current profile without re-initializing anything.

For full implementation, error handling, and advanced options (refetchBoosted, removeUnspecified), see the SDK methods reference and the SDK segmentation setup guide.

Recommended attributes to push

If you are just getting started, here is a minimal set that unlocks most use cases:

Attribute
Type
Why it matters

user:id

String

Prerequisite for persistent profiles

user:email

String

Readable identification + integrations matching

user:name

String

Personalization in experiences

plan

String

Segment by subscription tier

role

String

Segment by permission level

signup_date

ISO date

Cohort analysis, tenure-based targeting

language

String

Multi-language targeting

last_active_days

Number

Re-engagement segments

feature_usage

Array

Adoption tracking and progressive onboarding

See the full recommended custom attributes guide for more examples and implementation patterns.

Seeing attributes on real users

This page is the catalog: it defines what attributes exist. To see the values a given user actually carries, you look elsewhere.

On one specific user

Open any user's profile and check the Data tab: it lists every attribute attached to that user, with its value and its Source. The Source column is your troubleshooting shortcut: if a value looks wrong, it tells you where to go fix it, your SDK push or a connected integration. See User details.

On yourself, live, from your own app

The dashboard shows what Jimo stored. To see what your app is pushing right now, in the current session, use the Troubleshooting tool.

Its user-detail section reads your live attributes and segments straight from the running SDK, so you can confirm a value landed the moment your app sends it, before it even shows in the dashboard. When an attribute is Pending and you are sure the snippet runs, this is where you catch the mismatch.

Stored vs live, in one line: the Attributes page and User details show stored data, the Troubleshooting tool shows live data. When the two disagree, trust the live one and look at your push code.

In this section

Related pages

PreviousData managementNextCreate a custom attribute

Last updated