I'm working on a deployment of Target/Recommendations on a standard website (i.e. not a single page app). We're running at.js 2.1.0 and we have Experience Cloud ID service running, as well as Analytics. We're also using mbox3rdPartyID to leverage the the client's internal user IDs so that we can more accurately map and maintain profile data for specific users.
Most everything about this deployment is straightforward, but I've run into a use case that is a little bit odd.
One of our key stories is that users will be accessing the site from a 'kiosk' computer. They don't have log-in credentials to that computer itself (it is effectively always running the same "Guest User" account), instead they log in to the website on that computer. What this means is that we can rapidly transition between different user accounts on the website inside the same "session" window (i.e. 30 minute blocks).
This is a problem because Target - by design - is hanging on to a session identifier. If we have someone log off and another user log in, that 2nd user is currently seeing the first user's personalized content. I'm also not sure what the implications are for having a session with two or more values for mbox3rdPartyID.
We've tried a few workarounds - the least unsuccessful being a custom code data element for mbox3rdPartyID that will wipe out the Target mBox cookie if it sees the value of mbox3rdPartyID change (Store ID value in cookie, compare ID data element to cookie from previous page, if values don't match delete mBox cookie). That does clear out the 1st user's recommended content, but we're not seeing the profile data update to the 2nd user when we debug the Target experiences.
For what it's worth - right now we're not using any offline data attributes, so we have not configured the ECID service to set an Authentication State. Based on the documentation I've seen so far, that does not appear to be mandatory at this stage. That said, I'm wondering if there's a potential issue because ECID is holding on to a customer identifier and confusing the profile merge?
Effectively, how do I tell Target that the first user's session is over when a key event happens and to prepare for a new user? Also, is there an expected time-lag that I should worry about when we swap over between different mbox3rdPartyID values?
Hi Ryan - first off thanks for the feedback. Quick questions/responses:
Yeah, we're not doing anything special with the cookies so I think we are in what you would consider a 'default 1st party cookie deployment'. I wish there was an easy way to detect the user leaving the kiosk - there is a website log-out which we might be able to use but because it causes navigation I'm wary of relying on that 100% (If I could get the log-out servlet to delete the mbox cookie, that would probably be ideal but I don't think I can get that capability.
That said - as long as I delete the mBox cookie before I trigger the global mBox on page load, that should be okay right?
Okay, that makes sense and is what I expected based on the documentation. Thanks much.
I did notice that when I set mbox3rdPartyId I'm not seeing the parameter show up in the id block of the mBox JSON if I use I .getOffer/.applyOffer call but I do see it when I use a .trackEvent() call. Is there any reason for that difference? I've not used at.js 2.x very much and this behavior has been difficult for me to diagnose/explain.