User data & attributes
Learn about user profiles in the WLL platform, including core profile fields, custom attributes, user ID properties and restricted processing for GDPR compliance.
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 and the Users API 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.
Optional fields:
Gender: The user’s gender (defaults to unknown if not provided).
Country: The user’s country of residence (in ISO 3166-1 alpha-2 format, e.g., GB or US).
City: The user’s city of residence.
Postcode: The user’s postcode.
Profile picture: The HTTPS URL of the user’s profile picture.
User attributes
You can add custom attributes to a user via the API.
Examples of custom attributes:
Additional PII data (e.g., mobile number, first line of address).
Membership details (e.g., subscription plan, suspicious user).
Developer note: When updating user attributes, you must pass the entire attribute array in the patch request. Updating a single attribute will result in it replacing the entire array, not just the modified attribute.
Do not store internal flags as user attributes
For internal flags, use the user flags property (see API documentation for details).
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.
The auth identifier cannot be changed after it has been set.
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.
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 “[email protected].”
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.
Last updated
Was this helpful?