# Variables ## 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](https://help.usejimo.com/docs/analyze/users-and-segments/users/attributes).
#### 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](https://help.usejimo.com/docs/analyze/users-and-segments/users/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](https://help.usejimo.com/docs/analyze/users-and-segments/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). {% tabs %} {% tab title="Rich text content" %} 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.
| Surface | Examples of use | | ------------------------------------------------------------------------------------------- | --------------------------------------------- | | [**Tours & Modals**](https://help.usejimo.com/docs/experiences/tours-and-modals) | Step titles, body text, CTA labels | | [**Surveys**](https://help.usejimo.com/docs/experiences/surveys) | Questions, intro text, thank-you messages | | [**Banners**](https://help.usejimo.com/docs/experiences/banners) | Headlines, body copy | | [**Hints**](https://help.usejimo.com/docs/experiences/hints) | Tooltip titles, body text | | [**Checklists**](https://help.usejimo.com/docs/experiences/checklists) | Task names, descriptions, completion messages | | [**Resource Center**](https://help.usejimo.com/docs/experiences/resource-center/components) | Header title, section titles, item labels | | [**Changelog posts**](https://help.usejimo.com/docs/experiences/changelog) | Post titles, body content | | [**Agent**](https://help.usejimo.com/docs/experiences/agent/chat/agent-builder) | Greeting messages, suggested prompts | | {% endtab %} | | {% tab title="Action configuration fields" %} 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**](https://help.usejimo.com/docs/build/actions/available-actions) **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**](https://help.usejimo.com/docs/build/actions/available-actions) **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. {% endtab %} {% endtabs %} ### 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](https://help.usejimo.com/docs/publish/target-specific-urls-domains-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 {% hint style="info" %} **Quick rule:** if a field has a variable insert icon (**+** or a person icon) next to it or in its toolbar, it supports variables. ![](/files/BH7trZSj2ISJ8d4LljPx) **If no icon, the field is plain text only.** {% endhint %} *** ## 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](#fallback-values) below for how to choose good fallbacks. *** ### Available variables The variables you can insert come directly from your [user attributes](https://help.usejimo.com/docs/analyze/users-and-segments/users/attributes). Two categories appear in the picker. #### Native variables Jimo's username and email are always available, regardless of your setup:
| Variable | Value | | --------------- | -------------------------------------- | | `Jimo Username` | User's display name (from `user:name`) | | `Jimo Email` | User's email (from `user:email`) | #### Custom attribute variables Every [custom attribute](https://help.usejimo.com/docs/analyze/users-and-segments/users/attributes) 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. {% hint style="warning" %} If a custom attribute is missing from the picker, check that your SDK is sending it correctly. See the [SDK segmentation setup guide](https://help.usejimo.com/docs/for-developers/for-developers/sdk-guides/setup-the-segmentation). {% endhint %} *** ### 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
{% hint style="warning" %} #### 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. {% endhint %} #### Setting good fallbacks Choose a fallback that keeps the sentence natural. A few examples for text content: | Variable | Suggested fallback | Renders as | | ------------- | ------------------ | --------------------------- | | `{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: | Variable | Context | Suggested fallback | | ---------------- | -------------------- | ------------------------------------------------- | | `{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 | {% hint style="info" %} 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. {% endhint %} *** ## 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.
{% hint style="info" %} For staged testing, use a dedicated [Team segment](https://help.usejimo.com/docs/publish/target-right-people-who) or a [test environment](https://help.usejimo.com/docs/settings/environments) so you can iterate on variable content without affecting production users. {% endhint %} *** ## 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**](https://help.usejimo.com/docs/build/multiple-languages) to localize content with user-specific data in the correct language. * **Keep variable names predictable.** If you use `firstName` in 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](https://help.usejimo.com/docs/analyze/users-and-segments/users/attributes): Reference for the data that powers variables * [Users](https://help.usejimo.com/docs/analyze/users-and-segments/users): Inspect individual user data in the profile panel * [Segments](https://help.usejimo.com/docs/analyze/users-and-segments/segments): Target experiences based on the same attributes you use as variables * [Content Builder](https://help.usejimo.com/docs/build/builders/content-builder): Where you insert variables into your experience text * [Available Actions](https://help.usejimo.com/docs/build/actions/available-actions): Navigate to and Launch Agent reference with their variable-enabled fields * [Setup the segmentation](https://help.usejimo.com/docs/for-developers/for-developers/sdk-guides/setup-the-segmentation): Push custom attributes to unlock more variables * [Multiple Languages](https://help.usejimo.com/docs/build/multiple-languages): Localize content alongside variable personalization * [Target right people (Who)](https://help.usejimo.com/docs/publish/target-right-people-who): Target experiences based on the same attributes you use as variables --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://help.usejimo.com/docs/analyze/users-and-segments/users/variables.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.