You’ve put it on the back burner for long enough, it’s time to replace those curtains that came with the house with brand new faux wood mini blinds. Hang in there, I’m going somewhere with this!
You decide to pull up your laptop and start a shopping cart at ReplaceThoseUglyCurtains.com. Your laptop is portable, so you carry it around your house while you measure each of your windows, adding a new set of blinds to the shopping cart with each measurement you take. After measuring 10 windows and adding 10 items to your shopping cart, you decide to take a break…
You come back to it 30 minutes later and start measuring again. Add item to cart…”your session has timed out”. What! See you later ReplaceThoseUglyCurtains.com. I’m gonna head over to woot.com and buy something I don’t need instead!
Why we impose session timeouts
When we have to explain it to an e-commerce client or an end-user, we might feed them a line about it being a security concern (sometimes it actually is). For the most part, at least in the majority of my web projects, I time out sessions to conserve memory. Every visitor to a page (whether it be a search engine or a lifetime customer, someone who engages for 10 seconds then leaves or someone who adds $200 worth of product to a shopping cart) creates a user session in memory.
So what do we tell our e-commerce clients when they want us to put a 4, 6 or 12 hour session timeout in place (such as might be useful when an order involves planning – creating a kitchen cabinet layout, measuring all of your blinds, choosing from a collection of photos to print). We have options:
- Force the user to create an account before shopping, allowing us to store their shopping cart in a database and attach it to their account.
- Upgrade your server memory and charge your client an additional hosting fee.
- Reward visitors with a longer session timeout as they progress further down the on-site conversion funnel (from product store, to shopping cart, to payment form).
Increasing session timeout as a visitor becomes more “valuable”
Although I have never heard about this method, or have yet to actually implement it, providing visitors with a longer session timeout as they become more likely to convert really seems to make sense to me.
If RAM costs money (in terms of hosting fees and, I guess, actual electricity usage), it seems appropriate to allot most of it to visitors that are more likely to earn you money.
Once we’ve decided we want to do this, the actual coding aspect is surprisingly simple, assuming two things:
- It is acceptable to rely on JavaScript to extend the session timeout for a visitor
- You have a means of communicating the visitor’s “value” to the JavaScript
Using JavaScript to Extend the Session Timeout
This part is simple, and the method has been around for a while. It’s commonly known as “Keeping the Session Alive”. This method takes advantage of the fact that any request from the visitors’s browser to the server will “reset” the session timeout.
So if our user is sitting idle on a page and we wish to keep their session alive, all we have to do is make an AJAX call to a page on the server. This is traditionally done with the JavaScript setTimeout or setInterval functions.
The code below will extend the visitors’s session one time, after 19 minutes of inactivity (ideal for 20 minute session timeouts).
setTimeout(function() {
$.get('/keepalive.php');
}, 19 * 60 * 1000); // after 19 minutes of inactivity, reset the session This would essentially give every user (who has JavaScript enabled) a 39 minute session timeout.
Okay, so we know how to do it, but it doesn’t really seem to make practical sense. If we wanted a 39 minute session timeout, why not just change the session timeout settings on the server-side to 39 minutes?
Two reasons:
- A short server-side session timeout prevents non-humans (spiders, DOS bots, etc) from obtaining a longer session.
- To leverage this new method of dynamic session timeouts
Determining a visitor’s “value”
To recap, by the word “value”, I’m not talking about the user’s primary key id in your database’s user table. I’m referring to the potential for a visitor to convert to a sale on your website.
The first step in rewarding a visitor with an increased session timeout based on value is, of course, to determine the visitor’s value.
This is entirely dependent on your situation. I imagine, for most e-commerce sites, the moment a visitor adds an item to their shopping cart, they become at least 5 times more valuable. At this point we might decide to increase their session timeout five-fold.
After examining your analytics, you realize that only 25% of visitors who add an item to their shopping cart actually proceed to the checkout process. When we have a visitor this close to converting, the last thing we want is a session timeout.
Bob Jones just put $750 worth of chewing gum in his shopping cart. He spent hours putting the order together. He gets to the payment page and realizes that he left his wallet in the car, the same car that his 17-year-old son just took to the movies.
Three hours later, Bob gets his wallet back and proceeds to enter his payment information. We do not want this guy getting a session timeout! Lets be sure to increase the session timeout of visitors in the checkout process by 10-fold, and maybe 20-fold if they have more than $500 in their shopping cart.
The Dynamic Session Timeout (communicating the visitor’s “value” to JavaScript)
So we now have a basic formula for determining a visitor’s value. The question becomes, “how do we communicate that value to JavaScript, so the script can keep the session alive for the awarded amount of time?”
The answer, again, depends on your situation. At the most basic level, I’d consider using the information that your web browser makes available to JavaScript, such as the window.location object.
We can use the window.location object to determine the page the visitor is on, and hence where they are in the conversion funnel.
We can now expand the above simple keep-alive script to something like more like this:
var keepAlive = 19 * 60 * 1000; // 19 minutes
var keepAliveTimes = 0;
if (location.href.indexOf('/cart.php') !== -1) {
keepAliveTimes = 5;
}
else if (location.href.indexOf('/checkout/') !== -1) {
keepAliveTimes = 20;
}
setInterval(function() {
if (keepAliveTimes === 0) {
return;
}
$.get('/keepalive.php');
keepAliveTimes -= 1;
}, keepAlive);
Accept my apology for not testing this script. It’s more for demonstration than for practical use. Commit the concept to memory, but be wary of copy/pasting the actual code!
Taking it a step futher
That concludes my untested code examples but I wanted to finish with one more possibility for determining a visitor’s value and passing it to JavaScript.
I eluded to using the monetary value of the visitor’s shopping cart somewhere in all my ramblings above, however, the shopping cart is stored on the server-side. We could always use AJAX to grab the shopping cart value, but that kinda defeats the purpose of conserving server resources.
What if we were to, with each visit to the shopping cart, store the total value of the cart using HTML 5 Storage. You could drop that value in an easily identifiable element, in a data attribute or even generate the JavaScript itself on the server-side. However you do it, you’d just need to ensure that you use window.sessionStorage to store the cart value to a key in the browser’s storage.
Then, retrieve that value from window.sessionStorage when setting up the logic to determine the visitor’s value for the keep-alive script.
I’m hoping that was easily understood. If anyone has any additional thoughts or questions, just fire off some comments and I’ll be sure to keep on top of them.