Our decision in favor of Fredhopper was based on different aspects. The system offers an easy-to-use user interface, high availability and is highly scalable thanks to the cloud connection. But Fredhopper is more than just a simple search engine. The recommendation engine enables product recommendations based on user data, which means that the results presented can be highly personalized. This so-called ranking cocktail can be gradually refined so that our customer is slowly introduced to the topic. If you now look at all pages of an online store as a search, the full potential of Fredhopper opens up. Personalized recommendations can be displayed on each page in the frontend and the products can be displayed in the order relevant to the customer. There are also configurable campaigns. Last but not least, our expertise in connecting Fredhopper to Hybris systems also helped in the decision in favor of Fredhopper.
project flow
Before implementation, the individual use cases were first outlined. Campaigns should appear on static and dynamic pages, in the shopping cart, and when an item is added to the cart. But how should the selection of the products to be displayed be made? On the static pages we use campaigns configured by our customer. As a result, the presentation of the static content is completely in the hands of our customers. For dynamic pages (e.g. category pages), we rely on campaigns that are based on the content displayed. Product or assortment-specific campaigns are used in the shopping cart process to inspire store customers to make further purchases.
Following the specification of the use cases, it was clarified which information is transmitted to the Fredhopper system. Not only the data required for displaying the front end was relevant for this, but also the information that Fredhopper used to select the products. This information resulted in the data model for Fredhopper.
The data is imported into Fredhopper via a daily full export from the Hybris system, plus delta exports executed several times a day. This export from the Hybris system was addressed first during implementation. We were able to use the specified data model right from the start when implementing the communication between the frontend and Fredhopper.
The communication between the systems takes place via the API provided by Fredhopper, which significantly increased the speed of implementation. This allowed us to concentrate on interpreting the data provided by the interface for the frontend. Here, the effort could also be minimized by reusing beans already used in the frontend.
Exports out of hybris
A Hybris CronJob transfers the complete product data to Fredhopper once a day. For the full export, all the data of the products and their variants are read out and further values are calculated. This data is then written to a tab-delimited CSV file. In addition, the stocks and approval status are updated several times a day so that only available items are displayed in the shop front end.
Playing out the data in the frontend
First of all, services had to be written in order to prepare the data supplied by Fredhopper accordingly. The goal of being able to reuse the already existing beans of the Solr search to be replaced led to a major conversion of the providers, which now all had to be filled with Fredhopper data. It should be noted here that the shop works entirely via the search function, even navigation links are implemented via the search function. If a new link is to appear in the navigation, all you have to do is create a corresponding link in the CMS system and link it to a search query. Thus, the customer has the navigation in his own hands and can quickly make corrections independently.
In addition, new campaigns should be implemented with the change of search engine, existing ones can also be configured via Fredhopper. The campaigns can now also be controlled via the CMS. Here, too, existing beans and templates were used for the display. The complexity here lay in the nature of individual campaigns that were supposed to auto