Array of identities

Bear in mind that you cannot mark a string array as identity.

To support this, you may have to use the identityMap field group instead for your Loyalty IDs.
Also, do not mark them as primary identities!

Make sure that your Customer ID is set on the dataset as primary identity to support profile stitching.

{
    "_mytenant": {
      "customerId": "cs_1234567"
    },
    "identityMap":{
        "myLoyaltyNS":[
            {
                "id":"1111111111",
                "authenticatedState":"ambiguous",
                "primary":false
            },
            {
                "id":"2222222222",
                "authenticatedState":"ambiguous",
                "primary":false
            }
        ]
    }
}

btw: not crazy, just implemented it for a client

Hi ​@Michael_Soprano ,

Multiple Loyalty IDs — Edge Cases:

The main risk is cross-customer merging. If two customers share even one Loyalty ID, AEP will stitch them into one profile — which is wrong.

Other edge cases to watch:

1. Array attributes get overwritten — if second ingestion sends only [L001], AEP replaces [L001, L002, L003] completely. Old IDs are gone.
2. Unique Per Graph conflict — if Loyalty namespace has Unique Per Graph = Yes, having multiple Loyalty IDs on one profile will split into two separate profiles for the same customer — one per Loyalty ID.
3. 50 identity limit — if you add all Loyalty IDs as identity nodes, you burn through the limit fast.
4. Segmentation on arrays is painful — you have to write PQL instead of using the standard rule builder.

Best approach:

Store multiple Loyalty IDs as a profile attribute array — not as identity nodes. Use CustomerID as the primary identity namespace for stitching since it is stable and unique per customer. This keeps the identity graph clean with no merge risks while all Loyalty IDs remain accessible as attributes for segmentation and querying.

​@Michael_Soprano the solution and approach depends heavily on the use case and how you want to use the Loyalty id/data.
 

There are three possible designs, and the correct one depends on how the Loyalty IDs will be used.

1. Use identityMap when Loyalty ID must perform identity stitching

If records or events may arrive with only a Loyalty ID and must resolve to the customer profile, include the Loyalty IDs in identityMap.

• Customer ID should remain the stable primary identity.

• Customer ID should be Unique per graph and highest priority.

• Loyalty ID must remain non-unique if multiple Loyalty IDs are valid for one customer.

• Be aware of shared/recycled Loyalty IDs and the Identity Service limits of 20 identities per record and 50 identities per graph.

2. Use a lookup/dimension schema and relationship when Loyalty ID represents a related business entity

This may be the better option if each Loyalty ID has its own attributes, such as:

• Program name

• Membership tier

• Enrollment date

• Points balance

• Status

• Expiration date

Create a separate Loyalty Account lookup/dimension schema with one record per Loyalty ID. Set Loyalty ID as the primary key/identity of that schema.

Then add a string-array relationship field to the customer Profile schema:

{
  "customerId": "C123",
  "loyaltyIds": [
    "L001",
    "L002",
    "L003"
  ]
}

Configure loyaltyIds as a relationship to the primary Loyalty ID field in the lookup schema. Adobe supports relationships on string and string-array fields, so a customer can reference multiple Loyalty Account records.

This approach:

• Keeps Loyalty IDs out of the person identity graph

• Avoids identity-graph merge and size risks

• Preserves one record and attributes per Loyalty ID

• Supports multi-entity segmentation using Loyalty Account attributes

However, schema relationships provide enrichment and multi-entity segmentation; they do not perform identity stitching. Data arriving only with a Loyalty ID will not automatically merge into the Customer ID profile merely because a schema relationship exists.

Both schemas must be configured appropriately for Real-Time Customer Profile, and the lookup/reference schema must have a primary identity. Also review the dimension-entity guardrails: nested relationships and time-series data on dimension entities are not supported.

3. Use a profile attribute array when Loyalty IDs are only descriptive values

If Loyalty IDs are needed only for display, querying or simple segmentation—and have no separate attributes and never act as join keys—store them as a normal profile attribute array.

Therefore:

• Identity stitching required: use identityMap

• Related Loyalty Account records and segmentation required: use a lookup schema plus relationship

• Only a list of values required: use a profile attribute array

​@Michael_Soprano hope you got the solution approach you were looking for, if so please mark the correct response as accepted answer for the community