User Attributes

User attributes are the profile fields you let your members keep on their own record. You define the list of attributes once for your organization — each with a name, a type, and a stable key — and then every member can have a value for each one.

Unlike raw member metadata, user attributes are controlled: only the attributes you have defined can be read or written through the Allegro APIs. This is the foundation for a member preference center, where a signed-in member can manage settings like newsletter opt-ins, content preferences, or a favorite topic.

How they work

• You define attributes in Organization Settings → User Attributes.
• Each attribute has a slug that maps to a single key on the member's profile. This is where the value is stored.
• Each attribute has a type (text, number, boolean, or a fixed set of choices) that Allegro uses to validate and cast values.
• Members set their own values through the Browser SDK, or your backend sets them through the REST API. See Setting values.
• A member's current values are included in their signed session token (JWT) so your site can read them without an extra request.

Defining an attribute

Open Organization Settings → User Attributes and click New attribute. You provide:

Field	Required	Description
Attribute Name	Yes	The human-readable label, e.g. Wants Newsletter.
Slug	Yes	The key the value is stored under, e.g. wants-newsletter. Auto-filled from the name.
Description	No	An optional note describing what the attribute is for.
Type	Yes	How the value is validated and cast. See Attribute types.
Options	Enum	One choice per line. Shown and required only when the type is Select (enum).

The slug auto-fills as you type the name, but you can override it before saving.

The slug is permanent

The slug is the member profile key the value is stored under, so it cannot be changed after the attribute is created. On the edit form the slug field is locked. Pick it carefully — to rename the key you must delete the attribute and create a new one, which leaves the old values behind under the old slug.

Attribute types

Type	Stored value	Notes
Text	A string	Any free-form text.
Number	A number	Whole numbers or decimals.
Boolean	true / false	A simple on/off flag.
Select (enum)	One of a list	Must match one of the Options you defined, one per line.

Allegro validates every incoming value against the attribute's type. A value that doesn't match — a non-number for a Number attribute, or a choice outside the list for a Select attribute — is rejected.

Editing an attribute

From the User Attributes list, click an attribute's name to edit its name, description, type, or options. The slug stays locked.

Changing the type of an attribute with existing values

Changing an attribute's type does not rewrite values members have already saved. Existing values are reinterpreted under the new type the next time they're read, which can produce unexpected results (for example, text that isn't a number becomes 0). Change the type of a live attribute with care.

Deleting an attribute

Deleting an attribute removes it from the list so it can no longer be read or written through the APIs or included in new tokens.

Member values are kept

Deleting an attribute definition does not erase the values members have already stored. The values remain on each member's profile under the slug. If you later re-create an attribute with the same slug, those existing values become visible again.

Setting values

You don't set member values from the admin UI — they're set programmatically:

• Members set their own values through the Allegro Browser SDK (allegro.member.setUserAttribute(...)). This is how a preference center on your site lets a signed-in member update their profile. See the User Attributes SDK guide.
• Your backend sets values for any member through the REST API, under /v1/audience-members/{id}/user-attributes. Reading requires the audience-members:read scope; writing requires audience-members:write. See the REST API reference.

Writing to a slug that isn't a defined attribute is rejected — this is the control boundary that keeps arbitrary metadata out of the attribute APIs.

Values in the session token

Each member's current attribute values are included in the signed session token (JWT) as a user_attributes claim, so your site can read a member's preferences directly from their token. Only attributes the member has a value for appear; each value is cast to its declared type. See JWT Verification for the full token structure.

Related

• User Attributes SDK guide — Read and write a member's attributes from the browser.
• JWT Verification — Read attribute values from the session token.
• Members — Browse and manage your audience.