Comparison websites are now for most Germans the most important piece on the web. According to a 2013 study by consumer research firm Gfk, more than 70 percent of German Internet surfers are already using comparison websites to complete online contracts or to shop online. The most popular themes: leisure travel, energy tariffs and insurance. According to the statista.de more than two thirds of all requests in the insurance sector in 2014 were made via the comparison website check24.de.

For the insurance provider – or travel broker, online retailer, etc. – this means conversely that favorable placement in the check24.de results is now a key success factor for their online business.

But how it is possible for an insurance company to be displayed at the first results of a comparison website as check24.de? Interestingly, the insurer’s own IT plays a central role.

Respond in time shorter than 6 seconds – or you’re out?

As a bit of background, you should know that the comparison websites forward requests on behalf of its visitors as a SOAP web services request to the respective insurance companies. Only those companies who manage to respond to the request within six seconds have their offer included in the results. If this threshold is exceeded, the offer will be not displayed. The portal visitor remains unaware of the failure, and will likely opt for a provider whose offer is displayed in the comparison – essentially, a provider who responds within the six-second window. A “too-slow” insurer loses the opportunity to compete, and the transaction will be ultimately made with a competitor.

As part of an End User Experience monitoring test project for one of the largest German insurance companies, Amasol got the task of finding an answer to the question of how to ensure that its offers are reliably displayed in the results of major comparison websites, particularly at CHECK24.de.

Error analysis with the Dynatrace Real User Monitoring

With a network-based Real User Monitoring solution from Dynatrace (DC RUM) it was possible to verify when requests were completed and correctly delivered to the comparison website and when the requests missed the “six-second-hurdle,” failing to appear in the results at Check24.de. (See Figure 1)

Figure 1
Figure 1

Examining additional details, we determined that performance problems always came shortly after 18 o’clock and that most of requests could not complete within the required six-second response time window, resulting therefore in the above-described negative consequences for the online business of the insurer (see Figures 2, 3, 4)

Figure 2
Figure 2
Figure 3
Figure 3
Figure 4
Figure 4

Armed with this knowledge, a more specific root-cause analysis has been conducted, with the result that the problem could be isolated and resolved to a specific database behavior.

As part of their ongoing continual service improvement, the insurance company will continue to use the Advanced Deep Dive Analysis function of Dynatrace in order to investigate the causes of backend delays, quickly and accurately isolating and analyzing new problems before they disrupt business goals.

Lessons learned from this application example

As a user, if you use a comparison site like Check24.de, keep in mind that you may not necessarily get the lowest rates in the results, but rather the offers that meet the limits imposed by the comparison site – such as the six-second limit. You may never get to see competing offers from “slow providers”, even if they might have more attractive prices or options.

If your company operates in an industry where these comparison websites play an important role for successful online business, then this application example should encourage you to review your performance monitoring processes.

It is critical in the world of e-business to monitor all transactions and to analyze their performance. Traditional monitoring methods such as the consideration of average response times per application, synthetic tests or sampling/sample analysis are no longer sufficient. In fact, the problem we discuss in this blog would indeed remain mostly – or even completely – hidden if using these traditional performance monitoring approaches, and the insurance company would continue to miss out on important sales opportunities; what’s worse is that they would remain unaware of the problem.