Skip to main content
RJBu
Level 3
February 14, 2022
Solved

sessionID parameter in Delivery API request

  • February 14, 2022
  • 10 replies
  • 5382 views

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' \

 

    Best answer by Gokul_Agiwal

    Hi @rjbu 

    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. 

    10 replies

    Gokul_Agiwal
    Community Advisor
    Gokul_AgiwalCommunity AdvisorAccepted solution
    Community Advisor
    February 14, 2022

    Hi @rjbu 

    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. 

    Thanks, Gokul
      RJBuAuthor
      Level 3
      February 14, 2022

      Thanks!

       

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

        Gokul_Agiwal
        Community Advisor
        Gokul_AgiwalCommunity Advisor
        Community Advisor
        February 14, 2022

        Hi @rjbu 

        It's a user session for that current activity. 

        Thanks, Gokul
          AbuSh1
          Level 4
          February 14, 2022

          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

            RJBuAuthor
            Level 3
            February 15, 2022

            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?

              AbuSh1
              Level 4
              February 15, 2022

              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.   

               

                Terms & ConditionsAccessibility statement

                Loading footer...