Up/Down Monitoring isn’t Enough for Your Business

[This article was written by Laura Strassman]

Up/down monitoring won’t help your business

Businesses run on applications, and to keep your business running optimally, you must be monitoring those web applications.  The end users of your apps expect a certain level of performance, and if that expectation isn’t met, they simply will not complete transactions.  This means that in order to keep users happy and the business running smoothly, you must measure both performance and availability.

Synthetic Monitoring – It’s not all the same

Synthetic monitoring works by simulating users navigating to your application.  This type of monitoring can provide information about the most common paths in the application, uptime, and performance of your critical business transactions. However, synthetic monitoring is not all the same; it ranges from a simple ping to see if a server is turned on, to tests that replicate user interactions through complete business transactions.

Since there is so much variety within synthetic monitoring, it is important to match the precise monitoring technique to the problem you need to solve. When choosing a solution, ask yourself the following: Can my users successfully complete a transaction?

If your monitoring solution cannot answer that question, why use it?

In order to obtain accurate data about the performance of an application, it is important to replicate user interactions as closely as possible. AlertSite UXM offers several different types of monitoring that range from ping tests all the way to advanced, real browser-driven transactions that replicate exactly what a user would do when following a specific navigational path in the application.

In order to obtain accurate data about the performance of an application, it is important to replicate user interactions as closely as possible. AlertSite UXM offers several different types of monitoring that range from ping tests all the way to advanced real browser-driven transactions that replicate exactly what a user would do when following a specific navigational path in the application.

There are two options to think about when monitoring:

1. Does the monitoring system use an actual browser to look at web applications? Or does it bypass the browser?
2. Is the monitoring looking at a single page or service call? Or is it following a transaction over multiple steps?

In order to measure performance for an end user, you need to use a browser based monitor which can look at a complete transaction.

Think of it like this: Simply looking at the home page of a website is like pulling in to the parking lot of an ice cream shop, seeing the storefront, but not getting out of your car to actually get your ice cream.

AlertSite UXM’s Advanced Web monitor is browser based, and can move through any series of steps that a real user would take while interacting with a web application.

Monitoring in this way offers information about both performance and availability and even provides advanced metrics for Perceived User Experience.  These metrics show a more granular level of detail that accurately reflects the performance of the application for an end user, as well as any performance degradation impact on that experience.

On a practical level, if you are not monitoring performance, then the operations team can be sitting in the NOC (network operations center) with all the lights on their systems green, while the customer service phones are ringing off the hook because end users cannot complete transactions online.

For example, we monitored an e-retailer’s web site in two ways.

1. The home page
2. A three-step transaction to place an item into a shopping cart

The first screen shot shows the availability and performance of the e-retailer’s home page.

You can see that although the full page render time is slow, availability for the page is perfect.  (The ice cream shop’s lights are on.)  Furthermore, you can see that the perceived user experience metrics, first paint, and above-the-fold rendering all fall within acceptable limits.

Below is the transaction trace of a user navigating to something that they want to purchase.  Rather than just looking at the home page, we can observe the navigational path and the three steps that follow.

This screenshot tells a much different story than the first.

First of all, the page is quite slow.  Secondly, the image tells us that it is often not possible to complete the transaction, meaning the person can’t buy anything.

Back to our original analogy… You have a hankering for ice cream but you aren’t sure about the hours of the ice cream shop.  So you get in your car, drive by the store, and pull into the parking lot.  The lights are on and you think you see movement behind the counter window, but can you tell if you’ll be able to get that ice cream?

But if you get out of your car, walk up to the window, someone takes your order, collects your money and hands you your cone, then you can be certain that your ice cream transaction was a success.

If you followed the analogy, you’ll understand that you must look at what the desired user behavior is after landing on the home page.  If that user journey cannot be completed then you are not in business from a web channel perspective. You must monitor that critical path, starting at the URL you are monitoring today.