Case study: Alina Cosmetics luxurious online shop

Goals & challenges

The main goal of the project was to establish a new online shop with a focus on German-speaking markets (DACH region) which was to offer a wide range of cosmetics brands. This included premium brands, like Chanel, which are notorious for their online presence compliance requirements.

Also, a goal was to establish a platform for content marketing, storytelling and seamless customer experience, not just a typical shop with product listing. Marrying content and commerce is not a trivial thing and requires deeper UX considerations and custom development. I wrote a post on the topic five years ago: Importance of integrating e-commerce content management deeper. The market, in general, has improved since then, but the topic is still a challenge. 

Finally, the goal was to build the customer base, supported by numerous important shop capabilities. From adding gifts and testers to the order to simple returns and refunds. Building trust is a slow process with attention to details.

To achieve all that we had to jump through a lot of hurdles. 

First of all, the client had an ERP but with no simple way to get products and submit order transactions. The API to support that was being in the making by a 3rd party while we were developing the shop. It was like a moving target and required a lot of adapting and testing cycles. 

As expected, product data was rudimentary in the ERP and there was more product information & content but managed separately. Besides products, the ERP was the source of truth for categories, promotions, prices and stock as well. As those data can change very often for many products we had to have a relatively fast way of refreshing data on the shop side. 

The challenge was also the complexity of the product data. There was a rich set of meta data and many ways of categorising products. For example, each product had:

• Brand name
• Sizes
• Skin types
• Colours
• Is it a new product
• Is it a premium product
• Does it include a gift?
• ...

This required a lot of focus on product findability experience, making it simple for customers to find the product they are looking for. Also, some of this data, like the size of the perfume, dictates its price, hence its a variant. Variants should have links for SEO purposes, but the overall product should also exist as an anchor for product-related content. Having both makes the search index more complicated. 

Multi-skilled team

To meet these challenges, the project team was assembled from two partners:

• Reichl und Partner eMarketing, as a leader handled the client and the 3rd party communication, project management, UX/UI, prototyping, visual design, content and information architecture, CSS, eZ Platform content features (all except products)
• Netgen, together with specialised associates and our partner Locastic, handled architecture, installation, devops, deployments, integrations, customizations and development in general in Sylius and eZ Platform (product features)

Customer experience

A lot of effort was put into optimizing the customer experience. There are already established patterns and shablons that customers expect when they shop online. They want pictures of the product, prominent buy buttons, visible steps of the checkout process, etc. Still, there is a lot to improve on, from pure visual design to helpful backend features, from enough options to fast performance. 

While Reichl und Partner eMarketing focused on the UX/UI, we focused on implementing performance features that support the customers' expectations. 

For example, the product search and filter functionality is something that every shop covers in some way but only a few make it powerful and fast for the end-user. To make that page slick we opted to do a React based page which handled the state for facets, filtering, sorting and paging on the client side. This is backed by a REST endpoint that leverages Solr search, spell checking and faceting features. The result is a product finder page that works pretty fast providing easy drill down to the desired product. 

Architecture

On a very high level there is a:

• ERP as a source of truth for products, variants, categories, prices, discounts and stock,
  • data exposed as XML files via SFTP (full data & delta data), 
  • shipment statuses
  • realtime check of stock
  • order/refund submits
• Sylius eCommerce instance which handles the buying process from the basket to payment. It syncs data from ERP on a regular basis. It handles VATs, shipping costs, gifts, teasers, returns & refunds, short time stock calculations, basket based discounts, coupons for friends. Invoices, GTM, 
• eZ CMS instance which shows content including products. Product content is enriched via additional imports of images, descriptions, etc. It uses Solr to index content and provide performant faceted search 
• Payment providers
• Email sender system for transactional emails and newsletters
• Varnish as a reverse proxy in front of eZ (traffic to shop just passes thru)
• Cloudinary for storing, processing and delivering images
• RabbitMQ as a message bus for asynchronous tasks

The flow of data starts from the ERP. Delta imports are processed on a regular basis to have the product information in Sylius necessary for the checkout process and ordering. This includes variants, prices, categories, promotion and stock. Full import is available on demand.

Once a new product has been imported into Sylius or an existing one changed, it gets synced to eZ Platform CMS. If it's a new product, it is not visible on the site yet, as it needs to be enriched with images and other product information. Visibility is controlled with eZ Object State functionality but it's not available for manual control, rather calculated based on ERP product status code and Sylius product approval status. Editors are able to approve the product in the shop administration interface once they are ready to release it, this will automatically propagate to the CMS and the product will be listed on the site.

Varnish is used for performance reasons on all eZ generated pages. All images are stored, processed and delivered by Cloudinary which also takes load from the eZ instance.

Once it's visible and indexed it can be found and put in the basket in Sylius. Standard eZ Platform search has been customized with custom content sub-documents in order to enable searching for Products while defining grouped conditions on Variants. 

Although eZ and Sylius are two separate instances the add to basket action is seamless to the customer, the only visible difference is in the domain URL (Sylius is on the subdomain “shop”).

The user can then login, register or proceed as a guest and pay for the order. Even though the stock information is updated regularly, there is always a live stock check performed when adding the product to the basket to avoid orders of product not in stock. With payment processed successfully by one of the payment providers, a new order is submitted to ERP, related emails are sent out, etc.

 The customer can check the shipment status, information coming from ERP. Users can also download the invoice, also generated by the ERP. Customers can get a refund which is handled in Sylius and visible on the order history.

Content for eCommerce

As already mentioned, marrying content and commerce is not easy. There are many solutions and different ways how you can set it up — but the end result is what matters. For this project, we wanted to give the editors the ability to enrich the shop with content as much as possible and to be able to manage the content efficiently. 

Besides the typical CMS content types, we introduced several new ones which are mostly synchronized from Sylius and ERP so they are automatically created in the CMS. Editors then just add the rich content. 

Here is the list of the most important content types used in the project:

• The Promotion synchronized from Sylius that is reversely linked to a Product Variant. This means we have the list of variants listed on the Promotion page for which the promotion applies, but also in product listings we know what promotion is currently running for each product. 
• The Brand type can group all products of the same brand and show some specific information.
• The Product is synchronized from Sylius, enriched with images, description, etc.
• The Product Variant synchronized from Sylius.
• The Product Category for building a hierarchy, synchronized from Sylius category taxon subtree.

The Promotion and Brand are particularly interesting as they are used for story-building and inbound marketing efforts.

Custom eCommerce features

Standard Sylius features are leveraged as much as possible. This includes basket, user management, configurable checkout process with shipping & discounts, payment integrations, VAT management (different VAT per country), channel management (different rules per country). 

Still, the devil is in the details, so we developed a lot of additional features like the following: 

• When the user A gives an affiliate code to user B, and the user B makes one purchase, the user A will receive a coupon code at that point
• Gifts are products automatically given to the user if there is a promotion with matched rules
• Tester products are special products which are also not listed in the cart, but there is a special selection at the bottom of the cart, where the user can select on a free product they would like to receive
• Multiple promotions can be calculated on the same order
• In total three are 8 custom promotions and 3 related actions

All these features sum up to a better customer experience, furthermore to better sales numbers.

Conclusion 

The project was successfully launched and improved ever since. The technology stack proved to be flexible for all new improvements and tunings. But the most important thing achieved was the seamless customer experience combined with relevant storytelling tooling.