> ## Documentation Index
> Fetch the complete documentation index at: https://docs.embeddables.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Naming keys correctly in Embeddables

> How to name component keys, computed field keys, and other keys in Embeddables correctly

In Embeddables, there are many different places where you will need to choose a key name for something.

This includes pages and components, but it also includes many features that will end up storing data in the User Data (including some types of components known as Input Components).

Therefore, understanding how to correctly name keys, and the implications of doing so, is very important.

## Types of keys in Embeddables

| Type                | Example              | Stored in User Data? | Key name...             |
| ------------------- | -------------------- | -------------------- | ----------------------- |
| **Page**            | `page_key`           | No                   | Set in Builder          |
| **Component**       | `component_key`      | If Input Component   | Set in Builder          |
| **Automatic Data**  | `current_page_key`   | Yes                  | Automatically generated |
| **Answers**         | `weight`             | Yes                  | Set in Builder          |
| **Computed Fields** | `bmi`                | Yes                  | Set in Builder          |
| **Experiment Data** | `split_title_length` | Yes                  | Set in Builder          |
| **URL Params**      | `utm_source`         | Yes                  | Set in Builder          |
| **Registered Keys** | `access_token`       | Yes                  | Set in Builder          |

### 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:

```json theme={null}
{
  ...
  "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, otherwise you could have unintended consequences, e.g. one key overwriting the other.

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](/features/split-testing), e.g. testing between two different email capture pages, both containing an input component with the key `email`.