# User data, attributes & flags User profiles contain a variety of data fields. Below is a summary of the core fields and additional information. For more advanced details and information on how to create a user, refer to [creating-users](https://kbase.whitelabel-loyalty.com/product/loyalty-engine/users/creating-users "mention") and the [**Users API**](https://docs.whitelabel-loyalty.com/rewards.html#users-users-collection) reference documentation. *** ## Core profile fields #### Required fields: * **Given name:** The user’s first name. * **Family name:** The user’s surname (last name). * **Email address:** The user’s email address. {% hint style="info" %} If you prefer not to collect any of these fields, you can pass placeholder values: * Use 'REDACTED' or 'UNKNOWN' for given or family names. * Use '' for the email address. {% endhint %} #### Optional fields: * **Gender** - The user’s gender (defaults to UNKNOWN if not provided) * **Birth date** - Stored as *ISO 8601*: YYYY-MM-DD * **Telephone number** * **Street address** * **City** * **Region** * **Postcode** * **Country:** The user’s country of residence (in *ISO 3166-1 alpha-2* format, e.g., GB or US) * **Profile picture:** The HTTPS URL of the user’s profile picture *** ## User attributes & flags Users can have both attributes and flags associated with their account. These provide a way to store additional information beyond the standard profile fields. #### Common use cases Examples of what you might store as attributes or flags include: * **Additional PII:** e.g., mobile number, company name, favorite store * **Membership details:** e.g., subscription plan, suspicious user * **Ancillary info:** e.g., legacy user, staff member {% hint style="warning" %} #### Do not use attributes for targeted rewards/added incentive **Attributes** can be modified by the user and should *not* be used for sensitive data or segmentation logic tied to rewards (e.g. VIP status). Use **flags** for that purpose. {% endhint %} ### Attributes vs. flags

Feature	Attributes (data.profile.attributes)	Flags (data.flags)
Structure	Object of key–value pairs, e.g. `"companyName": "WLL",` `"favoriteCheese": "Manchego"`	Object of boolean keys, e.g. `"legacyUser": true,` `"staff": false`
Editable by	Users (with user auth token) & admins	Admins only (admin auth token)
Use case	Personal info users might update	Internal info used for segmentation
Value type	Any type per key	`true/false` only
Security	Not suitable for sensitive or benefit-granting data	Safe for use in audience-based rewards

### Setting attributes & flags Attributes and flags can be viewed or set [via API](https://docs.whitelabel-loyalty.com/rewards.html#users-specific-user-patch), or using the Loyalty Console by navigating to a specific user account and scrolling down under the *Details* tab. {% hint style="danger" %} #### Submit full array when updating attributes & flags via API When updating attributes, always submit the full array of attributes in your PATCH request. Partial updates will overwrite the entire array. {% endhint %}

User profile in Loyalty Console showing attributes and flags

*** ## User ID properties Each user in the Loyalty Engine is assigned several identifiers, each serving a specific purpose: * **WLL ID:** This is a unique UUID assigned to the user by the Loyalty Engine. It serves as the user’s primary identifier in the system and can be passed as the subject ID when reporting events. * **WLL Account Number:** This is a 7-digit account number assigned to the user by the Loyalty Engine. Like the WLL ID, the account number can also be passed as the subject ID when reporting events. * **External Identifier:** This is a flexible field that allows you to attach an arbitrary string to a user, often used to link the loyalty account to an external system (such as a CRM or membership platform). The external identifier is not required to be unique and, therefore, **cannot be passed as the subject ID** when reporting events. It is limited to 512 characters in length. * **Auth Identifier:** This identifier is required when creating a user in **administrative mode** and links the loyalty account to the ID used by your tenant’s authentication server. If the API will not be directly called with a user authentication token, this ID can be any unique string and can be used instead of the external identifier. The auth identifier can be passed as the subject ID when reporting events. This field is ignored if the API is called in user mode. {% hint style="warning" %} The **auth identifier** cannot be changed after it has been set. {% endhint %} *** ## Restricted processing Restricted processing is used for GDPR workflows when users request to limit further processing of their data. This setting must be false when creating a new account, as users must consent to data processing for account creation. When restricted processing is enabled for a user, they are excluded from data exports and console charts. This is useful for: * Users who request restricted processing as required by GDPR. * Test accounts in production environments, preventing impact on analytics accuracy. {% hint style="info" %} Restricted processing **does not prevent the user from accessing or participating in the loyalty program**. It is solely used to limit the processing of their data for compliance purposes. {% endhint %} *** ## FAQs #### Can I change a user’s Auth Identifier after it’s set? No, once assigned, the Auth Identifier cannot be modified. It serves as a fixed link between the loyalty account and the user’s authentication ID in your system. #### What happens if I only update one attribute in the attribute array? When updating user attributes, you must pass the entire attribute array in the request. Updating a single attribute without the full array will overwrite the other attributes with the new request. Be sure to retrieve and include all attributes you want to keep. #### Is it safe to store internal flags as user attributes? No, avoid storing internal flags in user attributes since attributes can be edited if the user has API access. For internal-only indicators (such as suspicious user or VIP status), use user flags, which are protected fields that cannot be edited by users. #### How does Restricted Processing affect a user’s experience in the loyalty program? Restricted Processing only limits the inclusion of the user’s data in analytics and exports; it does not restrict the user’s ability to access or interact with the loyalty program. Restricted processing is typically used for GDPR compliance or to exclude test accounts from impacting analytics. #### Can I use placeholder values if I don’t want to collect certain core profile fields? Yes, if you prefer not to collect given name, family name, or email, you can use placeholder values: * For given name or family name, use “REDACTED” or “UNKNOWN.” * For email address, use “.” #### What’s the difference between WLL ID, WLL Account Number, External Identifier, and Auth Identifier? * *WLL ID*: The primary UUID assigned to a user by the Loyalty Engine. * *WLL Account Number*: A 7-digit loyalty account number also used for event reporting. * *External Identifier*: A flexible field for linking to an external system, not required to be unique. * *Auth Identifier*: Links the loyalty account to the user’s ID in your authentication system; required for creating users in admin mode and cannot be changed after being set. #### What should I use for a user’s location information? The Loyalty Engine supports multiple location-related optional fields: country (ISO 3166-1 alpha-2 format), city, and postcode.