Hello community members,
I have a question regarding one of the use cases in AEP. We've developed a schema for web interaction data, with ECID as the primary identifier and CRM ID as the secondary identifier. We chose ECID as the primary ID because the CRM ID may be empty if the customer doesn't log in, and we also aim to link interactions with anonymous customers.
However, we foresee a problem with this approach. If multiple customers use the same device to access the website or make a purchase, it leads to linking multiple customers and considering them as the same, which is inaccurate. One solution could be to clear the ECID as soon as the user logs out or a new user logs in. However, this approach would result in multiple ECIDs being created for the same customer, and AEP has a limit of a maximum of 50 identities per profile.
I understand that this is not a common scenario where many profiles are using the same device for transactions, but it is still possible. What is the best way to handle such scenarios?
Thanks,
Arpan
Solved! Go to Solution.
Well, let's back up a little. I think it's worth figuring out how common this situation will be. If it's an edge case, it might not be worth over-engineering this thing. If it's a measurable % of your traffic then we're going to have to design something specific to accommodate that scenario which could have downstream implications. Depending on your business, ECID won't work as a Primary ID. Resetting ECID might also not work - because now you've redefined ECID - it's now a session identifier (or whatever the logic is).
If it's over 50% of transactions, maybe we use a hashed ID based on transaction information as the Primary ID?
If 20-30% of your business is people sharing a device then is there a way to flag this device type and have custom ID logic for that specific device?
If it's less than 5%, is it worth rearchitecting this thing just to accommodate an edge case?
See what I mean?
Well, let's back up a little. I think it's worth figuring out how common this situation will be. If it's an edge case, it might not be worth over-engineering this thing. If it's a measurable % of your traffic then we're going to have to design something specific to accommodate that scenario which could have downstream implications. Depending on your business, ECID won't work as a Primary ID. Resetting ECID might also not work - because now you've redefined ECID - it's now a session identifier (or whatever the logic is).
If it's over 50% of transactions, maybe we use a hashed ID based on transaction information as the Primary ID?
If 20-30% of your business is people sharing a device then is there a way to flag this device type and have custom ID logic for that specific device?
If it's less than 5%, is it worth rearchitecting this thing just to accommodate an edge case?
See what I mean?
@arpan-garg Did you find the suggested solutions helpful? It would be great if you can mark the answer as correct for posterity. If you have found out solution yourself, share it with wider audience in the community.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Like
Replies
Views
Likes
Replies