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.