sessionID parameter in Delivery API request

[rrrrrraul]

What exactly is the sessionID parameter in the Delivery API request call?

https://clientCode.tt.omtrdc.net/rest/v1/delivery?client=clientCode`&sessionId=d359234570e04f14e1faeeba02d6ab9914e\
  -H 'Content-Type: application/json' \

[Gokul_Agiwal · Accepted solution]

Hi @rrrrrraul 

Session ID is a unique ID for a user session. By default, this ID lasts 30 minutes.

You can able to see this unique ID in cookie name called mbox dropping by Adobe target JS library in browser. 

In terms of Server side implementation where you're using Delivery API for deliver the experience through different channels, API user needs to generate and maintained the sessionID for the current session The sessionId can be any printable string except a space, ?, or /. It should be between 1 and 128 characters in length.

Hope this helps. 

[rrrrrraul]

Thanks!

So in this context would "session" be referring to browser session, or Adobe session (or some other session)?

[Gokul_Agiwal]

Hi @rrrrrraul 

It's a user session for that current activity. 

[abu_shafi]

"browser session" but is the customer is back within 30min you have to use the existing "session id"

[abu_shafi]

hi

Follow the details
"For a particular session, its value must stay the same across multiple requests for the same user since routing to a particular node in the edge cluster, which contains the user profile, is done using the sessionId. The session is active for 30 minutes on the server side. Therefore, you shouldn’t use a different sessionId for a particular tntId or thirdPartyId within 30 minutes of the last request made with the same tntId or thirdPartyId. Otherwise, changes to the profile could be inconsistent and unpredictable."

For API implementation "Session id" management is your responsibility. Adobe is expecting 30min retention of this ID from the last active session. 

If session id is not maintained correctly you will have the following issues 

- cache segment is served (not real-time segment)

- frequency capping is not working

There is a limit on how many time real-time segment is pulled in a session is session is not manage correctly you will hit the limit and end up getting cache segment

Thanks

Abu

[rrrrrraul]

So what is the recommended pattern on how to access/persist the sessionID on a pure server side solution?  Is this even possible?

Is the VisitorID service (JavaScript) required to fetch information required for user persistence/bucketing (sessionID, ECID, etc.)?  If so it seems that the Delivery API cannot be a pure server side solution, unless there is something I'm missing here.

The specific use case I'm thinking of is when a user comes to site and has not yet been identified as a particular visitor (i.e., user clears cookies on close of browser).  In these cases the inbound request will not have ID cookie information.  However each request (in same session) after that should.  This means that said user could potentially get two different versions of the same test for each browser session.  

Does this make sense?

[abu_shafi]

In our case server side solution is required for financial institution due to content injection (via js implementation) is not allowed in our secure site or mobile apps.

Target API solution required 3 things (Visitor Id, Analytics & Audience manager).

The specific use case I'm thinking of is when a user comes to site and has not yet been identified as a particular visitor (i.e., user clears cookies on close of browser).  In these cases the inbound request will not have ID cookie information.  However each request (in same session) after that should.  This means that said user could potentially get two different versions of the same test for each browser session.  

---

Implement visitor id correctly should take care of the above concern.   

[rrrrrraul]

What exactly do you mean by "Implement visitor id correctly"?  

My understanding is that the Visitor ID service can only function on the front end (client side), i.e. the browser.  That being the case, how is the Delivery API supposed to have access to the required artifacts (sessionID, ECID, etc.) to pass into the outbound request on the server side if they do not yet exist in the HTTP request cookie attributes?