How do we tell Target a user's session is over (and a new one is starting)?

[Reyhan_Sadaka]

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?

[Ryan_Roberts_ · Accepted solution]

Hi Reyhan Sadaka​,

There is no way to force the session on the Target server to end. It only ends after 30 minutes of silence. Wiping the mbox cookie (assuming a default 1st party cookie deployment) seems like the most effective solution for you. I would think that ideal time to wipe the cookie would be once the user leaves the kiosk. Is there some action that could be triggered on the kiosk machine to clear cookies? Perhaps changing the browser settings to clear cookies on exit or something like that?

If you clear the mbox cookie at the right time I don't think this would be an issue.

You do not want to "switch" to different mbox3rdPartyId's on the same mbox cookie. That will merge profiles together. Again, I think deleting the mbox cookie will serve you best here. The profile merge should be real time when an mbox3rdPartyId is passed.

Hope that helps,

Ryan

[wesleybrett1]

Is it still not possible to force a new session? I'm running tests and need to see a new session, little annoying that I have to wait 30 mins.

Alternatively is it possible to reduce the 30 min timeframe only in the Dev/Stage instance?

[Reyhan_Sadaka]

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.

[Reyhan_Sadaka]

As a quick note for folks:

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.

Examples:

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).