Overview
About This Document
This document is the product reference for Flipkart Commerce Cloud Audience Manager (AM). It covers the signal model, segmentation engine, self-serve UI, activation surfaces, data requirements, and integration guidance for publishers and their technical and marketing teams.
Audience: Growth managers, CRM and marketing owners, merchandisers, integration engineers, and data teams.
Prerequisites: Familiarity with basic e-commerce concepts (orders, customer journeys, promotions) is sufficient. No SQL or data engineering knowledge is required to use the Audience Manager UI.
Table of Contents
- Introduction
- Platform Architecture and Key Concepts
- Phase 1 Signal Model
- Signal 1 — Lifecycle
- Signal 2 — Recent Activity
- Signal 3 — Brand and Category Explored
- Signal 4 — Channel (Platform)
- Signal 5 — Login Status
- Signal 6 — Geolocation
- Self-Serve Segment Builder
- Segment Lifecycle and Refresh
- Business Use Cases and Segment Examples
- Activation and Export
- Data Requirements
- Capability Summary
- Onboarding Checklist
- Glossary
1. Introduction
Overview
Audience Manager (AM) is Flipkart Commerce Cloud's core customer segmentation and activation engine. It ingests clickstream events, customer profiles, and catalog data to compute a well-defined set of deterministic user signals and audience segments — which can then be activated across storefront, pricing, promotions, and CRM surfaces without any SQL or custom data engineering.
The fundamental promise of AM is simple: make it trivial for any retailer on FCC to target the right customer at the right moment, without writing SQL or building their own CDP.
Why Audience Manager Exists
Most retailers operating at mid-to-large scale face three structural problems with customer targeting:
Blind targeting. Storefront experiences, offers, and CRM communications are largely generic, despite wide variation in customer value, intent, and location. Merchants struggle to answer questions like: "Show me grocery buyers who browsed yesterday but haven't ordered in two months."
Fragmented data. Clickstream, orders, user profile, and POS data live in separate systems. Creating a segment requires a data analyst and ad-hoc SQL — often taking days or weeks.
No storefront-native activation. Some CDPs and marketing tools can build audience lists, but they don't integrate tightly with live storefront rendering. Activation is limited to email and ads — not real-time merchandising.
AM solves all three. It unifies events into profiles, computes deterministic signals on a scheduled basis, and exposes them via a read API and self-serve UI that any business user can operate.
Expected Business Impact
| Outcome | Expected Lift |
|---|---|
| Personalised widget CTR on home and store pages | +8–12% |
| AOV from targeted offers and high-affinity upsell | +5–8% |
| Repeat purchase rate from lifecycle-based reactivation | +3–5% |
What AM Is Not
- Not a real-time system. AM computes signals in offline batch pipelines on a daily (or slower) cadence. Segment membership reflects the state of data as of the last pipeline run — not the current live session. Real-time session targeting (e.g., "user is on mobile right now") must be handled by the storefront rendering layer.
- Not an ML-based scoring engine. All Phase 1 signals are deterministic rule-based computations — pure functions over input data with no machine learning or black-box scoring. What you configure is exactly what you get.
- Not a substitute for a full CDP. AM is scoped to a well-defined set of high-signal dimensions that cover the most common retailer use cases. It is not a general-purpose data warehouse or audience platform.
Who This Platform Is For
| Persona | Core Need | Primary Signals Used |
|---|---|---|
| Growth / Category Manager | Personalise home and store pages without engineering dependency | Lifecycle, Channel, Brand/Category |
| Marketing & CRM Owner | Drive email, SMS, and push campaigns with lifecycle and activity signals | Lifecycle, Recent Activity, Login Status |
| Merchandiser | Align promotions and assortments to brand and category affinity | Brand/Category, Geolocation (Post-MVP) |
| Data / Engineering Team | Precise, well-specified signal model for system integration | All signals + API contract |
2. Platform Architecture and Key Concepts
Overview
AM operates as a batch pre-computation engine with a real-time read API. Signals are computed from historical event data and stored in a user signals store, from which downstream systems query in real time at the point of need.
Event Sources (Clickstream · Orders · Profiles · Catalog)
│
▼
┌────────────────────────────────────────────┐
│ UNIFIED DATA PIPELINE │
│ Ingests events → enriches with catalog │
│ → computes signals → stores results │
│ Runs on configured cadence (min: daily) │
└──────────────────────┬─────────────────────┘
│ Pre-computed signals
▼
┌────────────────────────────────────────────┐
│ USER SIGNALS STORE (AM) │
│ user_id → lifecycle, activity, channel, │
│ login_status, brand/category affinities │
└──────────────────────┬─────────────────────┘
│ Real-time read API
▼
Storefront · Pricing · Promotions · CRM
Batch Processing — The Core Principle
AM is a batch system. All signals are computed from historical event data up to the most recent pipeline execution. This has important implications:
- Segment membership changes are reflected only after the next pipeline run.
- The minimum supported refresh cadence is daily (once per 24 hours).
- Real-time event-triggered segment updates are not supported in Phase 1.
- For real-time session context (e.g., "user is currently on mobile"), the publisher's storefront rendering layer must handle this independently.
Three Input Classes
| Input Class | Examples | Purpose |
|---|---|---|
| Clickstream Events | Page View, Product View, Add to Cart, Order Confirmed, Login, Logout, App Open | Primary source for all activity, channel, login, and affinity signals |
| User Profile Records | Account created date, last order date, total order count | Supplementary data for Lifecycle signal; fills gaps where event history is incomplete |
| System Data | Product catalog (product ID, category, brand), store master | Enables enrichment of product events with category and brand metadata |
3. Phase 1 Signal Model
Overview
Phase 1 is scoped around five live signals and one post-MVP signal, computed for every known user via offline batch processing. All signals are deterministic and rule-based — no ML, no black-box scoring. Every signal is a pure function of the configured rules applied to the input data.
| # | Signal | Dimensions / States | Status |
|---|---|---|---|
| 1 | Lifecycle | PROSPECT, NEW, ACTIVE, DORMANT, CHURNED | ✅ Live |
| 2 | Recent Activity | NONE, BROWSE_ONLY, CART, ORDERED (per 1d / 7d / 30d window) | ✅ Live |
| 3 | Brand / Category Explored | Top categories and brands by view and order count (90-day window) | ✅ Live |
| 4 | Channel (Platform) | WEB, MOBILE_WEB, ANDROID_APP, IOS_APP — last active window | ✅ Live |
| 5 | Login Status | NEVER_LOGGED_IN, LOGGED_IN_BEFORE, CURRENTLY_LOGGED_IN | ✅ Live |
| 6 | Geolocation | City, postcode, nearest store (lat/lon) | 🔜 Post-MVP |
Custom Segment Upload (static CSV/SFTP lists) is available as an additional input mechanism for all clients, enabling retailers to bring externally sourced audiences (e.g., CRM lists, loyalty programme exports) into the AM activation layer.
4. Signal 1 — Lifecycle
Business Meaning
Lifecycle describes where a customer is in their relationship journey with the retailer: new, actively purchasing, drifting, or effectively lapsed. It is the most fundamental signal for differentiated treatment across all surfaces — from welcome experiences for new buyers to reactivation campaigns for churned ones.
Status: ✅ Live
States
States are mutually exclusive. Evaluation priority is strict: PROSPECT → NEW → ACTIVE → DORMANT → CHURNED. All thresholds are configurable per publisher; the canonical defaults are:
| State | Rule (Canonical Default) | Configurable |
|---|---|---|
| PROSPECT | No order ever recorded (first_order_at is null) | No |
| NEW | First order within the last 30 days AND total order count ≤ 2 | Yes (window and count cap) |
| ACTIVE | At least one order in the last 60 days; does not qualify as NEW | Yes (window) |
| DORMANT | Last order between 60 and 180 days ago | Yes (window) |
| CHURNED | Last order more than 180 days ago | Yes (threshold) |
Stored Attributes
| Attribute | Type |
|---|---|
lifecycle_state | enum: PROSPECT, NEW, ACTIVE, DORMANT, CHURNED |
last_order_at | timestamp |
total_order_count | integer |
total_order_value | float |
Activation Use Cases
| Surface | Example |
|---|---|
| Storefront | Show onboarding widgets, starter bundles, and welcome discounts for NEW users |
| Promotions | Send reactivation offers to DORMANT and CHURNED users; exclude PROSPECT from deep-discount loyalty campaigns |
| Pricing | Enable member-only or tenure-based pricing for ACTIVE customers |
5. Signal 2 — Recent Activity
Business Meaning
Recent Activity describes how engaged a user is over short time windows (1, 7, and 30 days). It distinguishes between users who are actively browsing, users with items in their cart, users who have recently ordered, and users who have gone quiet — enabling cart recovery, re-engagement, and intent-based targeting.
Status: ✅ Live
Activity Status per Window
For each time window (1d, 7d, 30d), AM computes an activity_status per user:
| Status | Rule |
|---|---|
| NONE | No recognised activity events in the window |
| BROWSE_ONLY | Has listing or category page views but no product page view, add-to-cart, or order |
| CART | At least one add-to-cart in the window but no order confirmed |
| ORDERED | At least one order confirmed in the window |
Stored Attributes
| Attribute | Type |
|---|---|
last_activity_at | timestamp |
activity_1d | enum: NONE, BROWSE_ONLY, CART, ORDERED |
activity_7d | enum: NONE, BROWSE_ONLY, CART, ORDERED |
activity_30d | enum: NONE, BROWSE_ONLY, CART, ORDERED |
views_7d | integer (page and product views in last 7 days) |
add_to_cart_7d | integer |
orders_7d | integer |
Activation Use Cases
| Surface | Example |
|---|---|
| Storefront | If activity_1d = CART → show cart recovery widget or "You left this behind" prompt |
| Storefront | If activity_7d = NONE and lifecycle_state = ACTIVE → show "We miss you" re-engagement banner |
| Promotions | Filter campaigns to users with views_7d above a threshold in selected categories |
| Pricing | Withhold time-limited discounts from users with activity_1d = ORDERED (already engaged) |
6. Signal 3 — Brand and Category Explored
Business Meaning
Brand and Category Explored captures what a user is currently interested in, based on deterministic interactions with product pages, category pages, and orders over a 90-day lookback window. It powers category-led homepages, brand-specific promotions, and smarter cross-sell targeting.
Status: ✅ Live
How It Is Computed
For each user, AM computes interaction counts over a configurable 90-day window:
| Dimension | Attributes Computed |
|---|---|
| Per (user, category) | category_view_count_90d, category_order_count_90d |
| Per (user, brand) | brand_view_count_90d, brand_order_count_90d |
Product View events and Category View events both contribute to view_count. Order Confirmed events (with line items) contribute to order_count. All computations join against the product catalog to resolve category_id and brand_id from product_id.
Activation Use Cases
| Surface | Example |
|---|---|
| Storefront | If category = BABY and category_view_count_90d > 3 → render baby-focused hero section |
| Storefront | If brand = COCA_COLA and brand_order_count_90d > 0 → show "Your Coke essentials" widget |
| Promotions | Restrict category or brand vouchers to users with relevant category_id and a view or order count threshold |
| Pricing | Explore higher price bands for categories where the user has demonstrated consistent engagement |
7. Signal 4 — Channel (Platform)
Business Meaning
The Channel signal captures which platform(s) a user has been active on over defined time windows. This enables retailers to target or suppress content based on a user's preferred or most-recent access platform — such as serving app-download banners only to web-only users, or mobile-optimised content exclusively to app users.
Status: ✅ Live
Channel Taxonomy
| Channel | Description |
|---|---|
| WEB | Desktop browser (laptop or PC) |
| MOBILE_WEB | Mobile browser (not a native app) |
| ANDROID_APP | Native Android application |
| IOS_APP | Native iOS application |
Important: AM computes channel signals from offline batch data. The Channel signal answers: "What platform was this user active on in the last N days?" — it does not answer: "Is this user active right now?" A user can appear in multiple channel segments simultaneously (e.g., active on both ANDROID_APP and WEB in the last 7 days).
Stored Attributes
| Attribute | Type |
|---|---|
last_active_channel | enum: WEB, MOBILE_WEB, ANDROID_APP, IOS_APP |
last_active_channel_at | timestamp |
active_channels_1d | list of channel enums with activity in last 24 hours |
active_channels_7d | list of channel enums with activity in last 7 days |
active_channels_30d | list of channel enums with activity in last 30 days |
channel_session_count_7d | per-channel session count in last 7 days (dict) |
Multi-Device Identity
A user may be active on multiple devices simultaneously (e.g., desktop at work, Android at home). By design, a single user can appear in multiple channel segments at once.
- Registered users: Channel signals aggregate across all devices linked to the
user_id. - Anonymous users: Channel signals are keyed on
device_id. When the user subsequently logs in, AM links prior device history to the account (device-to-account stitching).
Activation Use Cases
| Surface | Example |
|---|---|
| Storefront | Show "Download our app for exclusive deals" banner to users where active_channels_7d = [WEB] only |
| Promotions | Serve app-exclusive deals only to users whose last_active_channel is ANDROID_APP or IOS_APP |
| CRM | Send push notifications only to users with app channel activity in the last 7 days |
| Experimentation | A/B test mobile-web vs. app storefront layouts based on channel affinity cohorts |
8. Signal 5 — Login Status
Business Meaning
Login Status captures a user's authentication history, not just their current session state. The key distinction is between:
- Users who have never created an account (true anonymous / guest users)
- Users who have an account and have logged in before, but are currently browsing as a guest
- Users who are currently authenticated in their account
The primary use case driving this signal is re-engaging previously logged-in users — nudging them to sign back in to access loyalty benefits (wallet balance, reward coins, membership status). This is a high-intent nudge that requires knowing the user has an account, which anonymous-only logic cannot determine.
Status: ✅ Live
Login Status Taxonomy
| Status | Definition | Key Use Case |
|---|---|---|
| NEVER_LOGGED_IN | No login event ever recorded for this device or user. Pure anonymous / guest browsing. | Show generic sign-up prompts. Avoid personalised messaging. |
| LOGGED_IN_BEFORE | At least one login event exists in history, but the user is currently browsing without authentication. | Show "Welcome back — log in to see your rewards" widget. High-value re-engagement target. |
| CURRENTLY_LOGGED_IN | Most recent session has is_logged_in = true as of the last batch run. | Enable personalised content, loyalty-aware pricing, account-linked offers. |
Important clarification: CURRENTLY_LOGGED_IN in AM reflects the login state at the time of the last batch run — not the live session state. If a user logs in after the last batch run, their AM signal will show LOGGED_IN_BEFORE until the next refresh. Live session login state must be resolved by the storefront's session service. AM's login signal is best used for cohort-level targeting, not per-session real-time gating.
Stored Attributes
| Attribute | Type |
|---|---|
login_status | enum: NEVER_LOGGED_IN, LOGGED_IN_BEFORE, CURRENTLY_LOGGED_IN |
last_login_at | timestamp (nullable) |
last_login_channel | enum: which platform the last login occurred on |
login_count_30d | integer: number of login events in the last 30 days |
Activation Use Cases
| Surface | Example |
|---|---|
| Storefront | If login_status = LOGGED_IN_BEFORE → show "Log in to see your rewards" widget; surface loyalty balance preview |
| Promotions | If login_status = NEVER_LOGGED_IN → show generic sign-up incentive ("New member bonus: 10% off first order") |
| Pricing | If login_status = CURRENTLY_LOGGED_IN → enable account-linked offer claiming and wallet-based checkout |
| CRM | Suppress "Create an account" push notifications to LOGGED_IN_BEFORE users (they already have one) |
9. Signal 6 — Geolocation
Status: 🔜 Post-MVP
Business Meaning
Geolocation answers "Where is this user located?" for geo-personalisation and local assortment strategies. It enables targeting based on city, postcode, and proximity to physical store locations.
Planned Use Cases
- Local weekly flyers and store-specific hero widgets tied to the user's nearest store
- Region-specific assortments, pricing, and tax rules
- Geofenced promotions activated based on proximity to specific stores
Required Inputs (Post-MVP)
- Store master:
store_id,store_name,lat,lon,city,state,country - Geo fields on events:
city,postcode,lat,lon(from IP geolocation or GPS)
10. Self-Serve Segment Builder
Overview
The AM UI allows non-technical users — store managers, merchandisers, CRM managers — to create, preview, and activate audience segments without engineering support. The interface is designed to feel as intuitive as building a filter in a spreadsheet.
Status: ✅ Live
Core UI Capabilities
| Capability | Description |
|---|---|
| Use Existing Segment | Browse a catalog of pre-built system segments (Lifecycle states, activity windows) and activate with one click. No configuration needed. |
| Create Rule-Based Segment | Visual rule builder with AND/OR condition groups. Select signal dimension → operator → value. Supports nested condition groups up to 2 levels deep. |
| Custom Segment Upload | Upload a static audience list (CSV or SFTP). Map columns to user_id or device_id. Validate and preview row count before saving. Define an expiry date. |
| Segment Validity Window | Mandatory start_date and end_date on every segment. Toggle for "Evergreen" segments with a quarterly review reminder. |
| Refresh Cadence Setting | Dropdown: Weekly / Every 4 days / Daily. Displays estimated compute cost tier (Low / Medium / High) alongside each option. |
| Segment Preview & Size Estimate | After defining rules, shows estimated audience size (count and % of total user base) before saving. Allows drill-down to anonymised sample user IDs for validation. |
| Identity Key Selection | Choose whether the segment is keyed on account_id (registered users only) or device_id (all users including anonymous). Warning shown if device_id is selected with login-dependent signals. |
| Segment Activation / Export | Activate to internal surfaces (Storefront, Pricing, Promotions) or export to external platforms (NEO, PnP, Meta, Google). Configurable per segment. |
| Segment Tagging and Search | Add tags, description, and owner. Full-text search and filter by signal type, status (active / paused / expired), or last-modified date. |
| Audit Log and Version History | All changes to segment definitions are tracked with timestamp, user, and before/after diff. Previous versions can be restored. |
| Duplicate and Clone | Clone any existing segment to use as a starting point for a new one. |
| Manual Trigger | Force a one-time recompute of a segment outside its scheduled cadence. Requires admin permission. |
Segment Builder — Supported Operators
| Signal Type | Supported Operators | Example |
|---|---|---|
| Lifecycle (enum) | IS, IS NOT | lifecycle_state IS DORMANT |
| Recent Activity (enum) | IS, IS NOT | activity_7d IS CART |
| Channel (enum / list) | INCLUDES, EXCLUDES, IS EXACTLY | active_channels_7d INCLUDES ANDROID_APP |
| Login Status (enum) | IS, IS NOT | login_status IS LOGGED_IN_BEFORE |
| Category / Brand (count) | GREATER THAN, LESS THAN, EQUALS, BETWEEN | category_view_count_90d GREATER THAN 3 |
| Date / Timestamp | WITHIN LAST N DAYS, BETWEEN DATE RANGE, BEFORE, AFTER | last_order_at WITHIN LAST 30 DAYS |
| Segment Membership | IN SEGMENT, NOT IN SEGMENT | NOT IN SEGMENT 'Loyal Gold Members' |
11. Segment Lifecycle and Refresh
Segment Status States
Every segment in AM moves through a defined status lifecycle:
| Status | Description | Available Actions |
|---|---|---|
| Draft | Rule defined but not yet saved or published | Edit, Save, Discard |
| Scheduled | Saved; will activate on start_date | Edit, Cancel |
| Active | Currently computing and serving segment members | Pause, Edit (creates new version), Export |
| Paused | Computation suspended; segment membership frozen at last run | Resume, Archive |
| Expired | end_date passed; returns empty member list | Clone, Archive |
| Archived | Removed from active view; data retained for audit purposes | Restore, Delete permanently |
Refresh Cadences
| Cadence | Trigger | Recommended For |
|---|---|---|
| Weekly | Every 7 days (configurable day) | Lifecycle, Brand/Category (slow-moving signals) |
| Every 4 days | Configurable interval | Brand/Category with active promotions |
| Daily | Once per 24 hours (minimum default) | Recent Activity, Channel, Login Status |
| Sub-daily / Real-time | Not supported in Phase 1 | Must be handled by the storefront rendering layer |
Segment Validity Windows
Every segment definition must have an explicit validity window to prevent stale segments from serving indefinitely:
start_date: When the segment becomes active for downstream consumption.end_date: When the segment expires. After expiry, the segment returns no members.auto_expire: Flag to auto-disable the segment definition whenend_datepasses.evergreen: Boolean flag for segments with no planned end (e.g., "all active users"). Must be explicitly set. Publishers should review and renew evergreen segments quarterly.
Segment Update Modes
| Mode | Description | Use Case |
|---|---|---|
| Full Recompute | Recompute all segment members from scratch using full event history up to the lookback window. | Standard mode for all signals. Run on configured cadence. |
| Incremental Update | Process only new events since last run; merge with existing members. | Faster — planned for Phase 2. |
| Manual Trigger | PM or admin forces a one-time recompute via the AM UI. | After major data corrections or initial population of a new segment. |
| Custom Upload Refresh | Static uploaded lists do not refresh automatically. Valid until replaced or expired. | External CRM lists, agency-provided segments. |
12. Business Use Cases and Segment Examples
Single-Signal Segments
These are ready-to-use out of the box with a single AM signal dimension:
| Segment Name | Signal | Rule | Activation |
|---|---|---|---|
| Win-Back Candidates | Lifecycle | lifecycle_state = DORMANT OR CHURNED | Email or SMS reactivation with discount voucher |
| New Buyer Nurture | Lifecycle | lifecycle_state = NEW | Onboarding carousel on homepage; "Next purchase" incentive widget |
| Hot Shoppers | Recent Activity | activity_1d = CART | Cart recovery banner; urgency nudge ("Only 2 left!") |
| App-Only Users | Channel | last_active_channel IN [ANDROID_APP, IOS_APP] and no web activity in 30d | App-exclusive deals; push notification campaigns |
| Web-Only Users | Channel | active_channels_30d = [WEB] only | "Download our app" banner; app install incentive |
| Logged-Out Known Users | Login Status | login_status = LOGGED_IN_BEFORE | "Welcome back — log in for your rewards" widget |
| Baby Category Enthusiasts | Brand/Category | category = BABY and category_view_count_90d ≥ 3 | Baby hub hero; brand co-op baby promotions |
Multi-Signal Combination Segments
The power of AM comes from combining signals with AND/OR logic. These are high-value combinations available in Phase 1:
High-Intent Mobile Grocery Shopper
- Rule:
lifecycle_state = ACTIVE+active_channels_7d INCLUDES [ANDROID_APP or IOS_APP]+category = GROCERYwithcategory_view_count_90d ≥ 2+activity_7d ≠ NONE - Activation: Grocery-specific app home banner with store pickup option. Ideal for retailers targeting repeat mobile grocery buyers.
Lapsed App User — Re-Engagement
- Rule:
lifecycle_state = DORMANT+last_active_channel = APP+login_status = LOGGED_IN_BEFORE - Activation: Push notification: "We miss you! Your loyalty points are waiting." Back up with email if push not delivered.
Web Browsing but Not Converting
- Rule:
active_channels_7d INCLUDES WEB+activity_7d = BROWSE_ONLY+lifecycle_state = ACTIVE - Activation: Personalised homepage based on top browsed category. Target high-browse, low-conversion gap.
Premium Brand Loyalist
- Rule:
lifecycle_state = ACTIVE+brand_order_count_90d ≥ 3for a premium brand +login_status = CURRENTLY_LOGGED_IN - Activation: VIP early access to new product launches. Member-exclusive pricing for that brand.
Prospect on Mobile — First Purchase Nudge
- Rule:
lifecycle_state = PROSPECT+active_channels_7d INCLUDES [ANDROID_APP or IOS_APP]+login_status = NEVER_LOGGED_IN - Activation: Sign-up incentive: "10% off your first order when you create an account." Capture email for CRM pipeline.
Cart Abandoner on Desktop — Cross-Device Recovery
- Rule:
activity_1d = CART+active_channels_1d INCLUDES WEB - Activation: Email recovery campaign if the user is email-reachable. Show cart widget on next visit regardless of device.
Loyal Active + Multi-Category Explorer
- Rule:
lifecycle_state = ACTIVE+ category views ≥ 5 in last 90 days across ≥ 3 different categories - Activation: Curated cross-category homepage. Ideal for general merchandise retailers seeking to increase basket breadth.
13. Activation and Export
Internal Activation Surfaces
Segments computed by AM can be activated directly across FCC platform surfaces:
| Surface | How AM Segments Are Used |
|---|---|
| Storefront | Drive personalised widget rendering — hero banners, carousels, recommendation modules — based on segment membership |
| Pricing | Apply member-only pricing, tier-based pricing, or segment-specific price bands at checkout and browse |
| Promotions | Restrict vouchers, offers, and campaign visibility to qualified segments; suppress ineligible users |
External Export
For activation outside the FCC platform, AM segments can be exported to:
| Platform | Use Case |
|---|---|
| NEO | Personalised storefront widget targeting via FCC's merchandising console |
| PnP (Promotions & Pricing) | Segment-gated offer configuration |
| Meta (Facebook/Instagram Ads) | Retargeting and lookalike audience seeding |
| Google Ads | Customer match and display retargeting |
Export is configurable per segment. Publishers select which surfaces and external platforms to activate on at the point of segment creation or editing.
14. Data Requirements
Overview
AM's signal quality depends directly on the quality and completeness of the events and profile records the publisher provides. This section defines what must be flowing before each signal can compute correctly.
Required Events
Eight events are required for Phase 1. All are standard commerce events:
| Event | Required | What AM Uses It For |
|---|---|---|
| Page View | Required | Feeds Recent Activity (confirms session/channel activity); feeds Channel signal |
| Product View | Required | Primary input for Brand and Category Explored (increments view counts) |
| Category View (Listing Page View) | Required | Contributes to category affinity at the browse level; also feeds Recent Activity |
| Add to Cart | Required | Moves user into CART band of Recent Activity signal |
| Order Confirmed | Required | Primary input for Lifecycle (last order date, order count); advances to ORDERED in Recent Activity; feeds brand and category order counts |
| Login | Required | Feeds Login Status signal; confirms account existence |
| Logout | Required | Identifies users in LOGGED_IN_BEFORE state |
| App Open | Required | Captures native app channel activity even when the user doesn't browse further; critical for distinguishing ANDROID_APP and IOS_APP from MOBILE_WEB |
Required Base Attributes (on Every Event)
| Attribute | Required | Notes |
|---|---|---|
event_id | Yes | UUID for deduplication — prevents double-counting if the same event arrives twice |
event_type | Yes | Tells the pipeline which signal computation to trigger |
event_timestamp | Yes | UTC. Every time-window computation (1d, 7d, 30d, 90d) depends on accurate timestamps |
user_id | Conditional (null if not logged in) | Primary key for all registered-user signals. Must exactly match the profile record user_id. |
device_id | Required | Stable identifier for the device or browser. Must persist across sessions — not reset on each visit. AM's primary key for anonymous user tracking. |
session_id | Required | Groups events within a single visit or app session |
channel | Required | WEB, MOBILE_WEB, ANDROID_APP, or IOS_APP. Must be set correctly — an incorrect channel value will misclassify the user's platform history. |
Event-Specific Required Attributes
Order Confirmed — critical fields:
| Attribute | Required | Notes |
|---|---|---|
order_id | Required | Must be unique. Duplicate orders inflate lifecycle signals. |
order_timestamp | Required | Used as last_order_at for lifecycle computation |
order_value | Required | Total value after discounts, before tax |
line_items | Required | Must include product_id, category_id, brand_id, quantity, and unit_price per item. Without line items, Brand and Category Explored order counts cannot be computed. |
Product View — critical fields: product_id, category_id, brand_id (all required)
Login — critical fields: is_logged_in = true, login_method, user_id, device_id
Logout — critical fields: is_logged_in = false, user_id, device_id
App Open — critical fields: channel (must be ANDROID_APP or IOS_APP), app_version
Profile Records (Daily Snapshot)
A daily snapshot of user profile data from the Order Management or User Account Management system:
| Attribute | Required | Notes |
|---|---|---|
user_id | Required | Must exactly match the user_id in the event stream |
account_created_at | Required | Used to support lifecycle classification |
last_order_at | Required | Most critical field for Lifecycle signal — Active, Dormant, Churned all depend on this |
total_order_count | Required | Distinguishes NEW users (≤ 2 orders) from ACTIVE users |
total_order_value | Optional | Stored for value-tier segmentation |
email_opt_in | Optional | Used to suppress non-consenting users during email export |
push_opt_in | Optional | Used to suppress non-consenting users during push export |
loyalty_tier | Optional | Can be used directly as a segment dimension if available |
Product Catalog Record (Daily Snapshot)
| Attribute | Required | Notes |
|---|---|---|
product_id | Required | Must match the product_id in Product View and Order Confirmed events |
category_id | Required | Joined against product events for category view and order count computation |
category_name | Required | Shown in the segment builder for non-technical users |
brand_id | Required | Joined for brand view and order count computation |
brand_name | Required | Shown in the segment builder |
is_active | Required | AM excludes events on inactive products to avoid inflating affinity scores for discontinued items |
Signal-to-Event Dependency Map
Use this to confirm what must be flowing before each signal can go live:
| Signal | Events Required | Key Attributes | Needs Profile Record? |
|---|---|---|---|
| Lifecycle | Order Confirmed | Order ID, Order Timestamp, Order Value, User ID | Yes — Last Order At, Total Order Count |
| Recent Activity | Page View, Product View, Category View, Add to Cart, Order Confirmed | Event Timestamp, User ID, Channel, Page Type | No |
| Brand & Category Explored | Product View, Category View, Order Confirmed | Product ID, Category ID, Brand ID, Order Line Items | No — but requires Catalog join for Category Name and Brand Name |
| Channel | All events with Channel field; App Open specifically for app activity | Channel, Device ID, Event Timestamp | No |
| Login Status | Login, Logout | is_logged_in, Login Method, User ID, Device ID, Event Timestamp | Partial — to confirm account exists (User ID + Account Created At) |
| Geolocation (Post-MVP) | Any event carrying location data | City, Postcode, Latitude, Longitude | No |
15. Capability Summary
| Capability | Status |
|---|---|
| Lifecycle Signal (PROSPECT, NEW, ACTIVE, DORMANT, CHURNED) | ✅ Live |
| Recent Activity Signal (1d / 7d / 30d windows) | ✅ Live |
| Brand and Category Explored (90-day view and order counts) | ✅ Live |
| Channel / Platform Signal (WEB, MOBILE_WEB, ANDROID_APP, IOS_APP) | ✅ Live |
| Login Status Signal (NEVER, BEFORE, CURRENTLY) | ✅ Live |
| Custom Segment Upload (CSV / SFTP static lists) | ✅ Live |
| Self-Serve Visual Segment Builder (AND/OR rule groups) | ✅ Live |
| Segment Preview and Size Estimation | ✅ Live |
| Segment Validity Windows and Expiry | ✅ Live |
| Configurable Refresh Cadence (Daily / 4-day / Weekly) | ✅ Live |
| Activation to Storefront, Pricing, Promotions | ✅ Live |
| Export to NEO, PnP, Meta, Google | ✅ Live |
| Audit Log and Version History | ✅ Live |
| Segment Clone and Duplicate | ✅ Live |
| Manual Recompute Trigger | ✅ Live |
| Geolocation Signal (city, postcode, nearest store) | 🔜 Post-MVP |
| Incremental (delta) Pipeline Updates | 🔜 Post-MVP |
| Real-Time / Sub-Daily Segment Refresh | 🔜 Not Supported — handled by storefront rendering layer |
16. Onboarding Checklist
Overview
Standard AM onboarding takes approximately 3 to 5 weeks from data pipeline validation to first active segments in production, depending on event tracking coverage and profile data completeness.
Phase 1: Data Pipeline Setup and Validation
| Task | Owner |
|---|---|
| Confirm which of the 8 required events are already being tracked and routed to the data lake | Publisher Data Team + FCC |
| Validate event schema: confirm all required base attributes (event_id, event_type, event_timestamp, user_id, device_id, channel) are present and correctly typed | Publisher Engineering + FCC |
| Confirm that Order Confirmed events include full line items (product_id, category_id, brand_id per item) | Publisher Data Team + FCC |
| Confirm Device ID persistence — does it reset on app reinstall or browser data clear? | Publisher Engineering |
| Set up daily profile record snapshot export (user_id, last_order_at, total_order_count) | Publisher Engineering + FCC |
| Set up daily product catalog snapshot export (product_id, category_id, brand_id, is_active) | Publisher Engineering + FCC |
| Validate event volume and confirm event timestamps are in UTC | Publisher Data Team + FCC |
Phase 2: Signal Validation and Configuration
| Task | Owner |
|---|---|
| Configure Lifecycle signal thresholds per publisher (NEW window, ACTIVE window, DORMANT/CHURNED boundaries) | Publisher + FCC |
| Validate Lifecycle state distribution against expected customer base composition | Publisher + FCC |
| Confirm Recent Activity signal is computing correctly by validating against a sample of known user journeys | Publisher + FCC |
| Validate Brand and Category Explored counts against raw event sample | Publisher Data Team + FCC |
| Configure Channel signal: confirm channel values are correctly populated in the event stream | Publisher Engineering + FCC |
| Validate Login Status signal against known logged-in/logged-out user sample | Publisher + FCC |
Phase 3: Segment Creation and Activation
| Task | Owner |
|---|---|
| Onboard merchandising and CRM teams to the AM self-serve UI | Publisher Category/CRM Teams + FCC |
| Create first 3 active segments in production (recommended: Win-Back, New Buyer Nurture, Hot Shoppers) | Publisher Business Teams |
| Configure segment activation surfaces (Storefront widgets, CRM export, or promotion targeting) | Publisher + FCC |
| Set up custom segment upload flow if external audience lists (CRM/loyalty) are required | Publisher Data Team + FCC |
| Define segment refresh cadence and validity windows for each active segment | Publisher Business Teams |
| Validate segment size estimates against actual post-run member counts | Publisher + FCC |
| Establish reporting cadence and measurement framework for CTR and conversion lift | Publisher + FCC |
Glossary
| Term | Definition |
|---|---|
| Account ID / User ID | The registered account identifier. Present only when the user is logged in. AM's primary key for all registered-user signals. |
| Activation | The process of making a computed segment available for use on a specific surface — storefront, pricing, promotions, or an external platform like Meta or Google. |
| AM | Audience Manager — FCC's core customer segmentation and activation engine |
| Batch Pipeline | AM's processing architecture. Signals are computed from historical event data on a scheduled cadence (minimum: daily). Not real-time. |
| Brand and Category Explored | The AM signal capturing which brands and categories a user has interacted with over the past 90 days, based on view and order counts. |
| Channel Signal | The AM signal capturing which platform(s) — WEB, MOBILE_WEB, ANDROID_APP, IOS_APP — a user has been active on over defined time windows. |
| Clickstream Events | User interaction events generated by the publisher's storefront and app — Page View, Product View, Add to Cart, Order Confirmed, Login, Logout, App Open. Primary input to AM. |
| Custom Segment Upload | Mechanism for publishers to bring externally sourced audience lists (CSV or SFTP) into AM for activation. |
| Deterministic Signal | A signal computed by applying explicit, rule-based logic to input data — no machine learning or probabilistic scoring. Every signal in AM Phase 1 is deterministic. |
| Device ID | A stable identifier for a device or browser, set for both logged-in and anonymous users. Must persist across sessions. AM's primary key for anonymous user tracking. |
| Device-to-Account Stitching | The process of linking anonymous device browsing history (keyed on device_id) to a registered account (user_id) when the user logs in. |
| Evergreen Segment | A segment with no planned end date. Must be explicitly flagged and reviewed quarterly to avoid runaway compute costs. |
| FCC | Flipkart Commerce Cloud |
| Geolocation Signal | Post-MVP AM signal capturing user location (city, postcode, nearest store) for geo-personalisation targeting. |
| Lifecycle Signal | The AM signal describing where a customer is in their relationship with the retailer: PROSPECT, NEW, ACTIVE, DORMANT, or CHURNED. |
| Login Status Signal | The AM signal distinguishing users who have never created an account (NEVER_LOGGED_IN), users with an account currently browsing as guests (LOGGED_IN_BEFORE), and authenticated users (CURRENTLY_LOGGED_IN). |
| Lookback Window | The time period over which a signal is computed. For example, Recent Activity uses 1d, 7d, and 30d windows. Brand/Category uses a 90d window. |
| NEO | FCC's merchandising and storefront personalisation console. AM segments can be activated directly into NEO for widget-level targeting. |
| PnP | Pricing and Promotions platform within FCC. AM segments can be used to gate offers and pricing tiers. |
| Profile Record | A daily snapshot of user account data from the OMS or user management system — including last order date, total order count, and account creation date. Supplements event data for Lifecycle signal computation. |
| Recent Activity Signal | The AM signal describing a user's engagement level over short windows (1d, 7d, 30d): NONE, BROWSE_ONLY, CART, or ORDERED. |
| Refresh Cadence | How frequently a segment is recomputed. Supported options in Phase 1: Weekly, Every 4 Days, Daily. |
| Segment | A defined group of users matching a set of rules built on AM signals. Segments are the primary unit of activation in AM. |
| Segment Preview | An estimate of how many users qualify for a segment definition, shown in the UI before the segment is saved and computed. |
| Segment Validity Window | The start and end date defining when a segment is active for downstream consumption. |
| Storefront | The publisher's customer-facing website or app. AM segments activate personalised content here via widget targeting. |
| user_signals | The unified output surface of AM — a per-user record containing all computed signal values, queryable via the real-time read API. |
© 2026 Flipkart Commerce Cloud — Confidential. For Publisher and Partner Use Only.