How we achieved differential product page experience at Myntra
This article explains the changes we made to the product detail page and downstream services at Myntra (India’s biggest fashion destination) which has enabled us to achieve configurability thereby provide differential experience to our users.
The article also explains why we built system which is capable of achieving differential selling experience for different products to different users on our product description page in Myntra mobile applications.
Before we built the platform, we already had some of the capabilities to achieve differential experience based on certain conditions. But all of this logic was at the client end, which means, once we push the application to Store, there is no way to control the behaviour on the fly.
Some of the configurability / differential experience we had earlier were:
- Display different sections of the product display page in different order based on article type.
- Gracefully downgrade user experience in slower network / low end devices. We made following changes: All the widgets which required to be loaded lazily over the network after the core product details load were made on demand (user had to tab on the sections explicitly to view the content) , no rich content like videos or 360 degree images, loading lower quality images (using cloudinary). We also built ability to add the product to cart even before the complete product got loaded, just by using product gist passed down from the product listing page to detail page.
- Hide some of the sections based on article types (ex: Social widgets hidden for Lingeries).
- We of course had a full fledged AB testing platform which is used for experiments and rollouts in product page.
The limitation of this is that there are limited set of capabilities and all the logic resides at the client end, which meant once the application is distributed to user, there is no way to change the rules dynamically. There is now way to achieve personalised experience at the user level based on his/her past usage of the application.
Moving the configurability to the server
In order to overcome these constraints, we considered building a generic platform which takes various inputs and sends back a baked response to the client which has all the details to give personalised and differential experience to the user just by rendering the widgets in the same order at the client end. The inputs are different types attributes based on which we wanted to differentiate the look and feel of the product page. Now instead of client making all the decisions, all the inputs are read by the service which sends the response to the client, it makes all the necessary changes to response in a format that the client understands. Some of the dimensions based on which the the page can be configurable are:
- Platform: Different experience for iOS and Android.
- Tenant: Different reposes to different tenants. Based on Myntra or non Myntra.
- Network Quality / Type: Client sends this in request headers to enable service to take decisions based on network. Some of the rich components are not omitted or made on demand.
- AB Test: All AB tests are handled at the service end and clients presentation of things changes based on response. The response differs based on AB tests.
- Product attributes: The response differs based on product attributes like, product category, gender, article type, price range.
- Brands: So that different brand product pages can look differently based on the brand preference
- User: The ideas was to build the platform that can take inputs from our data science team and achieve differential experience based on users past interactions and preferences.
Also, these rules can be combined to form a complex rules like if brand is nike and price is greater than 5K and article type is sports shoes show a different kind of page. This will give a massive configurability of the page based on product attributes and have desired differential experience.
Just like the product attributes can be used to form a complex rule. The platform supports configurability based complex rules formed by using different configurability dimensions. Ex: if network type is 2G and Platform is Android and brand is nike or puma, display the page in a certain way. This gives configurability to combine all the dimensions and render the page which is best suited for the user for the article he is viewing, his network and platform.
There were the motivation to build the new platform that supports configurability based on various dimensions.
How?
Componentization!
We divided each logically / visually separate widget into a UX block called a component. A list of these components in any order forms a cards. The product page is a list of cards in a certain order (core card, brand card, similar card etc)! Example below:
Style Note, Similar (two components, similar products and cross links)and more information cards! Also note how the card are visually separated.
The client understands and renders a list of cards each of which is a list of components. The service gives data required to render each of the component and there components are in a specific order and rendered in the same order on the screen. Even the cards are ordered in a certain way. These orders are determined by various factors explained before. There are multiple layouts defined, each with a specific order of components (and configurations within the component like text, colour, styles) and cards and a layout is picked by the server based on different parameters and response is served to client.
By dividing the screen this way and building the system which returns such a response we can easily determine what is the order of different components shown to the user, what all are the components shown, what all components are logically clubbed to form a card and the order of rendering of the cards. The response is a function of all the dimensions upon which the page is configurable (all the dimensions are explained before). The rules which determine the order of components can be changes on the fly and users start seeing the changes in components orders on the fly!
Since all the configurability is at the service end and client understands the order, any new changes will get reflected in all the versions of the application. It is easy to incorporate inputs from the data science team and modify the components based on user preferences on the fly in all app versions. Easy to achieve things like having a different experience for different brands, price ranges, platforms and network. All led to a much better user experience and gave a great amount of flexibility.
