I feel real sympathy for Marketing departments.  They are saddled with the enormously difficult task of profiling users in order to achieve more effective marketing efforts.  In order to do that, they must understand who the user is, what they did on the site and how they reacted to various marketing efforts.  Up to now, they have been relying on traditional Web Analytics solutions to get that data.  However, the price for that data is the insertion of page tags and tracking cookies.  Cloud-based services add on an additional price – the exporting of analytic data out to the cloud.  All of that might seem like a small price, but it is actually a true Faustian deal.

To start with, Marketing must subject itself to the busy timelines of Development, QA and IT whenever it wants to change its tagging or cookies.  Since those departments are often busy rolling out new features, Marketing often has to wait weeks or even months to get their new data.  In many cases, Marketing discovers a problem with the page tagging during the course of a campaign and are unable to roll out a fix quickly enough. In companies where this problem is recognized, the problem is reversed and Marketing is allowed to hijack the roll-out process with an emergency patch to its analytics tagging, often negatively impacting the delivery of important new features.  Both Marketing and IT would benefit if this link could be severed.

The other problem that Marketing is facing comes from Europe, where a wave of privacy regulation is forcing existing Web Analytics solutions to run for cover, leaving Marketing departments with little to help them.  Germany has passed very strict laws prohibiting the use of page tagging and tracking cookies without the user’s consent.  Moreover, shipping analytics data to a hosted service for processing is specifically forbidden.  Although privacy is often talked about in every part of the world, Europe is the first to have passed these kinds of laws about it – a trend that could easily spread outside EMEA.

The irony is that most of the data that Marketing often requires is already contained within the traffic stream before any tagging or tracking takes place – where the user is from, what browser and OS they use, which ISP they used, where they came from, where they went, what they looked at, what they bought, etc.  It’s either embedded in the HTTP protocol or as part of a web server’s natural ability to maintain a stateful application or it is directly within the request or response content.

Consequently, as announced last week, Coradiant has teamed up with Google to create our Analytics In A Box (AIB) solution.  This revolutionary new product uses Coradiant’s existing technology to passively process all user traffic to and from the web site, producing full-featured web analytics data that remains in-house.  Instead of inserting page tags or using special cookies, Marketing can define AIB rules that will extract the information directly from the traffic stream. This approach will allow Marketing to define new metrics whenever they want to – even in the middle of a campaign during peak hours.  Moreover, the solution refreshes its data every hour, providing Marketing with immediate results from any changes.  No other department has to be involved.  Moreover, the data is 100% secure and kept in-house, which means no privacy violations.

As Bogey said, “this could be the start of a beautiful friendship”.

Coradiant is holding an informative afternoon executive event in the Penthouse at Gary’s Loft in Manhattan focused on end-to-end Web application visibility.

You can register for the event here (https://www.123signup.com/event?id=jbxhq).
Presenters include:

• Dave Anderson, Principal Architect/Co-founder of Peopleclick,
• Dennis Callaghan of The 451 Group,
• Fred Dumoulin of Coradiant
• Andreas Grabner, dynaTrace software,

Gary’s Loft in Manhattan features a stunning 360 degree view of the Manhattan skyline.  Light food, beverages and hospitality will be provided by Tip Of The Tongue NYC.

Date: Thursday, November 12, 2009
Time: 4:30 PM to 6:30 PM ET

Gary’s Loft
28 West 36th Street
Penthouse
New York, New York 10018

Coradiant’s TrueSight End-User Experience Management product evokes a number of interesting reactions when we first start monitoring a customer’s Web traffic.  One of the most common reactions is amazement at just how many bugs exist – even in the best Web applications.  One customer speaking at a luncheon described the experience as being similar to turning on the light in your apartment and seeing big ugly cockroaches everywhere – you are appalled, you are embarrassed … and you feel a strong urge to simply turn off the light.

This might seem like a damning statement to make about one’s own environment.  And yet we repeatedly hear how such confrontations with the ugly truth have provided insights that resulted in the correction of long-standing problems, some of which had never even made it onto the radar of Web Operations.  I think you would have to struggle to find a Coradiant customer that did not have a similar story to tell. One customer discovered that 30% of their traffic consisted of cache hits (where the server reports that nothing has changed) or redirects.  By simply tweaking the caching parameters returned by their web servers, they reduced the load on their servers significantly.  Another customer discovered that some pages were taking up to 1.5 minutes to be handled by the server before a response was being sent back to the browser.  Yikes.

How many users are hitting your site?  How many errors are being returned?  How slow are the pages?  How reliable is the network?  Some customers are clearly floundering without any real ability to answer these fundamental questions.  Other customers believe they already have a solid handle on such issues.  We have found that almost all of them have a real shock in store.  Some of our most loyal customers are those that firmly believed they knew the truth already.

Often, though, the insight doesn’t have to be that deep to be a revelation.  It never ceases to amaze me how often web sites are thrown over the fence to be supported by a team that hasn’t the first clue about what they have taken on.  We offer a fairly simple feature that reports lists of traffic attributes sorted by popularity – e.g., URLs, hosts, client IP address blocks, geographic regions, cookie keys, etc.  Our customers can define their own fields as well, pulling whatever they would like out of the traffic to do so (e.g., database error codes, product IDs, etc).  We use this feature to help populate configuration fields.  However, the contents of those lists proved to be such a revelation to our customers that we re-categorized the feature under “Reports”.  Using this simple feature, one of our customers noticed that we were seeing internal traffic that we should not have been able to see.  This led him to realize that his routers were improperly configured.

The customer that we had invited to speak at our luncheon finished off his presentation by advising others – somewhat jokingly – to consider carefully whether they were truly ready to handle the truth about their traffic.  Ugly as it may be, facing it can reveal real solutions to real problems.  I highly recommend it.

I spend a portion of my time working with Coradiant customers on session tracking strategies that ensure a complete view of the end-user experience. Session tracking gives us the ability to see clearly every action, every page and every object associated with a user. Proper session tracking achieves what we refer to as user awareness. This is different from identity awareness, which allows us to put a face to the session. I’ve written in more detail about the differences between identity awareness and user awareness, but I can recap briefly for the purpose of this article.

Identity awareness means that you know the unique ID of a specific user on the site, allowing you to put a name (or even a face) to that user’s activity – e.g., user XYZ can now be referred to as “Jonathan” or “jginter”.  Oddly enough, this is fairly simple since it only requires that users identify themselves (by providing an ID) at least once during their session – e.g., as part of a login procedure, etc.  If even one hit during the session carries the user’s personal ID, we can be configured to pull it out and place it on the session we are tracking.

I just said a mouthful and didn’t underscore it, though.  I said that we were tracking a session already, which means we would have already achieved user awareness.  To do this is no small feat, since it requires that we be able to identify the subset of hits that represent the activity of a single unique user.  This is the foundation of any good monitoring solution.  Moreover, we must find these related needles out of the haystack that is the river of traffic we are monitoring.  Ironically, this could be very simple, but most sites make it very hard.  However, we can resolve this through a couple of simple suggestions.

As I have said before, most sites host traffic that is unintentionally anonymous – i.e., there is nothing on the hit that would identify who it belonged to.  Even sites that are diligently trying to place identifiers in their traffic are likely to have anonymous traffic that they are not aware of.  Why is that?  The simple fact is that most sites suffer from tunnel vision.  They focus on their most important traffic – JSP, HTML, ASP, etc.  These hits represent their application, as they perceive it.  When they track a user’s progression through their site, these are the URLs that they care most about.  What are often overlooked are the support files – stylesheets, javascript, images, etc.  Although secondary in importance, they can be critical when it comes to understanding the performance seen by the user.  Organizations must solve this problem in order to monitor their traffic properly.

There are two basic problems that need to be addressed:

1. Failing to use cookies to identify sessions
2. Failing to control the domain of those cookies

Whatever identifier is being used on the primary URLs, it should also be present on all secondary URLs as well.  For those applications that use something other than a cookie to carry session IDs, this can be a challenge if not downright impossible.  Switching to cookies allows the browser – the most authoritative source for identifying a unique user – to properly label every hit using a natural aspect of the protocol.  Even when browsers do not support cookies, web servers have been designed to rewrite the URLs in the content being sent to that the cookie values are embedded in the URL paths themselves.  The beauty of this is that browsers and web servers are designed to do this with little effort on the part of the application developer.  All that is required is that the web server be configured to open a new session for any traffic it sees – something that is not usually done if the developers are trying to maintain a stateless application.

Recommendation #1: all web servers should be configured to track sessions even if the application is stateless.  Opening a session does not mean you are required to maintain any state.

So now your web servers are diligently placing a session cookie on all traffic that they are serving up, which will solve the problem … most of the time.  You can still be easily defeated by deployments in which some or all of the secondary files are hosted on an alternate server.  This is a problem because it places those files in a different domain and cookies are sensitive to domains (and paths).  It is considered a bad practice to ask browsers to send cookies to servers that don’t care about them (it bloats the network traffic and forces web servers to do extra work for nothing).  Therefore, web servers often configure their cookies so that browsers only send them back to the servers (i.e., domains) that issued them.  Thus, browsers usually do not send cookies set by the primary server to the secondary servers as well.  This is easy to fix, however, by changing the configuration of the web servers.  Most of the time, the secondary servers have the same root domain – e.g., www.coradiant.com vs. images.coradiant.ca – so a simple rule that includes both domains (*.coradiant.*) can be associated to the session ID cookie, allowing the browser to send it on all traffic to the monitored site.  That will ensure that all secondary traffic is also clearly tagged with a unique session ID.  Although this goes against best practice, the session ID cookie is typically very small and the best practice was meant to avoid needlessly sending multiple cookies and / or fat cookies with heavy payloads.  Moreover, what I am suggesting is hardly “needless”, since it solves a significant problem.

Recommendation #2: define domain patterns that cover your whole site and associate those patterns to the cookie(s) that will be carrying the session IDs.  Each web server vendor may do this differently, so consult the administration manuals for your specific web servers for more information on how this can be done.

Reconstructing sessions reliably does not have to be complicated, but people often get in their own way.  These simple recommendations should help solve a world of problems, no matter what monitoring solution you are using.

I’m starting day two of the Data Center Summit at Interop, back-to-back with user group events in New York and Boston this week. The first day was a very interesting set of topics:

• Steve Shah of Risingedge presented a session on the “State of the cage.” This fascinating presentation looked at the evolution from mainframes to clustered computers, and from local procedure calls to intra-data-center delays.
• A panel of folks including Michael Baum (CEO of Splunk), James Sayles (CCO of Ecora) and Michael Weider (CTO of IBM’s recently-acquired Watchfire) discussed issues of compliance and privacy in data centers.
• John Carton, formerly at Accenture and now the Senior Director of Web Services at Nature’s Bounty, presented a model for thinking about disaster recovery in data centers.

There was lots to learn from the sessions. Steve pointed out that with the adoption of service-oriented architectures, back-end procedure calls that used to take microseconds now take milliseconds, and that virtualization will make this worse since developers don’t know whether an often-reached machine is local or remote. Michael observed that compliance, which tells people to keep everything, conflicts with privacy, which says that more data makes a breach more risky. And John suggested that companies need to evaluate not only availability, but also how much data they can afford to lose, when setting recovery policies for data centers.

Today’s tracks look at the range of data center models (from on-demand to full colocation with a content delivery network); the issues of power, cooling, and efficiency in greening modern data centers; and automating changes in within data center environments.

I watched the Bourne trilogy this weekend.

I have to confess that I love the series. One of the things I most admire about it is that the hero actually thinks. I mean, in the first film, he grabs a radio off an opponent, rips a floor map off a wall, and uses that to evade capture and get out of the building. Sure, the films have some crazy car chases (which, by the way, result in a lot of accidents — how unusual!) And there are flight scenes and explosions. But they’re always reasonable.

It’s sad that I’m so impressed by someone acting wisely and normally. As I thought more about it, it occurred to me that Hollywood fills films with convenience. They do this so much that cleverness and pragmatism are refreshing. We’re so used to the Macguffin that when there isn’t one, we’re actually pleasantly surprised.

Peter’s Evil Overlord List is a great, and growing, list of silly conceits from movies. It does a better job than I can of making my point. Some examples:

1. My Legions of Terror will have helmets with clear plexiglass visors, not face-concealing ones.
2. My ventilation ducts will be too small to crawl through.
3. Shooting is not too good for my enemies.
4. One of my advisors will be an average five-year-old child. Any flaws in my plan that he is able to spot will be corrected before implementation.
5. No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.
6. I will never build only one of anything important. All important systems will have redundant control panels and power supplies.
7. For the same reason I will always carry at least two fully loaded weapons at all times.
8. Once my power is secure, I will destroy all those pesky time-travel devices.
9. If I have massive computer systems, I will take at least as many precautions as a small business and include things such as virus-scans and firewalls.
10. No matter how many shorts we have in the system, my guards will be instructed to treat every surveillance camera malfunction as a full-scale emergency.

So what does this have to do with IT? Well, often demos are so convenient they lull buyers into a false sense of security. We want to accept the convenient explanations, because they make things simple.I remember movies from the seventies in which the bad guy locked Our Hero in the sauna, hoping he’d steam to death.

Oh, come on. How many saunas have doors that lock from the outside?

For that matter, how many data centers have big “self destruct” buttons, clearly marked? How many security guards have nametags without photos on them? How many times is the back door to the secret lair conveniently ajar? None of these things happen in the real world; but they happen in movies, and we accept them. Software demos do the same thing. We see a demo, and it looks fine. We want to believe it can save us. We’re willing to accept the coincidences. Salvation is real and imminent.

But reality is a lot more bleak. The tools are seldom as straightforward as they were in the demo. In our field — user performance management for online applications — there are plenty of examples of how things in the real world aren’t nearly as convenient.

Here’s my list of ten differences between the demo and the real world for web monitoring technologies.

1. There’s always a security problem

Whenever you try to deploy new software, there are always security issues. Applications require ports for communication, and have to be tested by the security department. Capturing user data means compliance and oversight — depending on your industry, you may have to store it for seven years. And physical devices may be subject to attacks or may be an unsupported operating system. Good, secure tools that work out of the box without annoying your security officer are worth their weight in gold.

2. URIs aren’t sensible

Sites don’t always have easy-to-read names. Sure, Wikipedia might have http://en.wikipedia.org/wiki/Evil_Overlord_List as a URL that’s pretty easy to parse. But more often than not, it’ll be something like http://www.ifaw.org/ifaw/general/default.aspx?splash&oid=17767 (which, by the way, is the home page for the International Fund for Animal Welfare — but you wouldn’t know it from the URL.) Assume that for something to be useful, it has to be flexible enough to accommodate the quirks of your site’s structure.

3. The things you’re testing change

Nothing is static. We have customers whose websites’ code changes daily. For them, a simple test isn’t really relevant; it’s useful for a day. If a key function is a constantly moving target, make sure your tools can stick to that target like glue. Otherwise, when something breaks you’ll be looking at yesterday’s data. Ask yourself whether a tool can adapt quickly to changes in the site.

4. All functions aren’t equal

The typical website has dozens of funtions, from login to reporting to search to account management. We don’t expect all of them to take the same time. Logging in should be relatively quick; but generating a detailed report could take a while. And we’re okay with that. Unfortunately, performance measurement isn’t. Most web performance tools have a “one size fits all” approach to thresholding. This means that you’re either flooded with false alarms (which you’ll turn off) or missing important ones. Does the monitoring technology recognize the context of a function and a user, and automatically adjust to different functions?

5. Every site breaks in its own special ways

I used to have a bounty for broken sites. Over the years, people have sent me hundreds of screenshots of applications breaking in new and unexpected ways. (to this day, one of my favourites is http://www.starwars.com/welcome/404.html.) Some sites try to hide their errors behind polite apologies. Others give detailed error information on the page. Some errors don’t even produce data: A premature server reset or excessive TCP retransmissions, for example, happens outside the realm of HTTP; but it’s still a problem. What if your site breaks in ways that aren’t in the demo you’re seeing?

6. No matter what reports you’ve got, you don’t have the right one

You can never tell what you’re going to need to look at. Sure, it might be useful to see which server is busiest, which browser is slowest, or which page has the most errors. But sooner or later you’re going to get a “complicated” question: “Are Firefox browsers from China who search by zipcode generating more errors?” (seriously, one of our customers needed to know this.) If the tool can only slice data in predefined ways, you’re going to be stuck guessing. How flexibly can you focus the analysis of the tool on specific segments of traffic? Can you drill into it?

7. The installation of agents always has issues

The software agent is the IT equivalent of a dentist saying, “trust me, this won’t hurt a bit.” Agents need management and updating. They have to transmit data, and present points of attack. They’re silent when the servers they run on are broken. They generate network traffic. And they’re sandboxed, trapped within the environment on which they run.

Sure, agent-based monitoring is a necessary evil. But it should be used judiciously, and you need to deploy agents with a recognition that things won’t be as rosy as they sound. You’ll have to lobby for their deployment. You’re going to jump through hoops to get them communicating with your management systems. When you’re looking at a demo that has complete visibility, spend a lot of time on the organizational cost of that visibility.

8. Editing tags has hidden costs and limited visibility

The web alternative to agents is tags. These included pieces of Javascript provide some monitoring by asking the browser to report on performance and errors. Javascript and tagging is a big headache. For marketing departments, it’s an invaluable tool — but Gartner claims that maintaining tags and scripts is the biggest downside to web analytics.

Using tags for monitoring sounds easy in principle. In practice, however, it’s fraught with peril. Javascript collection makes the assumption that the page loaded properly (otherwise, how did you get the Javascript?) It also assumes that the client will run the script (which isn’t the case for many phones, for non-HTML content, and for users with privacy settings turned on.) And the client is sandboxed: For security reasons, the Javascript on the client doesn’t have access to the networking stack or facts about the network. What’s worse, the act of including Javascript can often slow down the page load time. Consider the organizational cost and the amount of technical information you’ll get when things go wrong.

9. Users don’t follow simple paths

Most e-commerce sites like to think they have simple transactions. Users put things in a cart, check out, pay for their goods, and confirm the shipping address. The reality is, users don’t follow proscribed routes. They meander around the site, going backwards and forwards, opening new tabs, changing their minds. For IT operations, what matters more is the health of key steps in a process, and which users encountered problems at those steps. Don’t assume users will do what you expect.

10. It’s always expensive to run things

Many studies have repeatedly shown that the real cost of IT is operational. Eric Dean, CIO of United Airlines, told Forbes that that for every dollar he spends on a package, he must spend $5 to $7 more on consulting to make it work. Network Appliance estimates that for every dollar of storage, users spend $5 to $7 to manage it (though their tools claim to get that down to $2 to $3 — partly due to their appliance focus.) And the Seybold Group estimates that with even standard packaged software, for every dollar spent on software a company spends $5 on consulting, systems integration, and custom programming. So when you’re seeing an IT offering, ask yourself: How much will this cost to run? Will it take care of itself?

Back to the real world

Demos often feature nice, simple sites where users are well behaved, installation is assumed, reports show the right data, and security’s not an issue. That’s the IT sales equivalent of the hero defusing the bomb with two seconds left, then finding an escape pod. It’d be nice, but it’s no way to run a business.

Next time you’re evaluating IT tools, think of the cheap tricks that movies pull to conveniently move the plot along. Then think about how much of what you’re seeing is conveniently tweaked for an ideal story.

We used to run websites, so when we started making tools for web operators, we vowed never to make things that looked better in the demo. In fact, we don’t have demo boxes. We have production units that prospective customers buy. They nearly never come back. We don’t really believe in demos: If the product is going to be useful, you should be using it from day one.

In short: If you can’t get results from it the day you plug it in, it’s probably not going to get used once you sign the check.

I’m going to finish this off with a joke, even though you’ve probably heard it and I may have already given away the punchline.

A software salesperson is killed trying to save a schoolbus full of orphans. St. Peter says, “I’m a little unsure what to do. On the one hand, you gave your life so others could live. On the other hand, you sold software that promised far more than it could actually deliver in the real world. So I don’t know whether you go to heaven or hell.”

The salesperson replies, “well, what’s the difference between the two?”

St. Peter answers, “I’m willing to let you visit both places briefly, if it will help your decision.”

First, St. Peter sends the salesperson to hell. And it’s beautiful! Sunny, clear, with attractive people enjoying delicious food, frolicking in the ocean.

“This is great!” says the salesperson. “If this is hell, I really want to see heaven!”

St. Peter snaps his fingers and they’re in heaven. It’s high above fluffy clouds, with angels singing and playing soft, Enya-like music.

The salesperson thinks for a minute, then says, “I guess I’ll take hell.”

Two weeks later, St. Peter decided to see how his charge was doing. When he got there, he found the poor salesperson in chains, hair singed off, screaming as he was tormented by fireball-tossing imps and succubi.

“How’s it working out?” he asked.

The salesperson sobbed, “this is nothing like the hell I visited two weeks ago! What happened?”

“Oh, I’m sorry,” said St. Peter. “That was the demo.”

I guess the moral of the story is, there’s no substitute for seeing the real thing.

Don’t underestimate the importance of products that do what they say they do, well, the day you get them.

Web applications are typically a complex mix of infrastructure, platforms, services and content. Unlike the mainframe-based applications or LAN client-server applications of the past, no single, simple set of metrics had existed to measure the performance of online applications.

I had an opportunity this week to discuss this issue with four web operations experts at a Coradiant round-table discussion series. Each participant runs very large sites, and each is a clear leader in their respective industries. These four IT executives represented very different industries: A pharmaceutical Software-as-a-Service (SaaS) provider, the highest volume online financial services organization, a regional healthcare provider, and the leading travel industry search site.

Ultimately, the goal is to overcome the visibility gap between IT executives and their web applications. And what’s clear is that watching user experience provides these organizations with a single tool set to measure online performance, find problems and govern IT effectiveness at the senior executive level of the organization. We’ve been working on technology to watch user experience since 2000, and it’s great to see this approach taking hold.

Each of these IT executives uses elements from four major groups of tools, but it’s clear that our User Performance Management (UPM) now gives IT a single, comprehensive capability to perform their jobs well. Because of this — and because UPM focuses on the user- and business-level perspective — it is quickly becoming the prevalent view of web operations health throughout their organizations.

There are four main ways to look at online performance:

• Platform Management: Monitoring the health of hardware platforms and infrastructure that applications run on
• Synthetic Testing: Repeated tests of certain user-initiated web processes using automated test scripts
• Web Analytics: Collecting information to analyze the source of visits, site navigation and buying trends
• User Performance Management: Monitoring actual end user traffic to identify errors and problems and to measure delivered performance

Web analytics and User Performance Management are based on data from user transactions, while synthetic testing and platform management use tests and platform metrics. Web analytics and synthetic tests are often the domain of marketing, while User Performance Management and platform management are more likely to be used by operational teams.

Let’s look at each in detail.

Platform management

The inherent complexity of modern applications means that there is less and less relationship between actual user experience and the health of platforms. A server can be unavailable—but load-balancers may hide the problems so that users aren’t affected. Similarly, a network can be forwarding packets perfectly—but users are getting content errors.

Server logs provide huge chunks of information that is difficult to correlate to actual user problems. Finding problems based on these logs often takes days of complex effort on the part of experts.

Platform monitoring tools are increasingly employed for diagnostic purposes and forensic root cause investigations. Platform monitoring is a necessary, but not sufficient, part of a web monitoring strategy.

Watching platforms tells you whether components functioned; but User Performance Management tells you whether the whole system delivered and what the resulting user experience was.

Web analytics

Web Analytics measures the effectiveness of online campaigns and web conversions. Marketing organizations use web analytics to optimize the process of converting viewers into buyers.

Modern web analytics has evolved into a powerful set of page-tagging and navigational analysis tools integrated into content management systems. Because it is not economical for web operators to capture and store the tremendous amount of information that collection can generate, analytics is most often delivered through a hosted service.

Web analytics shows purchases, lead sources, and search effectiveness, but doesn’t show whether poor performance affects conversions. Failed transactions often go unnoticed.

Analytics shows who did buy; but User Performance Management shows whether they could.

Synthetic testing

Synthetic testing gives an estimate of application performance. Synthetic testing uses scripts to provide a rough baseline to compare performance over time and to compare to competitors. They also act as a “sanity check” when a user complains of performance from a particular region.

Because of their repeatability synthetic testing has been particularly appealing to marketing organizations. Unfortunately, it has also lulled companies into a false sense of security. Modern, dynamic web applications generate unique pages for every visitor, and many of them are one-time transactions. Most organizations answer confidently when someone asks, “is your site working?” But they are far less certain when asked, “is your site broken?”—because someone, somewhere, may be having an error on a page that isn’t being tested.

Synthetic testing shows whether a site is working; but User Performance Management shows whether it is broken.

User Performance Management

Watching real users allows web operators to detect every error as it happens. More importantly, capturing users’ sessions means that there is a record of the failure. This makes it dramatically easier to reproduce, diagnose, and resolve the problem. User Performance Management also means organizations know what each user’s experience was like, as well as how the site really performs under production conditions.

This addresses some of the biggest challenges the panelists had:

• Assuring and effectively reporting service levels
• Finding and fixing problems quickly
• Knowing the effect of changes on their end users
• Real-time visibility into online user experience

Four essential elements

All four monitoring technologies are employed to run web applications. But it is clear that User performance Management gives web operators the ability to deliver fast, error-free, available applications and communicate IT effectiveness with the rest of the business.

I was at a party this weekend and listened to our self-described non-techical hostess introduce me as, “this is Alistair. He does computer stuff.”

Which, while accurate, doesn’t really lead to a rousing chat over drinks.

I began with the usual explanation: “The company I work for makes web performance monitoring equipment.” There were a couple of nods, but mostly the same blank-faced, I-don’t-care look I get when I try to explain a recipe to someone who hates to cook.

I went to my back-up explanation: “You know how you go to a website, and it’s really slow? Or you get one of those 404 errors?” (nods from everyone, with a couple of MySpace and YouTube complaints thrown in.) “Well, we fix that.” A bit more understanding, but not a lot of excitement.

So I tried a new one. It’s not really a new explanation, but as more CIOs and directors get their hands on TrueSight and our Real User Monitoring data, it’s a conversation I’m having more and more. I took a drink, and continued:

“You know how geeks like me are always talking about networks, and computers, and browsers … and you don’t care?”

Vigorous nods from everyone (eager for me to shut up so they can go get another glass of wine or look at our hostess’ spectacular apartment.)

“And you know how business, rather than caring about the geek stuff, worries about people — customers, employees, and so on?”

More nods.

“Well, we let the geeks talk about users, so the business finally understands them. In other words, watching real users makes IT matter to the business.”

Much better. All of a sudden they cared.

It’s true. We used to sell to the web operators who had to handle incidents and answer phones, who lived a life of blame and conference calls. They’re our most active users and eager proponents.

But now, along with those guys, the executives in the company are getting involved. They’re frustrated by the huge disconnect between what the IT team does — servers, networks, and applications — and what the business is about. And they’re looking for ways to get IT and the business working together.
The first step is to get them talking. For years now, IT and business haven’t been speaking the same language. And it’s been a source of huge problems; IT has useful information that business doesn’t care about; and the business has goals for its IT infrastructure that IT can’t turn into meaningful, measurable goals.

As more and more people in an organization get access to Real User data (what we call, Pervaisive Real User Intelligence,) it’s amazing just what an impact it has on the way the organization operates. Not only does it get easier to fix problems and resolve disputes, but businesspeople start being engaged in the IT systems themselves.

I think the British TV show The IT Crowd said it best. I haven’t seen the episode in a while, so some of it may be NSFW. But the first five minutes of this episode pretty much sum up a traditional business view of IT. If you’re in IT, and you’re not talking about real users, the business probably doesn’t understand what you’re saying.