In Part 1 of this 2 part blog series, we looked at the key metrics that are useful to different stakeholders in an IBM WebSphere Commerce (WSC) environment. To recap, one key component to successfully manage an online retail site is the ability to share data with all stakeholders from the same tool as it eliminates any confusion about the source of the data. In this blog, we want to showcase the effective collaboration between different stakeholders using the same tool using a real life example.
The sales funnel is an easy and powerful way for the business users to find out if any issues with user experience are affecting overall sales, and where in the funnel the issue is occurring. With increasing investment in digital marketing comes an expectation for sales growth, so maximizing every single visitor transaction from start to finish is vital.
In our example above, you can see that the Search Page Health did not look healthy, as the response time on that page had gone higher than the normal. It could be one reason why the conversion rate dropped in the given time period. This violation automatically triggered an alert for the IT operations group. As seen below, the IT operations dashboard clearly indicates the response time hovering over 4s instead of taking under 400ms.
In order to go deeper into the root cause, IT operations likes to immediately know whether it is a host/infrastructure issue or an application issue. The transaction flow diagram shown below not only told the IT operations that the host is healthy but also told them the exact tier that was contributing the most to the slow response time.
Having the knowledge that the issue was caused by application code, the IT operations team got the development/architecture team involved to find the root cause. Using the same tool and dataset, the development team immediately started looking into individual transactions that were contributing to the high response time. Going deeper into individual transactions instantly told the developers/architects that the host name lookup by IP address was causing the delay in the response time.
By looking up this pattern on the Internet, they found that this could have been caused due to DNS lookup. In order to prove this theory, they first set some host file entries so that the lookup would be resolved almost instantaneously via the host file. Running the same test with the host file entries in place revealed a drastic improvement in performance. The method getHostByAddr was now taking less than 1ms and the overall transaction time was down from 5 seconds to 361ms.
This also indicated that the problem was not with the code, but with the DNS Lookup itself. The team replaced their default DNS server in their development environment with Google’s free public DNS servers in order to determine if the problem lies there. Below, we can see a comparison of the two transactions, one with the poor performing DNS server on the right, the temporary Google DNS server on the left. DNS Lookup was still under 1ms. Based on this evidence, the architects made a recommendation to remediate the slow DNS server.
There are many reasons why a customer might not follow through on a purchase, but performance should not be one of them. Abandonment by customers due to poor user experience not only affects the revenue but also damages the brand.
Proper monitoring of online commerce sites through a single tool allows business, operations and development to work together seamlessly to rapidly identify and resolve user experience degradations that can impact the bottom line.