Problem context -
Wishlist is a relatively high used real estate with ~12% app openers landing on to the RE daily. The views to order conversion has remained low for the real estate. This can be attributed to -
Users adding and visiting the RE but not converting into orders (~49% cases) Primary reasons for users not placing orders on wishlisted items - High Price / Budget led (~42% cases) Not completely sold on the product / still in consideration stage (~27% cases) Awaiting social validation (~13% cases) Product moved OOS (~12% cases) Users adding products to wishlist but not visiting the RE altogether (~44% cases)
OBJECTIVE - Solve for core user issues leading to low conversion of wishlist and other core browsing real estates by generating intent towards suitable alternatives
Key focus for browsing experience would be to understand challenges for ~49% of the wishlisting users who add and visit WL but don’t end up converting.
We won’t be focusing on users adding wishlisted products but not navigating to the RE since -
There’s relatively lower spread for these users (~44% of wishlisting users) Core ranking baking in wishlist CG to surface wishlisted products across relevant feeds as a structural fix (Experiment in progress for RV)
Impact -
Intent generation on wishlist & conversion optimisation is expected to yield incremental platform NMV uplift of 0.4 pp.
Wishlist usage understanding -
Qualitative (Survey and LODs from ~1k users) - Users comprehend the use case of wishlist is for liking and saving a product for later ~60% survey respondents didn’t have any issues related to usability for the real estate ~48% users check wishlist at the start of a new shopping intent, ~37% users check the RE continually to understand any drop in prices Primary reasons for not shopping a wishlisted product - High Price / Budget led (~42% respondents) Not completely sold on the product’s design / still in consideration stage (~27% respondents) Awaiting social validation (~13% respondents) Product moved OOS (~12% respondents) Product rating profile is bad (~8% respondents) Forgot checking wishlist (~7% respondents) ~12% traffic lands on wishlist per day, similar session landings per month. ~39% of app openers add at-least 1 product in wishlist per month, Of this set, ~20% users end up ordering at least 1 product from their wishlist User segments on wishlist - ~5 Products added per users on an average per month in WL, Distribution - ~2 Products removed per users on an average per month in WL Average count of products per wishlist - On an average user has 50 products in wishlist, of which 4 (8%) is OOS ~60-70% orders from wishlist are for products added in the last 60 days in wishlist CTR on shared and viewed sub tabs - ~3% of all wishlist opens CTR on hide OOS toggle - ~1% of all wishlist opens
Current wishlist UX -
Solution considerations -
Wishlist to remain a product first real estate (High intent products) Simplify the feed and limit extra info or usage with negligible CTR Showcasing on demand reco over upfront reco for minimal cognitive overload
Proposed solve with phasing -
Adding product specific recommendation per product card on wishlist / FY / CLP / collections and search - Why - LODs indicate core reasons for not buying wishlisted product is price / Users still in consideration stage. There’s however some inclination towards the base product and keeping reco very contextual to the parent product would be ideal Feed 1 - Cheaper duplicates Power the feed using comp swap intel to fetch - Live wishlisted products - ~X duplicate products which are cheaper than the parent product and within rating bucket >= Parent Rating-0.2 (Keep X configurable) OOS wishlisted products - ~X duplicate products for the parent product within rating bucket >= Parent Rating-0.2 (No check needed for price) Sorting logic - TBU Rank lower priced alternatives first Feed 2 - Similar product options Power the feed using merlin CG and ranker for the wishlisted product, Similar to PDP reco No min or max limit - To be handled by recos CTA should be visible only when we atleast serve 20 recos from backend Reco ingress - The reco per wishlisted product would be populated on demand as per user intent and would have the following variants - Variant 1 - Icon to trigger bottom sheet placed on product image below wishlist icon Variant 2 - Icon to trigger bottom sheet placed on product image on bottom right corner Parent wishlisted product’s image and price / rating details to show up at the top of reco bottom sheet UX for cheaper duplicates - This would show up as a horizontal scroller at the top Visibility - Min (2), Max (5) Would not be visible for cases where we get <2 catalogs from comp swap / BE call UX for similar product options - Vertical feed, Min - 20 live catalogs, Max - 200 live catalogs Adding markers to signify cheaper alternative presence per wishlisted product to improve reco icon CTR Other hygiene UX updates on wishlist - Removal of shared and viewed sub tabs Removal of view non OOS toggle Phase 2 - Adding a substitute fallback feed at the end of wishlist section Why - To enable browsing in the real estate for users with low / no wishlisted product / low CTR on product specific reco Feed aggregation - Feed would be curated using a mix of - Merlin content recos for wishlisted products (PDP reco flow) Cheapest duplicate per wishlisted product Recently viewed catalogs or RV substitute feed Feed ranking - Use platform scaled rankers / Merlin ranker to finally rank the parallel feed We’d need to shorten the wishlist the section to recent most ~14 wishlisted product, post which the new substitute feed section starts Users will see a view more CTA to expand older wishlisted products The navigation would be similar to PDP reco parallel feeds with the first tab showcasing all reco and remaining tabs for quick category specific browsing Tab visibility - The parallel feed tabs would only be visible if each tab has >=20 live products coming in from BE
Designs -
Instrumentation -
The following views and clicks events would now log - Only Primary_real_estate would get updated as ‘bottom_sheet_recos’ for clicks and views coming on products through bottom sheet across any real estate Origin and screen will remain unchanged without any update Views event - silver.mixpanel_android__catalog_views_report_final Clicks event - silver.mixpanel_android__catalog_opened_main and silver.mixpanel_android__product_clicked New events to be instrumented -
Experiment design - TBU
PRD - Intent generation on wishlist
