Session is such a simple term, but we can use it for multiple definitions. For example, it can apply to a 40-minute session of a therapist with their patient or refer to the number of hours in a movie theater watching a movie. But for developers and marketers, the word takes on added meanings: a game session, the uninterrupted use of a service, the day-to-day use of an app, and so on.
Session and sessionization (which refer to the act of clustering session activities) became popular in the last few years. Both words are part of the user journey analysis universe. In this post, we will explain how our technology enables the creation of browsing journeys that adapt to the needs of each customer in real-time.
A session is a way of clustering a sequence of interrelated activities. It's like a new chapter in a book you write each time you enter a website or use an app. And the title of this book is "The User's Journey".
Concluding a session is analogous to placing a period at the end of a chapter about a specific interaction with the application.
It'd be like going to a store in the offline world. Did you enter and leave with something? Did you look, and then just left? Did you promise yourself you'd go back and buy something? However, the interactions aren't as clear-cut as when visiting physical stores in the online world.
And that is why we need a heuristic or logic for defining when a session ends. Imagine the following scenario to help you understand the challenge:
- 10:00 – A user accesses an e-commerce searching for specific sneakers
- 10:02 – They spend 5 minutes reading about the sneakers
- 10:07 – They close the tab without buying anything
- 10:30 – They go back to the site and add the product to the cart
- 10:35 – They conclude the purchase
By looking at this narrative, can we confirm that all the activities are part of the same session? The answer is: it depends.
For some websites, the session ending is defined by the time one spends between an activity and the next one.
In the previous example, if that interval is 35 minutes, all the activities are included in the same session. But what if the interval was only 15 minutes? The first visit would occur before adding the product to the cart, and the actual purchase would happen during the second visit. So shouldn't we define it as two sessions?
The truth is there is no single way to define it in all cases. In the gaming world, where the scenario is much more dynamic, 30 minutes between one match and the other would be considered an eternity.
And that is why the sessionization model is flexible at Croct, adapting to the most diverse scenarios. As a result, you can select the logic that best meets the needs of your business when setting up your account.
Clustering activities in sessions can seem trivial when looking at how things have happened in the past. However, if you understand SQL (and then you know how clustering logic is not that sophisticated), you are able to analyze each session of a clustering event without too much effort.
It becomes challenging to make decisions in real-time: each user interaction can be the last or just another one among many others that are still yet to come.
The challenge is even more significant if your app runs offline. Imagine a user departs on a flight, and after taking off, they enter the flight mode and spend the entire flight using your app. After getting off the plane, the app goes back online. How can these events be clustered? That is what we call late-arriving events, and our platform knows precisely what to do in these cases.
Our platform lets you choose an expiration policy to better meet the needs of your business.
The midnight policy ends the session every time at midnight. New day, new session; it's just that simple. It's also the best alternative for those who wish to view the site side-by-side based on each calendar day.
But the timeout policy abides by another pattern. A session is considered ended when the time between an interaction and the next one is longer than the one set in the account. That is the logic adopted as a standard by most web analytics platforms.
Along with all this, you can even specify a grace period. That option defines how long the platform should wait for delayed events.
In the example of using the app during flights, if the grace period is four hours, all events taking place in the first four hours of the trip will be correctly assigned to the session that began before entering the plane. You can set the grace period according to your business needs.
After clustering events into sessions, decision-making becomes more simple and assertive. Without sessions, you'd need to think about all the possible scenarios, and you'd quickly lose the focus on what's really important: user experience. For determining what should follow, questions like "is that the first visit of the user?", "is that what happened recently?" or "what did they do right before that moment?" are essential.
Besides that, it's possible to create "summaries" from sessions on your users' experiences, including stats on the number of visits, session time, number of orders, and others.
Imagine you wish to personalize your site for users who have previously visited it. You would need to do at least the following to implement something so simple:
- Identify the user between visits
- Determine a logical pattern for defining the beginning and end of a visit
- Increment the number of visits in each new session
- Create a service for rolling back the number of the current visit.
This would easily make your technology team sprint. But with Croct, this process is as easy as writing the user is returning. Furthermore, based on sessions, our platform can answer this and many other questions simply, agilely, and efficiently.
Did you like the content and want to experiment with Croct? Create your free account and explore our platform by yourself.