{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.


That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.


Sorry about this, there is a problem with our search at the moment.
Please try again later.

When your sales conversion is lower than expected - asking the tech team for web performance metrics may not help: visitors per hour is not enough, concurrent users is plain unhelpful.

I was interested to read Ashley's blog, where he argued that marketing and commercial people "should take a closer look at their IT set up?"

Again this week, I came across the sad case of a marketing manager trying to get the best ROI on their portal, and getting baffled by the wrong metrics.

I guess I'm surprised that after all these years (back in 1992 I was explaining the benefits of the web to blue chips), that marketing and business folk still find it hard to get concrete measurements, so they can apply good business sense to the online world.

Sales conversions had been lower than expected and the question was raised - just how many sales /minute can our online store handle? 

The web analytics in place, with a little more time, could have provided more than just pages/minute and visitors/minute metrics.

Pages or visitors per minute is a poor measure anyway your site can probably shift a lot more homepages per second, than say the final checkout page (which does a load of database and credit checking work), and not all visitors are on your making-money pages anyway.

The finance metrics in place weren't bad either, that told them how many orders per day they'd taken. But that was all historic data about the 'what happened', not 'why did it happen'.

It couldn't help the marketing manager's question - the successful campaign had generated lots of new visitors, but had that extra load maybe caused caused slow downs and errors for users; and thus been the root cause of the low sales conversions?

Bluntly, did the online technology let the campaign down just at it's moment of success. Or must root cause lie in the campaign marketing and targeting.

The poor marketing manager was left high and dry when the tech team responded to the web capacity query with a big number.

It would have been nice if they could have shown a graph like the following of performance for the checkout pages:

1,000 concurrent users?

Users are treated worse as the week goes on... and they said this portal could handle the best part of a thousand 'concurrent users'. Sounds huge. Humm..

But err… not all 'concurrent users' are making purchases… so what exactly does it mean?

The business and tech team do talk a different language - the tech team are wrestling with the vagaries and not-so-logical problems and black-art of complex web application software and languages, while the marketers are coming top down, from customer user journeys, and sales values, etc.

The tech team uses concurrent users as a measure for a simple reason. It's easy. It requires no testing. It requires no analysis of any data. No need to spend any time on it. A web application worth its salt will give you a value for it, straight off.

And for a busy site, it is often a reassuring high value - way bigger than any business metrics like sales per minute. It kind of deflects criticism of the technology platform.

Definiton: Concurrent Users is the count of how many real users are currently on the site (in technical talk - they have a session running).

  • When does a user become a Concurrent User? - as soon as they hit their first page.
  • When does a user drop out of the count? That happens after a timeout value is reached, after the last page they requested. The length of that timeout is configurable in the web application - e.g. 30 minutes.
Did you see the impact of that timeout property? It means that even after a user has downloaded their last page from your site, and has now gone off elsewhere on the Internet, they are still listed as a concurrent user until the timeout ends. But they aren't making any demands on your system in that time window - no pages downloaded, nothing.

So not all concurrent users are equal - they may be a visitor who has grabbed one page in the last half hour; or at the other end of the scale, someone who went through 20 pages in the last 10 minutes, during which they searched for a product, put it in the basket, then went to the check out to buy it.

That's not a great metric for the marketer struggling with low sales conversion issues.
And another factor - is that by changing the configuration of your web software (the session timeout value), the concurrent users value will also change! Without any change in the level of activity on your system. Or any change in the capacity of your system to handle load. Ouch.
So what have we got so far:

  1. Pages per second is a poor measure of capacity - your site can probably shift a lot more homepages per second, than say the final checkout page (which does a load of database and credit checking work)
  2. Concurrent users are far from being equal - ranging from a visitor who requests only 1 page in say 30 minutes - versus a valuable customer who in 15 minutes gets 10 pages, makes a product search and spends money with you.
  3. The concurrent user number from your web application can be manipulated up or down without any change to your systems capacity, through the time-out setting.

There are of course better metrics to cover the capacity handling capability of your website, which I'll cover next time.

But until then, if you're planning some load testing of your website - make sre that you'll get more then 'concurrent users' out of it.


Deri Jones is CEO and founder of SciVisum, a web application testing company.


Published 12 October, 2006 by Deri Jones

Deri Jones is Chief Executive Officer at SciVisum and a contributor to Econsultancy.

4 more posts from this author

Comments (2)


Jason Koumas

What a load of old tosh!

about 9 years ago


Bill Salak

This article is completely misinforming and attempts to address issues the author clearly does not understand. I won't correct all of the misstatements but I would like to point out that concurrent users is the count of visitors to a website at the exact same time. All visitors beyond this crucial number will have to wait their turn for the webserver to respond.

Let's assume your webserver can handle 250 concurrent users, user number 251 will have to wait for 1 of those 250 requests to be served. We count server response times in milliseconds so user 251 would typically not even know that they were queued up before they got served. Now take that same server and send it 250k requests at the exact same millisecond. User number 250k would have a signifigantly longer wait that user number 300.

The number of concurrent users is not something that "any web application worth it's salt" will tell you. This number is based upon hardware performance in combination with web application requirements and is the result of many complex factors.

I do agree that marketing folks and tech folks are speaking a different language as the author stated. Tech folks should be paying attention to the metrics which ensure uptime, performance and stability within their systems. Marketing folks generally want to know about visits, views, and conversion rates which are absolutely the wrong numbers to use to capacity plan with from an IT perspective.

If you are reading this article you are obviously interested in this topic and I would be happy to share with you more specific information and/or suggestions in response to any questions you might have.

over 7 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.