Introduction

Recommendations are products that are presented as an additional offer. They may occur on any page in an online store. You often find them on product (detail) pages and on the shopping cart page. Recommendations are often located at the bottom of the page and are introduced with headings like "You might also be interested in", "Customers who bought this item also bought" or "What other items do customers uuy after viewing this item?". These kinds of recommendations are based on product(s)-to-product(s) recommendations. This means, the user gets recommendations for products in relation to one or more other products. There are some other recommendation options, like search recommendations (based on a search term), category recommendations (category-to-products) and recommendations without direct input parameter, e.g. "Top Sellers".

There are two ways to provide recommendations for products:

• Static links:
  This means that a recommendation product is directly linked to another product. If one of the products is viewed, the recommendation product will be displayed. This is useful if you want to recommend, e.g., a mouse, a keyboard and a monitor for every notebook you have in the store. These kinds of recommendations are handled with product and category links within the Intershop 7 system. They are not in the scope of this documentation.

• Dynamic links:
  The second way is used by bigger online stores like Amazon, HP, eBay and so on. In this case, the recommended products are determined dynamically based on the behavior of users in the online store. This can be achieved by using a recommendation engine. This approach is explained in detail below.

To provide recommendations that are based on the user behavior, recommendation engines observe all actions in an online shop (like product A viewed, product B ordered, etc.) and store this information to compute relevant recommendation products at the end. For this observation, recommendation engines use events that are provided by Business Tracking events. There are events for the most important actions that can be done in a web shop (view product xy, add product xy to cart, order product xy, search for product xy). The relevant questions for recommendation engines are: which products customer X looked at while visiting the store, which products the customer put in the shopping cart and which products the customer ordered within one customer's shopping session. That's why it is necessary to tag all events with a session ID to ensure a valid data basis where all events are stored grouped by session to determine the related ones. In Responsive Starter Store the storefront session ID is used for that. Since the REST API is stateless and does not know any sessions, the term of recommendation context has been introduced. A recommendation context is just a simple string that is used as a replacement for the session ID. For recommendation engines it has no semantic meaning, it just symbolizes that events with the same ID belong to one session.

Every engine should have a TrackingEventHandler that is registered to one or more events in which the engine is interested. Different engines may use different events. Requests are used to fetch recommended products from the recommendation engine. In most cases, one or more products are used as input parameter(s), and the output is a list of recommended products that are computed from the input.

Both artifacts are described in detail in the following sections.

Events

Structure

There are Java interfaces for all events that are supported. An implementation of a recommendation engine has to implement Java classes for the events that implement these event interfaces. These event classes normally extend an abstract superclass that contains some common logic for this recommendation engine implementation. If an event class is created for a concrete recommendation engine implementation, this event can be selected in the back office of the engine.

Business Tracking

As mentioned before, the recommendation component uses events from the business tracking to evaluate the storefront behavior.

In this context, two different topics have to be considered:

• First, the collection and evaluation of storefront events with a TrackingEventHandler.

• Second, an integration of tracking related data is possible through TrackingSFI (Tracking Storefront integration).

Both aspects are explained below.

TrackingEventHandler

The adapter cartridge for a recommendation engine should provide an implementation of a TrackingEventHandler that is registered to receive storefront events. The TrackingEventHandler evaluates those events, and depending on the type of event, it stores additional information in a data container to maintain information about the event. The events themselves are lost after being consumed. For example, if a ProductAddToBasket event is received, the handler stores the product ID (SKU) and the quantity in this container. The data container is provided to the storefront components via TrackingSFI interface.

More information about TrackingEventHandler can be found in Concept - Business Tracking | TrackingEventHandler and in Cookbook - Business Tracking.

TrackingSFI

The TrackingSFI(long name: Tracking Storefront Integration) interface allows all registered services to integrate a header and a footer template into the DefaultPageStructure template, which is the base template for all pages. Both templates can be provided by TrackingSFI implementation using the fixed names MainFrameHeader and MainFrameFooter as template IDs. The header template is normally used to add your JavaScript code or includes at the end of the HTML header section. The footer template usually contains the code to send the events to the recommendation engine.

Requests

Structure

In accordance with event interfaces, there are also Java interfaces for all requests that are supported. An implementation of a recommendation engine has to define Java classes for all requests that are declared in the implemented request interfaces. These request classes normally extend the same abstract superclass as do event classes. This superclass may contain some common logic for this recommendation engine implementation. If a request class is created for a specific recommendation engine implementation, this request can be selected in the back office of the engine.

Storefront Integration/Components

As mentioned above, the TrackingSFI interface is used for events to integrate the event templates into the storefront. This way only works with events; the integration of requests works completely different. Requests need CMS components that include the request templates.

At the moment, there are two default CMS components for recommendations regarding product-to-products-recommendations:

• used on the product detail page, and

• used on the shopping basket/cart page

These components have to be added to the storefront pages. For information about using the components, see Cookbook - Recommendation | Recipe: Include Recommendation Components In the Storefront.