Flipkart Commerce Cloud Recommendations
Product Documentation v1.0 Built By Retailers, For Retailers
Confidential — For Publisher and Partner Use Only © 2026 Flipkart Commerce Cloud
About This Document
This document is the product reference for Flipkart Commerce Cloud (FCC) Recommendations. It covers how the recommendation engine works, the available widgets, cold start strategy, measurement framework, and data integration guidance for publishers and their technical teams.
Audience: Network publishers, integration engineers, and e-commerce product managers.
Prerequisites: Familiarity with e-commerce concepts (product catalogues, browse and purchase signals) is helpful but not required.
Table of Contents
- Introduction
- Platform Architecture and Key Concepts
- Widget Catalog
- Cold Start Strategy
- Metrics and Measurement
- Data Requirements
- Onboarding Checklist
- Glossary
1. Introduction
Overview
FCC Recommendations (Reco) is FCC's ML-driven product discovery engine. It infers user intent from behavioural signals and catalogue data, then surfaces the most relevant products — or stores and categories — for a given user in a given context.
Reco is designed as a headless service: the engine returns a ranked list of products via API, and the client's storefront determines how and where to display them. This gives publishers full control over the visual experience while FCC handles the intelligence layer.
Where Reco Fits
Reco occupies the middle of the intent spectrum between explicit search and manual merchandising:
| Intent Level | Mechanism | Description |
|---|---|---|
| High | Search | User explicitly states what they want via a query |
| Medium | Reco | System infers what the user might want from behavioural signals |
| Low | Merchandising / Curation | Business manually decides what to show |
Reco is most valuable in contexts where users are browsing without a specific query — homepages, category pages, and product detail pages — and the platform must make an intelligent, personalised prediction of what to surface next.
Core Output
A ranked list of products (or stores / categories) — chosen using User Data + Catalogue Data + Business and Domain Rules — optimised for a defined business goal (CTR, CVR, or AOV).
What Reco Is Not
- Not a search engine. Reco does not parse search queries. There is no query-term matching or inverted-index retrieval in the Reco pipeline.
- Not pure merchandising. Reco recommendations are algorithmically generated, not manually curated by a business team.
- Not a storefront layer. The headless Reco service returns product lists via API. The publisher's frontend is responsible for rendering, layout, and display logic.
Who This Platform Is For
| Persona | Description |
|---|---|
| Network Publishers | Retailers and marketplaces wanting to drive product discovery, increase basket size, and improve user retention through personalised recommendations |
| Integration Engineers | Technical teams integrating FCC Reco APIs into publisher apps, websites, and data pipelines |
| E-Commerce Product Managers | Product teams designing widget placement strategies and measurement frameworks for recommendation surfaces |
2. Platform Architecture and Key Concepts
Overview
FCC Reco is a two-stage ML pipeline. A Candidate Generator first retrieves a pool of relevant products for a given user and surface. A Candidate Ranker then scores and reorders that pool using business logic and ML signals to produce the final ranked list.
Every widget on the client storefront runs its own Candidate Generator + Ranker combination. There is no single universal pipeline — algorithms are tuned per widget and per surface context.
Three Inputs to the Engine
| Input | Description |
|---|---|
| Catalogue Data | Product attributes, categories, availability, and pricing. Ingested by the publisher via the FCC Catalogue API or batch pipeline. Powers catalogue-based widgets such as Similar Products. |
| Collective / Raw User Data | Aggregated behavioural signals across all users: clicks, purchases, add-to-cart events, and browse history. Powers collaborative and graph-based models such as Cross Sell Recommendation. |
| User Insight Signal | Individual user-level signals: session context and personal browsing and purchase history. Powers personalised widgets such as Recently Viewed Products. |
Customisable Business Requirements
A fourth input sits above the engine — client-specific rules that shape both candidate generation and ranking. Examples include boosting a specific brand in results, suppressing a category, or enforcing diversity across recommendation slots. These are configured per publisher and applied at runtime without requiring retraining of the underlying models.
The Two Internal Modules
Candidate Generator (CG)
The CG produces a pool of candidate products for a given user, surface, and widget context. The algorithm varies per widget — from simple catalogue attribute matching (Similar Products) to graph neural network embeddings (Cross Sell Recommendation). Domain Rules are applied at this stage to guard against semantically nonsensical product pairings.
Candidate Ranker
The Ranker scores and orders the CG output to produce the final ranked list returned to the client. Business Rules and Filters are applied at this stage — removing out-of-stock or non-serviceable products, optimising for CTR or CVR, and applying client-specific boosts or suppression rules.
User + Surface Context
│
▼
┌────────────────────────┐
│ Candidate Generator │ ← Catalogue Data
│ (widget-specific │ ← Collective User Data
│ algorithm) │ ← User Insight Signal
│ + Domain Rules │
└──────────┬─────────────┘
│ Candidate Pool
▼
┌────────────────────────┐
│ Candidate Ranker │ ← Business Rules & Filters
│ (ML scoring + │ ← Customisable Business Requirements
│ business logic) │
└──────────┬─────────────┘
│ Final Ranked List
▼
API Response → Publisher Storefront
Domain Rules vs Business Rules
| Rule Type | Applied At | Description |
|---|---|---|
| Domain Rules | Candidate Generator | Manually configured, heuristic constraints on which product domains can appear together. Guards against nonsensical cross-category recommendations — for example, preventing co-occurring purchase signals from pairing iPhones and bread in a recommendation. |
| Business Rules & Filters | Candidate Ranker | Dynamic, goal-driven filters applied during ranking: remove non-serviceable or out-of-stock products; optimise for CTR or CVR; apply client-specific brand boosts or category suppression; control diversity across recommendation slots. |
3. Widget Catalog
Overview
A Widget is a specific recommendation placement on the client storefront — for example, "Similar Products" on a product detail page. Each widget has its own Candidate Generator + Ranker configuration, tuned to the intent and context of that surface.
FCC currently offers four live widgets, with three additional widgets in the pipeline.
Widget Summary
| # | Widget Name | Surface | Status | Cold Start Ready |
|---|---|---|---|---|
| 1 | Recently Viewed Products | Homepage, Product Pages | ✅ Live | ✅ Day 1 |
| 2 | Recently Viewed Stores | Homepage | ✅ Live | ✅ Day 1 |
| 3 | Similar Products | Product Detail Page (PDP) | ✅ Live | ✅ Day 1 |
| 4 | Cross Sell Recommendation | Product Detail Page (PDP) | ✅ Live | ⚠️ Partial |
| 5 | Quick Grab | Cart Page | 🔜 Coming Soon | ❌ Needs data |
| 6 | Best Seller | Homepage | 🔜 Coming Soon | ❌ Needs data |
| 7 | Trending | Homepage | 🔜 Coming Soon | ❌ Needs data |
Widget 1 — Recently Viewed Products
Surface: Homepage, Product Pages Status: ✅ Live Cold Start: ✅ Available from Day 1
Description
Recently Viewed Products surfaces the products a returning user has most recently browsed, enabling them to quickly resume their shopping journey. No ML model is required — the widget is a direct lookup of the user's personal browse history, weighted by recency.
| Attribute | Detail |
|---|---|
| Candidate Generator | Personal browsing history lookup — retrieves the last N products viewed by the user |
| Ranker | Recency-weighted — most recently viewed products surface first |
| Key Data Input | Individual user session and browse history |
| Cold Start | Available instantly — accumulates from the user's very first session |
Best For: Returning users navigating across sessions. High relevance with minimal data dependency.
Note: The quality of this widget depends on the publisher passing accurate, stable user identifiers in every API request. Users browsing anonymously or across multiple devices without a unified ID will receive limited personalisation.
Widget 2 — Recently Viewed Stores
Surface: Homepage Status: ✅ Live Cold Start: ✅ Available from Day 1
Description
Recently Viewed Stores operates at the category or store level rather than the individual product level. It surfaces the stores or categories a user has recently browsed, helping users re-navigate to familiar sections of the platform.
| Attribute | Detail |
|---|---|
| Candidate Generator | Personal browsing history lookup at the category / store level |
| Ranker | Recency-weighted category ranking |
| Key Data Input | Individual user session and browse history |
| Cold Start | Available instantly |
Best For: Platforms with well-structured store or category taxonomy. Particularly useful for high-frequency shoppers who return to the same categories across sessions.
Note: The relevance of this widget depends directly on the quality and depth of the publisher's catalogue taxonomy. A flat or poorly structured category tree will limit the widget's navigational value.
Widget 3 — Similar Products
Surface: Product Detail Page (PDP) Status: ✅ Live Cold Start: ✅ Available from Day 1
Description
Similar Products recommends products that share key attributes with the product a user is currently viewing. The Candidate Generator uses catalogue attribute matching only — no user history is required. This makes it the most reliable widget for new clients onboarding with zero user data.
| Attribute | Detail |
|---|---|
| Candidate Generator | Catalogue attribute matching — heuristic similarity on category, brand, price band, and product specifications |
| Ranker | Heuristic scoring on attribute overlap |
| Key Data Input | Catalogue data only (no user data required) |
| Cold Start | Available from Day 1 — zero user history needed |
Best For: New client onboarding, and PDPs across all product categories. Widget quality scales directly with the richness and completeness of the publisher's catalogue attributes.
Note: Thin or incomplete catalogue data — missing categories, brands, or product specifications — will reduce the relevance of Similar Products recommendations. Publishers should prioritise attribute completeness during catalogue ingestion.
Widget 4 — Cross Sell Recommendation
Surface: Product Detail Page (PDP) Status: ✅ Live Cold Start: ⚠️ Partial (graph model available; collaborative filtering layer requires data volume)
Description
Cross Sell Recommendation surfaces complementary products on the PDP — products that users commonly co-visit or co-purchase with the item being viewed. It is FCC's most ML-intensive Reco widget, using a visits graph and Graph Neural Network (GN) model to learn product relationships from aggregated user behaviour.
| Attribute | Detail |
|---|---|
| Candidate Generator | Visits graph (co-visit / co-purchase graph) → Graph Neural Network (GN) generates product embeddings; CNN for additional signal fusion; Collaborative Filtering where data volume is sufficient |
| Ranker | GN + CNN embeddings ranked by heuristics; business filters applied (availability, domain rules) |
| Key Data Input | Aggregated user data (co-visits, co-purchases) + Catalogue data + GN embeddings (trained offline) |
| Cold Start | Partial — the GN model can operate on the catalogue graph with limited user history; the Collaborative Filtering layer requires sufficient data volume to be effective |
Best For: Increasing basket size and average order value on high-traffic PDPs. Most effective on platforms with established user bases and rich co-purchase data.
Technical Note: All ML model training — GN embeddings and CNN — is offline batch. New product embeddings are generated periodically. Products added to the catalogue may not appear in Cross Sell recommendations until the next training cycle completes.
Widget 5 — Quick Grab (Coming Soon)
Surface: Cart Page Status: 🔜 In Pipeline Cold Start: ❌ Requires data
Description
Quick Grab is designed to surface low-priced, high-turnover impulse-buy products at the cart page — the digital equivalent of checkout aisle products in a physical store. It blends trending signals with low average selling price and high sell-through rates to identify the right candidates.
| Attribute | Detail |
|---|---|
| Candidate Generator | Trending + low-ASP product signals |
| Ranker | Blend of trending score + low price point + high sell-through rate |
| Key Data Input | Sales data + browse trending signals + catalogue pricing data |
| Cold Start | Not available at launch — requires sufficient sales and browse signal volume |
Widget 6 — Best Seller (Coming Soon)
Surface: Homepage Status: 🔜 In Pipeline Cold Start: ❌ Requires sales data
Description
Best Seller ranks products by actual purchase volume, providing a stable, data-driven representation of what is most popular on the platform. It is particularly useful for new or anonymous users where no personal history is available.
| Attribute | Detail |
|---|---|
| Candidate Generator | Aggregated sales-signal based retrieval |
| Ranker | Sales volume weighted — more stable and concrete than Trending |
| Key Data Input | Aggregated sales and order data |
| Cold Start | Not available at launch — requires sales signal volume |
Widget 7 — Trending (Coming Soon)
Surface: Homepage Status: 🔜 In Pipeline Cold Start: ❌ Requires browse volume
Description
Trending surfaces products that are gaining momentum in views and clicks — a more real-time, dynamic signal than Best Seller. It captures emerging demand before it fully converts to sales, making it particularly valuable for fast-moving categories and seasonal spikes.
| Attribute | Detail |
|---|---|
| Candidate Generator | Aggregated browse-signal based retrieval — products gaining momentum in views and clicks |
| Ranker | Velocity-weighted browse signal |
| Key Data Input | Aggregated browse and clickstream data |
| Cold Start | Not available at launch — requires sufficient browse data volume to produce statistically meaningful velocity signals |
4. Cold Start Strategy
Overview
Cold start refers to the challenge of providing useful recommendations when a new client onboards with zero or limited user history. FCC's widget portfolio is designed so that publishers can go live with meaningful recommendations from Day 1, with ML-intensive widgets becoming progressively more powerful as data accumulates.
Day 1 Ready Widgets
The following widgets do not require historical user data and can go live immediately after catalogue ingestion and API integration:
| Widget | Why Cold Start Ready |
|---|---|
| Similar Products | Catalogue-only — no user data needed. Works immediately after catalogue ingestion. |
| Recently Viewed Products | Personal session data — accumulates from the user's very first session. |
| Recently Viewed Stores | Same as above — session-level data, no historical volume required. |
| Cross Sell Recommendation (partial) | The GN model uses the catalogue graph and can operate with limited user history. |
Widgets That Require Data Accumulation
The following widgets require meaningful data volume before they can produce reliable recommendations:
| Widget | Data Required |
|---|---|
| Cross Sell Recommendation (CF layer) | Co-visit and co-purchase data for the Collaborative Filtering component |
| Best Seller | Aggregated purchase and order volume across the product range |
| Trending | Aggregated browse and clickstream data with sufficient traffic for velocity signals |
| Quick Grab | Sales data + cart behaviour + browse trending signals |
Recommended Rollout Approach: Launch with Similar Products, Recently Viewed Products, and Recently Viewed Stores from Day 1. Plan a phased rollout for Cross Sell Recommendation and editorial widgets (Best Seller, Trending, Quick Grab) once the required data volume has been established — typically after several weeks of live traffic.
5. Metrics and Measurement
Overview
FCC Reco uses a three-tier metrics framework. L0 metrics reflect business-level outcomes. L1 metrics are the direct levers that Reco influences on a daily basis. Guardrail metrics ensure improvements in L1 do not come at the expense of platform or user experience health.
Metrics Framework
| Tier | Metric | Definition |
|---|---|---|
| L0 — Business Outcomes | Unit / Share | Volume of units sold attributable to Reco-driven discovery |
| Retention | User return rate — whether Reco improves long-term platform engagement | |
| Engagement | Depth and frequency of user interaction with the platform | |
| L1 — Reco Levers | CTR | Click-Through Rate = (PPV Clicks) ÷ (Widget Impressions) |
| CVR | Conversion Rate = (Reco Widget ATC + PPV ATC/BN) ÷ (Widget Impressions) | |
| AOV | Average Order Value — influenced by surfacing complementary or higher-value products | |
| Guardrails | Platform Health | To be agreed per client during onboarding |
Key Metric Definitions
| Metric | Definition |
|---|---|
| CTR | (Product Page View Clicks) ÷ (Widget Impressions) |
| CVR | (Reco Widget Add-to-Cart + PPV Add-to-Cart / Browse-to-Navigate) ÷ (Widget Impressions) |
| AOV | Average Order Value — the average value of a single order. Reco influences AOV by surfacing complementary or higher-value products. |
| ASP | Average Selling Price — the average price of items sold. Relevant to Quick Grab, which intentionally targets low-ASP impulse-buy items. |
| Widget Impression | Counted when a Reco widget loads and is rendered to the user on the page. |
Measurement Considerations
Attribution window. Reco attribution requires an agreed window between a widget interaction (click or view) and a downstream conversion (add-to-cart or purchase). Publishers should agree on attribution windows with FCC during onboarding, before any widget goes live.
Baseline definition. To evaluate Reco impact, publishers should define a measurement baseline — typically the organic conversion rate or basket size before Reco is deployed — against which Reco performance is tracked over time.
Measurement framework. FCC strongly recommends that publishers agree on a measurement framework — including success metrics, attribution definition, and reporting cadence — before committing to widget deployment. Establishing measurement criteria post-deployment makes ROI evaluation significantly more difficult.
6. Data Requirements
Overview
The quality of FCC Reco recommendations scales directly with the quality and volume of data the publisher provides. This section describes the data inputs required per widget type and the publisher's responsibilities for each.
Catalogue Data
All widgets depend on a well-structured, complete product catalogue. Publishers must ingest catalogue data via the FCC Catalogue API or the batch ingestion pipeline before Reco can serve any recommendations.
| Catalogue Attribute | Importance | Notes |
|---|---|---|
| Category (hierarchical) | Critical | Drives domain rules and attribute matching for Similar Products |
| Brand | High | Used in attribute matching and brand-level domain rules |
| Price / ASP | High | Required for Quick Grab widget targeting |
| Product Specifications | High | Rich specs improve Similar Products relevance |
| Availability / Inventory | Critical | Out-of-stock products are filtered from all recommendation outputs at ranking time |
| Product Images and Titles | Required | Required for the publisher storefront to render recommendation cards |
Behavioural Signal Data
Publishers must pass behavioural event data to FCC to power ML-based widgets and metric tracking.
| Signal | Required For | Delivery Method |
|---|---|---|
| Browse / Product Page View | Recently Viewed Products, Trending, Cross Sell CG | Real-time event API |
| Add to Cart | CVR measurement, Quick Grab | Real-time event API |
| Purchase / Order | Best Seller, Quick Grab, Cross Sell CF layer | Real-time or batch ingestion |
| User Session Data | All personalised widgets | Passed in the GetRecommendations API request |
User Identifier Requirements
FCC Reco relies on a stable, unique user identifier to build personal browsing history and match users to their behavioural signals across sessions.
Publishers must:
- Pass a consistent
user.idin every API request. - Use the same identifier across browsing sessions (to the extent permitted by the user's consent settings).
- Pass a consent flag when user consent for personalised recommendations has not been granted. When consent is absent, only catalogue-based widgets such as Similar Products are eligible to serve.
7. Onboarding Checklist
Overview
Standard Reco onboarding takes approximately 3 to 5 weeks from contract finalisation to the first live widget, depending on integration complexity and catalogue size.
Phase 1: Setup and Configuration
| Task | Owner |
|---|---|
| Define widget placements and surfaces — which widgets on which pages | Publisher + FCC |
| Configure domain rules per product taxonomy | FCC (with Publisher input) |
| Configure business rules and filters (brand boosts, category suppression, diversity controls) | Publisher + FCC |
| Define attribution window per widget | Publisher + FCC |
| Define measurement baseline and success metrics | Publisher + FCC |
| Agree measurement framework before any widget goes live | Publisher + FCC |
| Assess client data volume and readiness for ML-dependent widgets | FCC |
Phase 2: Technical Integration
| Task | Owner |
|---|---|
| Integrate GetRecommendations API for each widget surface | Publisher Engineering |
| Implement impression and click tracking event firing | Publisher Engineering |
| Set up catalogue ingestion pipeline (real-time API or batch) | Publisher Engineering |
| Set up behavioural event ingestion (browse, add-to-cart, purchase events) | Publisher Engineering |
| Validate user identifier consistency across API requests and event ingestion | Publisher Engineering + FCC |
| Test API responses across all device types and surfaces | Publisher Engineering + FCC |
| Validate domain rule and business rule behaviour in serving responses | Publisher Engineering + FCC |
| Confirm out-of-stock filtering is working correctly in ranked outputs | Publisher Engineering + FCC |
Phase 3: Go Live
| Task | Owner |
|---|---|
| Launch Day 1 widgets: Similar Products, Recently Viewed Products, Recently Viewed Stores | Publisher + FCC |
| Monitor widget impressions, CTR, and CVR for the first two weeks | Publisher + FCC |
| Assess data accumulation progress for ML-dependent widgets | FCC |
| Plan phased rollout of Cross Sell Recommendation once data threshold is met | Publisher + FCC |
| Establish reporting cadence and quarterly business review schedule | Publisher + FCC |
Glossary
| Term | Definition |
|---|---|
| AOV | Average Order Value — the average value of a single order. Reco can influence AOV by surfacing complementary or higher-value products. |
| ASP | Average Selling Price — average price of items sold. Quick Grab targets low-ASP items intentionally to drive impulse-buy behaviour. |
| Candidate Generator (CG) | The first stage of the Reco pipeline. Retrieves a pool of candidate products for a given user, surface, and widget context using widget-specific algorithms (heuristics, graph models, collaborative filtering). |
| Candidate Ranker | The second stage of the Reco pipeline. Scores and reorders the CG output using ML signals (CTR, CVR predictions) and business/domain rules to produce the final ranked list. |
| Cold Start | The challenge of providing meaningful recommendations when a new client onboards with zero or limited user history, or when a new product has no interaction data. |
| Collaborative Filtering (CF) | A recommendation technique that identifies patterns across many users' behaviour to infer what a given user might like. Requires sufficient data volume to be effective. |
| Cross Sell Recommendation | FCC's most ML-intensive Reco widget. Recommends complementary products on the PDP using a visits graph + Graph Neural Network (GN) + CNN model. |
| CTR | Click-Through Rate = (PPV Clicks) ÷ (Widget Impressions). |
| CVR | Conversion Rate = (Reco Widget ATC + PPV ATC/BN) ÷ (Widget Impressions). |
| Domain Rules | Manually configured guardrails that constrain which product domains can appear together in a recommendation — prevents semantically nonsensical pairings. |
| Business Rules & Filters | Dynamic rules applied at ranking time: filter unavailable products, optimise for CTR or CVR, apply client-specific boosts or suppression rules. |
| FCC | Flipkart Commerce Cloud. |
| GN (Graph Neural Network) | A type of ML model that learns product representations (embeddings) based on co-visit and co-purchase relationships in a graph. |
| Headless Service | FCC's Reco deployment model — an API that returns ranked product lists; the client's storefront layer controls how and where they are displayed. |
| MACH | Microservices, API-First, Cloud-Native SaaS, Headless — the architectural standard FCC is building towards in 2026. |
| Reco | Short for Recommendations — FCC's ML-driven product discovery engine. |
| SaaSable | Describing a feature that is ready for multi-tenant, configurable, production deployment for external FCC clients — as opposed to a publisher-internal-only implementation. |
| Visits Graph | A graph data structure representing which products are co-visited or co-purchased by users. The primary input for the Cross Sell Recommendation Candidate Generator. |
| Widget | A specific Reco placement on the client storefront — e.g., "Similar Products" on the PDP. Each widget has its own Candidate Generator + Ranker combination. |
| Widget Impression | Counted when a Reco widget loads and is rendered to the user on the page. |
© 2026 Flipkart Commerce Cloud — Confidential. For Publisher and Partner Use Only.