This article explores how front-end taxonomy came to be at Jet. Let’s begin by discussing the concept of taxonomy.
In e-commerce, using a “taxonomy structure” is the practice of bucketing similar products together based on some classification logic.
For a long time at Jet, we only used one type of taxonomy: back-end taxonomy.
Back-end taxonomy is based on “what a product is” or “product type” and is represented as a tree with a depth of two at most. All nodes at the same depth in aback-end taxonomy tree are on the same level of granularity for classification based on product type. The deeper the level of a node in this tree, the more granular the classification base on product type becomes.
Every product falls in exactly one category or node at the deepest level of a back-end taxonomy. Due to the hierarchical nature of the taxonomy, a product mapped to a child node automatically belongs to the parent node.
To understand this better, consider the product shown in the image to the left. At the lowest level, this product classifies as product type = apple. Since “apple” is a subcategory or child category “fruit,” which itself is a subcategory of “fresh produce,” this product belongs to these back-end categories as well.
It is beneficial to have taxonomy represented as a tree based on product type since this pinpoints products to exactly one category, efficiently informing business processes such as pricing, inventory management, shipping and returns, reporting, accounting, profit margin calculation, and so on.
Not so long ago, this taxonomy tree used to double as Jet.com’s site navigation. However, analytics on customer shopping behavior show that customers have different intents or missions when shopping for different things. Building a mission- or intent-based shopping experience becomes difficult when dealing with a taxonomy where each product belongs to exactly one node of the shopper-facing tree.
Imagine yourself shopping for a television, versus shopping for paper towels. Would your approach be the same for both? Probably not. When shopping for grocery online, you might have a list in mind so that you can get your items into your basket fast, and get it over with. On the other hand, when shopping for gifts for your family and friends, you may not be sure what to get and want some inspiration.
Product organization optimized in a way that allows shoppers to seamlessly find what they’re looking for can make a huge difference in minimizing the time and effort spent shopping and improve the whole experience for the customer, which in turn increases the number of sales for the business.
At Jet, our focus is on providing the best-in-class shopping experience for our customers. In an effort to have a mission- or intent-based experience and personalized site navigation for our shoppers, we decided to decouple the product-type taxonomy (back-end taxonomy) and the site-taxonomy (front-end taxonomy).
The goal of developing a front-end taxonomy system was to empower retail teams to create flexible views of the product catalog to easily merchandise product categories on the site.
Since retail teams work across Walmart and Jet, we made a decision to leverage and reuse existing UI tools developed for managing customer-facing taxonomy on Walmart.com. This way business users have a centralized tool for managing shopper-facing taxonomies on both Walmart.com and Jet.com.
A complete front-end taxonomy framework with tooling was implemented earlier this year, and Jet.com transitioned to a front-end taxonomy for site navigation in mid-May.
The front-end taxonomy we have today is a Directed Acyclic Graph (DAG), where each node represents rules for catalog search. The edges of this front-end taxonomy DAG signify parent-child relationship between nodes. Every edge is directed from the parent to the child. To provide flexibility to the front-end taxonomy, there are no restrictions on the number of parents or children that any given node can have (with few exceptions). Instead of storing what front-end taxonomy nodes a product belongs to at the product level, each front-end taxonomy node has rules based on product attributes, which are used in real-time by search to evaluate relevant products to display to the shopper.
For example, consider these rules for a hypothetical front-end category ‘Halloween must haves’ with id 12:
front_end_category_id = 12 =>
(product_type = “Candy” AND attribute/Occasion = “Halloween”)
OR (attribute/Decoration = “Scary”)
This can be translated directly into an ElasticSearch query as:
When a user tries to browse to ‘Halloween must haves’, this query is run against ElasticSearch (what we use for Search at Jet) to retrieve relevant products in real-time. Since products are mapped to front-end nodes at runtime, changes to the front-end taxonomy are dynamic and available as soon as a new taxonomy goes live.
One major drawback of using the back-end taxonomy system for site navigation was that every product could have only one backend category assignment. Because of the rule-based nature of front-end taxonomy, a product can live in multiple front-end nodes. For example, a shampoo SKU will be assigned to the backend category “Shampoo,” but, depending on its attributes, it can be also assigned to front-end nodes for “Spa Day,” “Bathroom Must-Haves,” and “Luxury Hair Care.”
Front-end taxonomy offers a lot of flexibility to users, but not all changes made to this tree can be programmatically validated. For example, rules describing categories could be syntactically correct but semantically incorrect. Consider these rules for a hypothetical front-end category “Luxury Shampoo” with id 100:
front_end_category_id = 100 => attribute/Luxury = “true”
This rule, although syntactically correct, will return all Luxury products, not just products that are “Shampoo.” For this category to semantically make sense, the rule needs to be rewritten as:
front_end_category_id = 100 =>
product_type = “Shampoo” AND attribute/Luxury = “true”
Therefore, to ensure seamless operation of our site, enforcing a proper change management process is required. The following steps are followed when making any changes to the front-end taxonomy:
- Category specialists from the retail team go to the UI and set up new front-end categories or changes rules for existing ones.
- When updates are ready, a snapshot of the tree is created and pushed to the staging environment. Front-end, discoverability, search, and browse systems start using the new tree in the staging environment.
- A category specialist reviews changes to the site navigation in the staging environment.
- The Site Management team verifies and approves changes to the taxonomy tree, and makes updates if necessary to the content management system (CMS) that defines the page layouts.
- Lastly, the front-end taxonomy from the staging environment is pushed to production and goes live on the site!
This framework to create and manage front-end taxonomy has made it easier than ever to alter site navigation. Thanks to cross-team collaboration across the organization, Jet.com successfully relaunched with a completely revamped experience-based shopping model on Sept. 13, 2018, with a major focus on the categories of Grocery, Home, Fashion, Beauty, and Electronics.
Considering that customers approach different shopping occasions differently, as discussed earlier in the article, different tools and delivery options are available for customers in different experiences. For example, shoppers can easily reorder or schedule item delivery in the “City Grocery” experience, while the focus in our “Home” experience is to suggest products based on personal style and space considerations. The front-end taxonomy framework played a huge part in facilitating this change.
We believe that personalized shopping is the future of e-commerce. The introduction of front-end taxonomy was an important step in achieving this larger goal of personalization-based product discovery. We intend to continue improving front-end taxonomy tooling and capabilities and finding new and innovative ways for tackling discoverability.
Interested in tackling the challenge with us? Come #workpurple, and check out open roles in our tech org here.