Identity Groups
An identity group is at its core a grouping of customers and may consist of any customer including guests. Each group can apply rules to the customers matched within, controlling the price group, discounts, loyalty points, access rights and fixed members. You can access identity groups via the Aurora admin menu.
Create a New Identity Group
Navigating to the Add Identity Group tab you will initially create an identity group providing only its name.
After doing so you will be presented with the edit page for your newly created Identity group where you can configure it to your needs.
Managing Identity Groups
Priority
Identity groups have conditions that when required are resolved against the user's request. This resolution process may result in zero or more identity groups as a result but a single identity group will need to be selected. To handle this Identity Groups have a "priority" field, which is a numerical value where the lower the number the higher the priority.
Price Group
When editing an Identity group you will may notice the Price Group field. This field allows for assigning a given Price group to an Identity group to be used within price group resolution.
This allows for providing members of an Identity group different prices than that of another group or the default price group.
The price group field will only show when multiple price groups have been enabled. Contact Aurora to action this on your behalf.
Priority
The priority is used to order identity groups when the identity group is selected i.e. which identity group to select first when a user has multiple identity groups assigned.
The lower the number the higher the priority. Leaving this field empty is the lowest priority.
Merchandising
Discounts and Loyalty Points can be applied to customers matched to a given Identity group. To understand how these are configured and how they work with the wider merchandising platform see our User and Group Discounts guide and Loyalty Points guide.
Members and Access Rights
An identity group can have dynamically assigned members or fixed members. Having fine-grained control over specific user access rights is helpful for individual roles however at times when more than a single user is in a role it’s beneficial to be able to enforce access rights to a group of users. This can be easily done with Identity Groups and fixed members. To understand more about how this is configured please see our User Access Rights guide
Conditions
Members can be dynamically assigned to an identity group for a request. How this assignment happens depends largely on the conditions an administrator creates within the conditions UI.
The UI allows for creating nested AND/OR based rules covering:
Constraints Key:
- eq: equal
- ne: not equal
- gt: greater than
- gte: greater than or equal
- lt: less than
- lte: less than or equal
- in: matches a value from a list
| Rule | Constraints (see key above) | Notes |
|---|---|---|
| Group: Customer | ||
| Has User Account | eq:yes/no | Is the current user logged into Aurora? OR API Identity Group requests that submit a user email address in the context match to a user account. |
| Group: Eagle Eye | This group is not available by default, talk to your AC account manager if this group of rules are required. | |
| Has Valid Wallet | eq:yes/no | One of the following to be true to equate to “yes”: Does the user have a valid discount card in their basket? Does the user have an active Eagle Eye session with a valid Eagle Eye card. If no active session does the user have an associated wallet id associated to their user account and do they have a valid Eagle Eye card If an Identity Group API call, does it contain a user_email context item, and does the value match a user with a valid wallet?If an Identity Group API call, does it contain a eagle_eye_discount_card context item, and does the value validate? |
| Group: API | ||
| Is an API Call | eq:yes/no | Is the current request an API request? |
| API V1 User | eq:[value] | The request is from the selected V1 API user |
| API V2 User | eq:[value] | The request is from the selected V2 API user |
| API Custom Field[key] | eq:[value] ne:[value] gt:[value] gte:[value] lt:[value] lte:[value] in:[list] [key]:exists [key]:does not exist | A Condition Context Field provided in the Identity Group API Call will be matched (according to the constraint type) against a user-defined value. [key] is a string. [value] is a string. [list] is a comma-separated list of [value]s |
| Group: Locale | ||
| URL Slug | eq:[value] in:[list] | Does the current user's locale match the user-defined value? [value] is a string. [list] is a comma-separated list of [value]s |
| Group: Customer Order History | ||
| Order Count | eq:[value] gt:[value] gte:[value] lt:[value] lte:[value] | The current logged-in customer's total number of orders is over/under the user-defined value. [value] is an integer |
| Total Value | eq:[value] gt:[value] gte:[value] lt:[value] lte:[value] | The current logged-in customer has a total historic order value over/under or equal to the user-defined value? [value] is a decimal or integer |
| Last Ordered Date | eq:[value] gt:[value] gte:[value] lt:[value] lte:[value] | The current logged-in customer's last order was placed before/after the user-defined date. [date] is a string with date format dd/mm/yy |
Note during API requests Aurora will action all rules on the customer if a user email is provided (context key user_email) and a customer exists with that email. E.g the logged in rule will consider this truthy.
Can't find a rule you need, let us know!
Updated about 1 year ago