Skip to main content
In Embeddables, User Data refers to the current data stored on a given user. User Data exists as a JSON object of properties. These properties could be:
  • Answers the user gave to questions (the key would be the input component’s key)
  • A value calculated by a Computed Field (the key would be the computed field’s key)
  • A value set by an Experiment (the key would be the experiment’s key)
  • Other types of properties (see full list below)

​
Where is User Data stored?

User Data is stored in three places, or ‘contexts’, and each one usually stored a different amount of data.
Contexts are cascading, so if a property is stored in #2, it will also be stored in #1 as well, and so on.
  1. Embeddable Context - This is the full User Data, and is stored within the Embeddable itself. It is not available after the user refreshes or closes the tab.
  2. Local Storage Context - This is the subset of User Data that is stored in the user’s browser, in Local Storage. It’s used to remember a user’s answers and position in the flow after they close the tab and return later.
  3. Embeddables Cloud Context - This is the smallest subset of User Data that is stored in Embeddables’ databases. It is used for displaying analytics insights in the Embeddables Web App.

​
How to set whether/where a User Data property is stored

This feature is coming soon to the New Builder.In the meantime, ask Embeddables support to show you how to set this in the component JSON.

​
Types of User Data

TypeExampleTypical Use-Case
Automatic Datacurrent_page_keySending the user’s current page to an API
AnswersweightAsking the user for their details
Computed FieldsbmiCalculating a value to decide if the user is eligible
Experiment Datasplit_title_lengthUsing the user’s current variant to show or hide a page
URL Paramsutm_sourceSetting a condition based on the user’s traffic source
Registered Keysaccess_tokenStoring the result of an API request

​
User Data keys and key naming

You can read our full guide to best practices for naming keys in Embeddables here:

Naming keys correctly in Embeddables

Learn how to choose good names for component keys, Computed Fields and more.

​
Input component keys

Input components, i.e. components that collect data from the user, are special in that they store their data in the User Data. This means that the key name you choose for an input component will also be the property key name for that field in the User Data. For example, if you have an input component with the key name, the User Data will look like this: 
{
  ...
  "name": "John Doe"
  ...
}
For this reason, it’s especially important to choose good key names for input components.

​
Choosing good key names

  • All keys must be in snake_case, meaning:
    • lowercase letters and underscores only
    • no numbers
    • no special characters
    • no spaces
    • no uppercase letters
  • All experiment keys must start with split_.

​
Input component keys, and other keys that end up in the User Data:

  • Should be short and descriptive (e.g. full_name).
  • Should describe the data it’s collecting, not the component (e.g. full_name not full_name_input).
  • Should be unique within the Embeddable, except in very special cases (see below).

​
Keeping keys unique

All keys, whether component keys or other User Data keys, must be unique within the Embeddable. The only exception to this rule is if you’re handling multiple input components that will be ‘swapped out’ - i.e. shown/hidden such that only one of them is visible at a time. The most common use-case of this is a Split Test, e.g. testing between two different email capture pages, both containing an input component with the key email.

​
Default User Data

Default User Data allows you to set initial values for User Data properties when an Embeddable loads. These values are automatically added to the User Data object before the user interacts with your Embeddable.

​
How it works

When you set default User Data:
  1. The values are stored in the defaults.userData property of your Embeddable configuration
  2. When a user loads the Embeddable, these default values are automatically added to their User Data
  3. Default values are applied during the reset process - when User Data is cleared, default values are preserved and reapplied

​
Setting default User Data

You can set default User Data through the Builder UI:
  1. In the Builder, navigate to the Options panel for your Embeddable
  2. Look for the “Edit default user data JSON” option
  3. Click to open the JSON editor modal
  4. Add your default values as key-value pairs in JSON format
Example: 
{
  "user_type": "new_visitor",
  "source": "organic",
  "language": "en"
}

​
Use cases

Default User Data is useful for:
  • Pre-filling form fields - Set default values that users can modify
  • Setting initial state - Define starting values for conditions or logic
  • Tracking metadata - Add default tracking parameters that persist throughout the user’s session

​
Important limitations

Not recommended for Computed Fields - Default User Data should not be used to set values for computed fields. The update sequence could cause computed fields to override default values before you intend them to. Computed fields should set their own default values, and using both would create conflicts.
Not recommended for Experiment data - Default User Data should not be used to initialize experiment-related data. The Experiments feature handles setting that data automatically, and using both would create conflicts.
Requires Registered Keys - If you want to set default User Data for keys that aren’t already created by components, computed fields, or other features, you must add those keys to Registered Keys. This ensures the Embeddable is aware of them and can watch for changes.

​
Behavior with reset

When you reset User Data (either programmatically or through user actions), default User Data values are preserved and reapplied. This ensures that your Embeddable always starts with the correct initial state. The reset process:
  1. Clears most User Data properties
  2. Preserves system properties (like entryId, current_page_id, etc.)
  3. Preserves computed fields and experiment keys
  4. Reapplies all default User Data values
Default User Data values will not override existing User Data. If a user already has a value for a key, the default will not replace it unless the User Data is reset.