Explore

Parallel Feeds

Experiment design

Experiment reads

Agenda -

Align on problem and core solutioning objectives

Finalising the RE which we’d want to experiment with based on tech feasibility

Finalising the BE logic layer to assign adjacent categories for a given feed / curate feed for a given category per RE

Brainstorming on various design approaches and understand tech feasibility of implementing each

Objective -

Enabling swifter cross segment (Category / taxonomy / feature) browsing for exploratory low - med intent users through the shopping journey

Problem context -

Exploratory browsing is quite rampant on the platform which is evident from -

~75% users heavily browse SSCAT A and end up purchasing SSCAT B within the same session

~60% users primarily browse a given super portfolio and end up buying from some other super portfolio within the same session

~17% users order from multiple SSCATs within the same day contributing to ~35% plat OC

Considerable re-browsing for a different category happens within the same session / within 30 mins from first order placement

The re-browsing through other categories / super portfolios happens within -

Same session for 43% users while 57% resume in a different session

~13% users buy from different categories within the same checkout, Another ~52% buy within 30 mins of placing the first order

⁠

⁠

Significant portion of secondary orders that users place in other categories stems from PDP reco / search / HP widget and wishlist, This indicates users have to go thorough the browsing journey again in case they have intent for another category

⁠

⁠

Data appendix⁠

⁠

Current browsing flow requires users to signal intent towards the category of their choice by either -

Starting the browsing journey again from HP REs

Re-initiating browsing journey from search

Rely on low accessibility IC touch-points like filters in core browsing feeds

Significant traffic real estates like PDP reco / FY etc miss out on browsing enablement to channelise browsing intent towards adjacent or related category offerings.

Strategic view -

While the KR initially focused on generating / channelising intent towards adjacent / similar category in core browsing flows like PDP reco / FY, We’ve also baked in strategic priority to scale VC for programs like Mall / Gold through the updated experience.

RE details -

PDP reco - Visited by ~47% app openers / ~38% traffic clicking on a PDP. The RE signifies high intent objective from users visible from higher views to order conversions as compared to other feeds.

Feed aggregation details - Currently PDP reco serve ~70 catalogs from the same SSCAT / SCAT as parent PDP basis -

Aggregating closest 200 catalogs from intent and content CG w.r.t. parent product (100 each)

Filtering the products within the same SSCAT for fashion and same SCAT for NF

Returning the top 70 catalogs of this feed basis ML ranker

FY - Visited by ~20% app openers with exploratory / low intent. Lowest views to order conversion ratio amongst all REs

Feed aggregation details - Is an infinite feed which is aggregated from a mix of catalogs slotted across explore / ads and exploit from a mix of -

Catalogs from Recently interacted SSCATs basis recent clicks

Popular products from last 5 ordered SSCATs

Cross category catalogs - Catalogs from category clusters user has never interacted with

RE prioritisation snapshot -

Real estate

RE objective

Tentative impact

Priority

PDP reco

Prelim / detailed product evaluation

Browsing continuation / shopping intent - High

High

FY feed

Browsing journey start

Shopping intent - Low - Med

Med

SLP

Browsing journey start

Shopping intent - High

Low

Order page

Tracking orders / End of intent

Shopping intent - Low (0 OD users only contribute to ~1% of order page opens)

Low

Wishlist / Cart

Browsing continuation

Shopping intent - High

Low

There are no rows in this table

⁠

Solutioning approach -

The recommended solve bakes in ingress of intent routing touch-points across reco / FY to generate intent towards -

Strategic programs

Related / adjacent SSCATs

Design guidelines for MVP -

The MVP design build is to test and build conviction on horizontal swipe UX to browse feeds from other category or programs in PDP reco. The MVP version would just have Gold and Mall as the parallel feeds to optimise for velocity, Backend build for cross category feed curation would be different and is parked off from v1 scope. The build to insert adjacent category ingress would be serialised and picked iteratively.

Parallel feed UX -

Should we have program and category ingress in the same row?

Yes, having a L0 / L1 layer has the following cons -

Utilisation of more vertical space

Limited utilisation of the new row since HVFs limited to Gold / Mall

Inconsistent UX - Some SSCATs can have either Gold or Mall or Both

Can we scale these designs to other REs (FY)?

Yes, but the approach might need a few adjustments per feed -

Parallel feed granularity - The parallel feed ingress would work at portfolio level in FY over granular SSCAT level toggle in PDP reco

HVFs and IFs to be used to further channelise intent to a given category or it’s attributes in FY

Other UX updates - FY / Other feeds already have 2 rows for IC in the form of static filter and sort and HVFs, Adding a third layer for category ingress through parallel feed adds into the clutter

We’ve seen sort and filter usage limited to ~2.5-3% of all FY feed opens

Of this, 67% is filter usage while sort usage is limited to ~33%

To bypass this, we’s have to update the UX to integrate all filter and sort screen through the same row as HVF - Design explorations on-going

Plan on FTUX -

Ideal FTUX - FTUX involves showcasing a finger swipe animation with the feed peaking in and out with some sunset

MVP FTUX - Since the ideal FTUX would have larger effort from tech, we’d also explore lottie based version which can showcase users the possibility of swiping through to the next feed w/o actually giving a feed preview

What happens at end of PDP reco feed?

At a later point, we’ll add in touch-points to relay users to the next parallel feed at the end of landing reco feed. To be iterated post base MVP build

Tech solutioning guidelines (MVP) -

PDP -

Information of what sub sections and nomenclature to show per PDP -

The details of position, name and image per parallel feed tab would come in from a presto table with the following schema -

Real estate

Location ID {Null for FY, CLP ID for CLPs, Collection ID for collections, PST for search, SSCAT ID for PDP reco}

Variant ID - To support testing multiple variants of SSCAT / program position (To be kept in schema, A/B integration can happen iteratively)

Position details - {Condition for tab1, Condition for tab2, ..., condition for tab n}.

Reference⁠

⁠

Tab condition JSON structure

Tab condition will primarily relay AND / OR conditions with details on -

SSCAT constituting the feed

Any attribute filters (For Gold / Mall etc)

Tab name

Curation of feeds for the different parallel feeds -

Programs -

Gold and Mall - Leverage the PDP widget build to power the initial catalogs, then create a fallback feed from OFS / RXFA which -

Filters all Gold / Mall catalogs within parent product’s SSCAT and uses it as the fallback

While doing so, only add incremental catalogs not already part of the feed from fallback

SSCATs - Create support to power these feeds from OFS / RX-FA through a dynamic CLP which filters live catalogs part of the respective SSCAT

Configs to power dynamic CLP to be shared in the position table detailed above

Handling visibility of the parallel feed tabs -

MVP build -

Check OFS for availability of catalogs to ensure the tabs show up or not basis the section config shared by product / DS team

Only showcase the tab option if we have at-least ~XX catalogs

Instrumentation requirements -

Backend instrumentation -

Adding instrumentation for views coming in from the new RE in central views table

Attributes to persist -

source / current_screen / screen → Parallel_Feed

tab_name → Name of the tab from which catalog was viewed

tab position → Position of the tab from which catalog was viewed

view depth → Position at which catalog was placed in the parallel feed

Tab visibility - PDP level tagging of the count of tabs visible per PDP (0/1/2)

Mixpanel instrumentation -

⁠

https://docs.google.com/spreadsheets/d/1QzzM6nP0jmkmjRp2cUkzSlOK_LGItjZCqic2fQhEetE/edit?gid=0#gid=0⁠

⁠

FY - Similar to PDP, just the config could be different which is shared by DS / product (Tabs could be at a portfolio or cluster of SSCAT level)

Tech FTUX -

FTUX build -

https://www.figma.com/proto/Lr2UQWCBQH7KTyPbcLthF2/Parallel-Feed?page-id=4051%3A6&node-id=8935-40962&viewport=1058%2C-1227%2C0.54&t=lPfGBksUXNmJCT3t-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=8935%3A40962&show-proto-sidebar=1⁠

⁠

Trigger - FTUX to trigger for X PDPs across sessions for a user

Re trigger capability - Build custom capability to re-trigger FTUX at a later point in time

FTUX should only trigger once the tab names come and stick at the top of page

FTUX should get disabled in case user does any action on the page

Add a mixpanel event for FTUX as described

here⁠

⁠

Designs -
⁠
⁠

Solutioning decision -

The solution would entail decision across the following lines, We need to optimise for velocity and faster GTM -

What categories and IC objectives to display per PDP / FY?

PDP -

Choice and ranking of adjacent category -

<💡Heuristics first → DS> To start keep the clusters at a category / SSCAT level. Think about increasing granularity later..

Heuristics can be based on existing ranking models / SSCATs which users interact with in terms of views and orders post purchasing a given SSCAT

Choice of IC objectives - Which PDPs to show Gold vs Mall ingress touchpoint?

💡Enable for all PDPs where the base SSCATs has at-least ~XX catalogs to power infinite feed/ Maintain visibility basis count of catalogs classifying for the feed

FY -

Choice and ranking of adjacent categories / clusters -

💡Heuristics basis user’s interacted category clusters and adjacent category near those

Choice of IC objectives - Which users to show Gold vs Mall ingress?

💡 Show for all in MVP, personalise later

How do we curate feeds for adjacent categories / IC objectives?

PDP -

Feed curation (Adjacent categories) -

💡Dynamic CLP created from all catalogs mapped to the SSCAT ranked by ODNR / other readily available catalog features

💡Manual CLPs created from all catalogs mapped to the SSCAT ranked by ODNR / other readily available catalog features

💡Utilising existing PDP reco feed curation logic and modifying the payload to return catalogs from required SSCAT

Feed curation (Gold / Mall) -

💡Automated feed curation approach similar to PDP reco widget for Gold / Mall

Showing FIF and parallel feed with same duplicate products - <Think>

💡Manual / dynamic CLP based from all Gold / Mall products within parent SSCAT ranked by ODNR

FY -

Feed curation (Adjacent categories) -

💡Dynamic CLP created from all catalogs mapped to the SSCAT ranked by ODNR / other readily available catalog features

💡Manual CLPs created from all catalogs mapped to the SSCAT ranked by ODNR / other readily available catalog features

💡Utilising existing FY feed curation logic and modifying the payload to return catalogs from required SSCAT

Feed curation (Gold / Mall) -

💡Filtering all Gold / Mall catalogs part of FY

💡Manual / dynamic CLP based from all Gold / Mall products ranked by ODNR

UX decision - How do we build a scalable UX which can be used to relay users to feeds from other categories / Gold / Mall?

Outside IN ideations -

Horizontal browsing sub tabs with a swipe action FTUX (Recommended)

Used across REs in long tail platforms like Temu to enable faster switch to an adjacent category feed

⁠

Inside IN -

Wishlist - We use the same interaction in wishlist where CTRs fare ~3% tab switches upon landing

Cross sell experiment from ranking - Quoted CTR of ~11% across tabs (Very sparse / unreliable data) -

⁠

Check CTR for tab switch for anon users on HP

FIF based ingress -

FIFs from category / Gold / Mall could be ingested in PDP recos (Already implemented)

CTRs heavily influenced by relevance of first few products upfront visible on the widget

⁠

⁠

HVFs based ingress -

Complex from a BE perspective, would not solve for category ingress for a lot of cases since reach limited to the first 5 HVFs getting a lot of views

Product card based ingress -

Used by head E-com platforms like Ajio etc to route users to a parallel feed on browsing

⁠

⁠

Limited ingress touch points could be baked in with this approach

Infinite feed ingress at end of PDP

⁠

⁠

Would limit re-direction for users reaching end of the feed

PIP modal call out as part of PDP recos

Non native invasive experience, Would limit intent ingress to some intent objective / category

Might not be able to inject a vertical infinite feed

⁠

MoM -

Team to test vertical scroll designs

Team to align on MVP FTUX

Design review -

Core problem statement -

Platform lacks touch-points for adjacent category browsing through user’s core shopping journey for exploratory intent

Exploratory user behaviour - Significant portion of users on Meesho have exploratory intent, browsing multiple portfolios in one session -

~75% of users browsing SSCAT A end up buying SSCAT B in the same session

~60% of users browsing one super portfolio end up transacting in a different super portfolio in the same session

Multi-Category Ordering Insights - ~17% of users order from two distinct categories within the same day, contributing to 30% platform OC

~70% of these second orders are placed within 30 minutes of the first order, with 43% occurring in the same session

Navigational challenge - Many second orders from other categories are driven by PDP recommendations, search, homepage widgets, and wishlist indicating users need to re-navigate the browsing journey for different categories

⁠

Strategic stance (C>T>I) -

While the KR originally focused on generating / channelising intent towards adjacent category in core browsing flows like PDP reco / FY etc. We’ve prioritised boosting visibility for strategic programs like Mall / Gold as part of MVP under project sniper

Design guidelines -

Crafting an UX which can be scaled for adjacent category ingress as part of later builds

Ensuring new designs are scalable across REs for future builds

Creating an intuitive FTUX for easy UX comprehension

Decision on RE for MVP -

We’ve finalised PDP reco as the focus RE for MVP -

Primary real estate for re-orders from users transacting in multiple SSCATs daily

High traffic potential, with ~47% of app openers navigating to recommendations at least once per session

MVP objective -

Experiment with a minimum scope to understand user’s comprehension of the new UX

Identify instances of primary intent cannibalisation in case of PDP reco

MVP Metrics -

North star - Views and order jump for Gold and Mall Views and order jump for Gold and Mall

L0 - Gold O/Vi

Gold V/Vi

Gold NMV/Vi

Mall V/Vi and Mall NMV/Vi

L1 -

Usability - Sub section CTR

Checks -

Platform O/Vi

Platform NMV/Vi

Reco O/Vi

Reco NMV/Vi

80 OC

NQD

Ads revenue per user

Design choices -

HVF -

Competitive landscape - Used across comp to surface broad intent objectives like browsing for top rated, low priced etc

Scalability challenges - ~75% CTRs comes in from the first 4 HVFs limiting our reach to scalably use the designs for program and adjacent category ingress

IF -

Competitive landscape - Used across comp to surface prelim and detailed category specific objectives while browsing

Scalability challenges - IFs are currently positioned to surface category specific features for homogenous feeds, category selection specifically for heterogeneous feeds

FIF based ingress - Already picked up as part of strategic programs

Not be scalable to integrate ingress for multiple category clusters

CTRs heavily influenced by relevance of first set of products visible upfront on the widget

Product cards based ingress - Limited ingress touch points could be integrated with this approach

Infinite feed ingress at end of PDP - Would limit re-direction for users reaching end of the feed

RE decision framework -

Real estate

% Secondary order contribution

Net traffic potential (% of AOs)

Primary IC lever

Priority

PDP reco

29.75%

47%

CLPs & collections

17.62%

25%

Experiment design -

Metrics to track -

North Star - Total gold orders by visitor

Check metrics - NMV/Vi , GMV/Vi , V/Vi , V/DAU , Total Orders/Vi

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.

Parallel Feeds

Agenda -

Objective -

Problem context -

Strategic view -

RE details -

Solutioning approach -

Design guidelines for MVP -

Tech solutioning guidelines (MVP) -

Designs - ⁠⁠

Solutioning decision -

Design review -

Core problem statement -

Strategic stance (C>T>I) -

Design guidelines -

Decision on RE for MVP -

MVP objective -

MVP Metrics -

Design choices -

Experiment design -

Designs -
⁠
⁠