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?
I did some diagnosis on my own regarding the mbox3rdPartyId parameter not showing up in my mBox calls and wanted to share quickly:
Based on what I've found, there seems to be an issue when using at.js 2.1.0 with DTM where setting an mbox3rdPartyId doesn't work.
Effectively, any parameters in your "Global Variables" section in DTM will get ignored when at.js tries to set the mbox3rdPartyId parameter for the Page View mBox call or a getOffer mBox call. However, when you use a trackEvent() call, at.js *will* capture your global variables.
When tracing through the global/page view mBox call - note that the "e" object is empty
When tracing through a getOffer() mbox call - the only items in the "e" object are parameters that I had directly added in the mBox:
But when I trace a trackEvent() mbox call - all of my global variables and my mBox parameters are available in the "e" object:
This behavior seems to be specific to the method that sets the mbox3rdPartyId value. If folks are having trouble similar to mine, this behavior seems to be why you're not seeing that mbox3rdPartyId value in certain circumstances (and is probably another reason to migrate to Launch before upgrading to at.js 2.X).