Variables
Variables are dynamic placeholders you insert in text content to personalize experiences with real user data at runtime.
Understanding variables
Variables are dynamic placeholders you insert in text content and action fields to personalize experiences with real user data at runtime. Use them to greet users by name, reference their plan, route them to a personalized URL, or pre-fill the Agent with a contextual prompt, all powered by any user attribute.
What a variable does at runtime
A variable is a named reference to a user's data. In the editor it appears as a styled chip (e.g. {firstName}). When the experience is shown to a user, Jimo replaces each chip with the user's actual value for that attribute.
Example:
"Hi {firstName}, your {plan} subscription renews on {renewal_date}."
Rendered for a specific user:
"Hi Sam, your Pro subscription renews on 15 Jun 2026."
Every user who sees the experience gets their own personalized version based on their profile.
Variables and user attributes
Variables are a read-only projection of your user attributes. Any attribute attached to a user can become a variable: native fields (name, email, language), custom attributes pushed via the SDK (plan, role, signup date), and fields synced from integrations (HubSpot, Salesforce, Segment.io).
This means the same data powering your segments also powers your personalization. Push an attribute once, use it for both targeting and content.
Where variables can be used
Variables work in two distinct contexts: rich text content (paragraphs, titles, labels the user reads) and specific action fields (URLs and messages that configure user-facing actions).
Any text editor with rich formatting supports variables. Whenever you see a text input with a toolbar exposing bold, italic, and link options, a variable icon lets you insert an attribute as a styled chip.
Step titles, body text, CTA labels
Questions, intro text, thank-you messages
Headlines, body copy
Tooltip titles, body text
Task names, descriptions, completion messages
Header title, section titles, item labels
Post titles, body content
Greeting messages, suggested prompts
Some action configuration fields also accept variables, even though they are not rich text editors. The variable inserter appears as a dedicated button next to the input.
Navigate to — URL field
When configuring a Navigate to action on a CTA button, a progress trigger, a checklist task, or a resource center action block, the URL field accepts variables. This is how you route each user to a personalized destination like their own dashboard or workspace.
Example:
https://app.example.com/workspace/{workspace_id}/settings
Resolves for each user to the workspace they belong to.
Launch Agent — Message field
The Launch Agent action includes an optional Message field that pre-fills the Agent chat with a prompt when it opens. This field accepts variables so the Agent immediately starts processing a contextual, personalized question.
Example:
"I am on the {plan} plan. Can you help me understand my billing cycle?"
Gives the Agent the right context from the first message, no setup needed from the user.
Where variables are NOT available
Some fields never accept variables because they are not meant to resolve at runtime:
CSS selectors in hint positioning or tour step targets
URL matching rules in the Where targeting section (not the Navigate to action URL, but the page-match URLs)
Targeting conditions and segment names
Experience names and internal descriptions
API keys, webhooks, and integration credentials
Quick rule: if a field has a variable insert icon (+ or a person icon) next to it or in its toolbar, it supports variables.
If no icon, the field is plain text only.
Inserting a variable
Opening the variable picker
Click any supported field to activate it, then click the variable icon to open the picker. The icon varies slightly between surfaces: a + icon in most text editors, a person icon in the Agent Builder, and an Add attribute button in action configuration fields.
Picking a variable
In the picker, click the variable you want to insert. It appears at the cursor position as a styled chip. You can continue typing before and after the chip like normal text.
To insert multiple variables, open the picker again at the next cursor position. There is no limit to how many variables a single field can contain.
Setting a fallback value
Click any inserted variable chip to open its edit popover. From there you can:
Select the attribute variable — search within the attributes list
Edit the fallback value — the text shown when the user has no value for the selected attribute
See Fallback values below for how to choose good fallbacks.
Available variables
The variables you can insert come directly from your user attributes. Two categories appear in the picker.
Native variables
Jimo's username and email are always available, regardless of your setup:
Jimo Username
User's display name (from user:name)
Jimo Email
User's email (from user:email)
Custom attribute variables
Every custom attribute pushed via the SDK or integrations becomes an available variable. Push plan, role, and signup_date and you will see {plan}, {role}, and {signup_date} in the picker.
Visibility rules
Only attributes that have been pushed at least once appear in the picker. An attribute defined in your code but never actually sent to Jimo will not show up until the first SDK call with that attribute lands.
If a custom attribute is missing from the picker, check that your SDK is sending it correctly. See the SDK segmentation setup guide.
Fallback values
A fallback is the text that displays when a user does not have a value for the referenced attribute. Without one, missing attributes render as an empty string and can break the grammar, flow, or URL structure of your content.
How fallbacks work
If the attribute has a value: the variable renders with that value
If the attribute is empty or missing: the variable renders with the fallback
If no fallback is set: the variable renders as an empty string, which can leave awkward gaps in your copy or invalid URLs in action targets
Fallbacks are only resolved live
In preview, the SDK is not loaded, so things such as attribute values aren't fetched. This means that in preview mode your experience will always display the fallbacks, which behave exactly like testing as a completely anonymous user without any attributes logged.
Setting good fallbacks
Choose a fallback that keeps the sentence natural. A few examples for text content:
{firstName}
there
"Hi there"
{company}
your team
"Welcome in your team"
{plan}
current
"Your current subscription"
{role}
user
"As a user, you can…"
For action fields (URLs, Launch Agent messages), set fallbacks that still produce valid values:
{workspace_id}
Navigate to URL
A default workspace slug or the home page path
{plan}
Launch Agent message
your plan so the sentence still reads naturally
Always set a fallback for user-facing variables. Test your copy with an anonymous user to make sure it still reads well when no attribute is available, and make sure URL fallbacks still resolve to a valid page.
Testing personalization
Preview in the builder
Use the Preview button in the experience builder to load a rendered version with placeholder data. The preview shows variables resolved with fallback values so you can validate layout, wording, and URL construction before publishing.
Live test with a specific user account
Once the experience is published, the most reliable way to test is to identify yourself as the target user (via your real account or a dedicated test account) and load the page where the experience should appear. Variables then resolve with your actual user data.
For staged testing, use a dedicated Team segment or a test environment so you can iterate on variable content without affecting production users.
Best practices
Always set fallbacks on user-facing variables. Missing data should never produce broken grammar or invalid URLs.
Use variables sparingly in critical messages. Over-personalization can feel intrusive.
Test with multiple user profiles (identified, partially identified, anonymous) to make sure your copy and URLs work in all cases.
Push attributes early to expand what you can personalize. Attributes you use for segmentation become available as variables automatically.
Combine with Multiple Languages to localize content with user-specific data in the correct language.
Keep variable names predictable. If you use
firstNamein one attribute, stick to that naming convention across your custom attributes.For URL variables, validate destinations. A wrong
{workspace_id}can send users to a 404 or the wrong account. Test with several sample users before publishing.
Related pages
User attributes: Reference for the data that powers variables
Users: Inspect individual user data in the profile panel
Segments: Target experiences based on the same attributes you use as variables
Content Builder: Where you insert variables into your experience text
Available Actions: Navigate to and Launch Agent reference with their variable-enabled fields
Setup the segmentation: Push custom attributes to unlock more variables
Multiple Languages: Localize content alongside variable personalization
Target right people (Who): Target experiences based on the same attributes you use as variables
Last updated