A picture speaks louder than a thousand words! Messages conveyed using a visual medium are always more impactful and reaches the audience more quickly. This is the philosophy that drives eG’s Real User Monitor Dashboard (see Figure 1).
To access this dashboard, click on the Real User Monitoring option in the Dashboards tile of the Monitor menu.
With the help of a bevy of visual tools – eg., intuitive icons, color-coded values, miniature graphs, geo maps, etc. - this real-time dashboard helps administrators understand, from just a glance, the following:
- How is the traffic to the managed web sites/web applications in your environment? Is the traffic to any web site/web application suspiciously high or low?
- From which devices is this traffic coming from – desktops? Mobile phones? Or tablets? Which is the most popular device
How many distinct users are currently connected to each web site / web application being monitored? - this is a good indicator of the number of users who are truly contributing to the traffic on the web site.
This way, the dashboard facilitates the rapid identification of web sites/web applications in your environment that do not enjoy user confidence and the probable reasons for this unfavorable user perception.
This way, the Real User Monitor Dashboard takes you from the problem symptoms to the problem source in no time!
The dashboard of Figure 3 supports an array of icons (see Figure 4) in its left panel, which when clicked enables you to review and analyze different facets of real user experience with the chosen web site/application.
By default, the Overview option is selected. As a result, Figure 3 appears by default, which provides an overview of the user experience with the target application.
Overview of User Experience
The Overview also points you to the countries and page groups in which high page load time has been observed.
User Experience Analysis Across Geographies
Without requiring you to pour over tens of metrics, the Geo Map in Figure 6 quickly tells you where your users are. Location markers accurately pinpoint the countries from which the requests are flowing into the web site / web application. The size of the location marker varies according to the number of requests from each country- i.e., larger the marker, higher will be the number of page view requests from that country. Also, to indicate the experience of users from a country, both that country and its corresponding marker are colored using conventional color-codes. This way, the map intelligently differentiates between the “happy” countries and the “unhappy” ones.
At any given point in time, you can choose to view only the request indicators - i.e., the markers - or the response time indicators - i.e., the countries colored using conventional color-codes - in the map. For instance, to hide the markers, click on the button below the map, and uncheck the Requests check box. To hide the colored countries, uncheck the Response time check box (see Figure 7).
You can also choose to view in the map, only those countries with a poor user experience. For this, you may want to uncheck the Normal check box in Figure 7, and check the Major, Minor, Critical, and/or Unknown check boxes therein.
If users from a country are experiencing slowness, it is only natural that you want to figure out whether the problem is widespread or is confined to a specific region within that country. This can be easily determined by zooming into a problem country in the map! For this, just select the country you want to focus on from the Country drop-down list in the Geo Map. Figure 9 will then appear revealing the exact regions (in that country) from which requests are received and the overall experience of the users from each region.
Likewise, you can quickly drill-down from a region to view the cities in that region and the quality of their experience with the web site / web application. For this city-level view, select a Country and then a Region from the Geo Map. Figure 10 will then appear. Using Figure 10, you can precisely pinpoint the city that is experiencing slowness.
If the Geo Map reveals that users coming from a particular country/city/region are experiencing slowness, then you may want where such users are seeing the maximum slowness - is it at the browser level? during content download? in the network? or during backend server processing? At the same time, you may want to verify whether the type of device used by the users from a specific country/city/region are impacting their experience with the application, and if so, in what way. The Response Time Breakup section in this geographical view enables this dual analysis (see Figure 11). The contents of this section will vary depending upon the option you choose from the Geo Map drop-down. For instance, if the Countries option is chosen from the Geo Map drop-down, then the Response Time Breakup section will display distribution pie charts revealing where application users from across all the countries in the world are spending their time. Likewise, if you choose a specific Country from that drop-down, then the Response Time Breakup will provide the breakup of response time for all users from that country alone.
Also, by default, the Response Time Breakup section presents the breakup of the response time of all application users, regardless of what type of device they are using. This is why, the End-user icon in this section is selected by default. If required, you can use this section to analyze the experience of users depending upon the device type they use. For instance, click on Desktop icon in this section to know where desktop users are experiencing a bottleneck (Figure 11).
If the Geo Map reveals that users coming from a particular country/city/region are experiencing slowness, then you may want to figure out which page groups accessed by the users from that country/city/region are the slowest. This is where the Top-5 Slow Page Groups <Countries/Regions/Cities> list helps. Depending upon the geography you zoom into in your Geo Map - whether it is for the world over, a particular country, or a specific region - this list will display the top-5 page groups in that geography in terms of responsiveness. For example, if Countries is chosen from the drop-down in your Geo Map, then the top-5 list will display the top-5 'least responsive' page groups accessed by application users across the world (see Figure 12).
Response Time Analysis
Using the Response Time Breakup section in Figure 13, you can easily and effectively analyze the response time per device type - i.e., desktops, mobiles, and tablets. A quick look at this visual representation will tell you if users using a specific type of device are seeing more slowness than the others.
You can also compare the responsiveness of a specific URL across device types by selecting the URL of interest to you from the All URLs drop-down. This will reveal the devices from which the URL has been accessed and the response time of the URL as seen as by the users of each device (see Figure 14). You will thus be able to tell whether the URL was slow across the board, or was slow for the users of certain device types only. This way, you can figure out if the poor application performance that the users of certain device types are experiencing is because the application is not optimized to handle requests for certain URLs from certain device types.
The Response Time Breakup section also reveals the probable cause for poor UX with the application - is it owing to a slowness at the browser end? a latent network? delay in content loading? or a processing bottleneck on the backend server? Note that this insight is provided at the application-level and not at the device type/URL level. If the section reveals that high network connection time is the reason for the poor responsiveness of the application, you can click on the 'magnifying glass' icon alongside Network Connection Time to view a break-up of that metric. This way, you can accurately diagnose the reason why network connections to the application took too long. Additionally, you can also identify those URLs that were badly hit by high network connection time (see Figure 15).
On the other hand, if the section reveals that high content downloading time is the reason for the poor responsiveness of the application, you can click on the 'magnifying glass' icon alongside Content DownloadTime to view a break-up of that metric. This way, you can accurately diagnose the reason why content downloading took too long. Additionally, you can also identify those URLs that were badly hit by high content download time (see Figure 16).
When viewed together with the per-device response time, this application-level response time breakup also reveals if the slowness at the browser, network, server, and/or content download areas has impacted all users or only users of a few specific device types. Typically, if an application is not optimized to handle requests from certain device types, then such requests may end up spending more time on the browser, network, server, and/or content downloading. Using Figure 16 therefore, you can identify those device types that the application is not optimized to support and where such optimizations should be performed.
Similarly, you can analyze responsiveness at the page group-level by selecting the Page Groups option from the Response Time Breakup drop-down (see Figure 17).
Using Figure 17, you can analyze the performance of the top-5 'least responsive' page groups in the target application. The response time of and the load imposed by (page views/minute and current sessions) each page group is displayed therein. This way, you can identify the page groups with which application users are having the maximum trouble! Here again, the response time break-up (browser time, network time, server time, and content download time) is presented at the application-level (and not at the page group-level). Using the break-up, you can determine why user experience with the application is poor. When correlating the application-level response time breakup with the page group-level analytics, you can figure out if the slowness that users are seeing on the browser, network, content processing, and/or are impacting all application users or only those accessing specific page groups. Sometimes, certain page groups in the application may not be engineered right to handle user requests. This inefficiency may manifest as high browser time, network time, server time, or even content download time. Figure 17 will point you to those page groups that may need fine-tuning.
User Experience Analysis Across Devices
User Experience Analysis by URL
By default, the Page Views drop-down in Figure 19 is set to All URLs. Accordingly, this section reveals the total page view requests to the target application and the count of slow, healthy, and error page views. This will reveal if there are any URLs in the target that are loading slowly. If this representation reveals slow page views, then you can scroll down to view a summary of the slow page views, as depicted by Figure 20.
In this summary, you will be able to view the break-up of page load time on one side - i.e., browser time, network time, server time, and content download time. Clicking on any component of page load time will list the top-5 URLs that registered the maximum value for that component. In other words, if say Browser Time is chosen, then the top-5 URLs with the highest browser time will be displayed. In the process, you can figure out where your bottlenecks lie, and which URLs are impacted by these bottlenecks.
If you want to focus on the responsiveness of a particular URL, then select that URL from the Page Views drop-down in Figure 19. The Page Views section will then graphically represent the experience of users hitting that URL alone (see Figure 21).
Analysis by Usage
To cross-correlate across usage analytics related to the target application and to study usage trends, click on the Usage icon in the array of icons (see Figure 4) in the left panel of the dashboard. Figure 22 will then appear.
Using the Page views vs Page load time graph in Figure 22, you can easily time-correlate page view requests with page load time for the last one hour. In the process, you can figure out if page load time increased consistently, or only when page views increased. If the page load time keeps increasing regardless of the count of page views, you may need to investigate the reasons for the same. On the other hand, if application responsiveness deteriorates only when the traffic to the application increases, it could only mean that the application is not optimized to handle heavy loads.
Using the Trend of Page Load Time graph in Figure 23, you can understand where your page view requests have spent most of their time in the last one hour - at the browser? on the network? in the backend server? or in content downloading? This will accurately reveal where your bottlenecks lie and where you need to focus your engineering efforts.
You can then analyze user experience trends using the Trend of User Experience graph in Figure 23. With the help of this graph, you can figure out whether the user experience with your application has been satisfactory or not during the last hour. Disturbing trends in user experience come to light in the process, so you can initiate measures to negate this trend before it becomes worse!
To view the most popular browsers and devices, in terms of the page view requests coming from them, use the Page Views by Device and Page Views by Browser distribution pie charts in Figure 23. To make sure that your application delivers an above-par experience to a majority of your users, optimize your application to offer the best support to these popular browsers and devices.