Tealeaf is a great tool for reviewing your customers’ behavior while visiting your website. Your organization might have started small and done a single application. Quite likely the data proved to be valuable and additional applications were added into the mix. But, as you added applications, did you consider the impact of sessionization?
Internally, Tealeaf is deriving a TLTSID value from your chosen session ID. You need to consider whether that session ID value is going to be unique over the time period you’re storing sessions.
As with most complicated information technology questions, the short answer to the question “How should I plan for proper sessionization?” is, “it depends.” For that first application, your organization probably chose some application-specific session cookie. It works fairly well when Tealeaf is only being fed one application. The pilot started, you breathed a huge sigh of relief when traffic through your PCA looked clean and you configured your PCA to use JSESSIONID or ASP.NET_SessionId. All was well with the world. Maybe you also set the session timeout parameter to be equal to that of your application’s session timeout. Your users saw what they expected and there were few questions.
But then the appetite for behavioral insight and general perception of Tealeaf’s value add grew. Your organization decided to add another application, then another. You probably thought you had it covered by reconfiguring your PCA – perhaps the first application was based on the .NET architecture and then you added another one on a different platform. Maybe it kept track of session state through a JSESSIONID cookie. Perhaps your PCA configuration looked a bit like this when you were finished:
All was well until you got feedback from your analysts: “I know this user visited applications X and Y, that’s clear from the comments they made on Facebook. Why am I only seeing their session for X?” At the time the most efficient response you could offer might have been to tell them to note the client IP address and do a search either just before (or after) the start (or end) of their X session. It was enough to walk them through finding the REMOTE_ADDR in the first request of the session and all was well.
But those calls got more frequent and more shrill. Perhaps they also realized that completely unrelated sessions were being concatenated together by RTV. That also points at a possible problem with your organization’s approach to Tealeaf sessionization. Even if you’re not injecting a TLTSID cookie, it’s deriving a TLTSID value from the one you’re telling the PCA to use. If that’s not unique over time, you’re likely to see disparate customer sessions mated together.
Shortly afterwards, a new story might have shown up on your group’s backlog. “As Tealeaf analysts, we would like to see all sessions from *.ourtopleveldomain.com appear in one contiguous RTV session.” Maybe there’s a second story about the unrelated customer data being concatenated together. Perhaps it’s even something that’s in your backlog now.
There are a few options out there. You conceivably could ask your application development teams to maintain session state identically, but it’s very unlikely that would result in a conversation that led anywhere productive. In any case, that’s probably the very most expensive way of achieving the goal. So let’s dismiss that one out of hand: the solution to your sessionization problem is very unlikely to be an application rewrite or, for that matter, a quick reconfiguration of the PCA. You’ll do that at the end, but there are some steps that need to be worked through in-between.
You’ve probably considered IBM’s Tealeaf cookie injector. It generates a TLTSID value that’s unique over time and you could configure your PCA to sessionize off of that – after you’ve convinced your organization that a new binary (and configuration file) need to become part of your standard server load! The most recent scuttlebutt that I’ve heard, in any case, is that IBM has chosen to treat the cookie injector as freeware. It’s not really the approach they would prefer you take. In any case, it’s a windows-only solution. Even if you are a windows-only shop – maybe you’d prefer not to have that negotiation with your production support and information security teams about the new binary you want to run in production. It’s completely understandable.