Monitor the most important websites in e-commerce

If you continuously monitor websites and especially online stores, then you have to think about a sensible structure of the checks in order to achieve the densest possible coverage of possible problems with the least possible effort.

A very common method to achieve this is the creation of component classes - academically also called equivalence classes. But what does this mean? Let's imagine we have a store with 5,000 items. It makes absolutely no sense to check all these pages for function every hour, because the article pages are technically all almost identical. In this case, only one page per technical implementation should be checked continuously. You then assume that if one page is working, all of them are working or the other way around, if one is broken, then they are all broken.

In theory, this is true, but it is possible to break something due to editorial or configurational differences. In most cases, though, it's not worth monitoring for. One would rely on a weekly crawling and check there again all pages on heart and kidneys.

Components in e-commerce

The good thing about e-commerce is that it's usually pretty standardizable. In fact, you usually start with the same base. Shopware, Magento or WooCommerce. The different components you start with are then always similar:

• Home page
• article page
• Category page
• Search results page
• Content page

All these pages are built differently by the store system, so they have different source code. In addition to the actual store pages, we have a few other page groups, which may not be technically very different, but are important for the store in terms of content or law.

• imprint page
• privacy page
• general terms and conditions

These were now the pages that the customer sees and can interact with. But there are also technical pages that are relevant for the success of his online store, which the user does not see at all.

• sitemap.xml
• robots.txt

If you have all these components of your online store in the monitoring, then you can be relatively sure that the user will be able to look around the store without any problems.

Which URLs should be chosen?

After you have determined the page types, you still have to choose the appropriate representative. These are always URLs from the store. Here you can choose two approaches:

• Particularly extensive pages:** Here you build pages especially for the test, which try to unite all functionalities of a class in itself. This makes a lot of sense for example with article pages or content pages. We take e.g. a product, deposit many variants, a video, additional texts, links to other articles and and and. If there are then somewhere problems with the rendering of the article page, this error should also occur on this page.

• Particularly important pages: Instead of creating a synthetic page, you can also take a particularly important page into the monitoring. So one would take the most sold product. Surely, this way you won't find all important errors, but you can be sure that the most important pages are working.

As always, the truth lies in the middle and a combination of the two selection methods certainly makes sense.

Since koality.io was built around this very concept, we offer these pages for monitoring. In many cases we even find them automatically.