Predictive Customer Analytics for E-Commerce | JoNoleecy Technology Intelligence

1. Overview & Business Case

A large e-commerce platform processes millions of orders per month across consumer electronics, apparel, home goods, and FMCG categories. With a registered customer base exceeding 15 million and a product catalogue of 2+ million SKUs, the platform faced a set of interconnected problems that traditional BI and rule-based systems could not solve at the speed or precision the business needed.

The Core Opportunity

The data to solve these problems already existed in the platform's databases — order history, clickstream events, support tickets, email engagement. What was missing was the intelligence layer to make that data predictive rather than merely descriptive: to anticipate churn before it happens, value customers correctly, and forecast demand precisely enough to avoid both stockouts and overstock.

Business Problems This System Solves

The personalization gap: Email campaigns sent to entire segments with the same message; product recommendations driven by simple collaborative filtering that ignored recent purchase context and lifecycle stage.
Invisible churn: Customers quietly stopped purchasing with no early warning. Retention campaigns were reactive — triggered only after a customer had already churned, making reactivation roughly 5× more expensive than prevention.
Inventory blindness: Demand forecasting relied on historical sales averages with manual seasonal adjustments, causing costly stockouts during peak periods and overstock in slow-moving categories.
LTV misallocation: Customer acquisition spend was allocated based on channel cost rather than predicted lifetime value — high-potential customers received the same marketing budget as low-LTV transient shoppers.

+33%

Revenue From AI Personalization

vs. rules-based baseline

-28%

Inventory Carrying Cost

Through demand forecasting

92%

Churn Model Accuracy (AUC)

Across 15M+ customer base

2. System Architecture

The platform follows a layered microservices architecture, mirroring the same architectural philosophy used across JoNoleecy AI implementations: a clean separation between presentation, business services, AI/LLM inference, agent orchestration, and data — communicating through well-defined REST APIs and an event-driven Kafka backbone.

System Architecture — E-Commerce Predictive Analytics Platform

Presentation

React Analytics Dashboard Personalization API Client Admin Console

↕ REST / GraphQL / WebSocket

API Gateway

Spring Boot API Gateway Keycloak / JWT Auth Circuit Breaker Audit Logger

↕ Internal REST / Kafka Events

Business Services

Customer Profile Service Prediction Service Inventory Forecast Service Campaign Service

↕ AI Inference API

AI / LLM Layer

LLM Orchestrator (Spring AI) GPT-4o Turbo (LLM) Churn Model (LightGBM) LTV Model (XGBoost) Demand Model (TFT) Embedding Store

↕ Agent Tool Calls / MCP

Agent Layer

Analytics Orchestrator Agent Churn Prediction Agent LTV Scoring Agent Demand Forecast Agent Insight Narrator Agent Campaign Optimizer Agent

↕ JDBC / Kafka

Data Layer

MySQL (Transactional) Redis (Cache) Kafka (Event Stream) Pinecone (Vectors) Snowflake (Analytics)

Infrastructure

AWS EKS SageMaker Docker Containers Terraform IaC Datadog Observability

Technology Stack

Layer	Technology	Rationale
Backend	Java 17 + Spring Boot 3.2 + WebFlux	Reactive streams for high-throughput prediction serving at millions-of-customer scale
Frontend	React 18 + TypeScript + Recharts	Rich interactive analytics dashboards with real-time chart updates via WebSocket
Primary Database	MySQL 8.0 (AWS RDS Multi-AZ)	Customer profiles, order history, prediction outputs — ACID compliance, read replicas for analytics
Analytics Warehouse	Snowflake	Petabyte-scale analytical queries; Snowpark for in-warehouse feature computation
Feature Store	AWS SageMaker Feature Store	Consistent feature serving for online (real-time) and offline (training) use cases
Event Streaming	Apache Kafka (MSK)	Real-time clickstream, order, and browse event ingestion at millions of events/hour
Cache	Redis 7 Cluster	Customer segment, recommendation, and prediction cache — sub-millisecond serving
Vector DB	Pinecone	Product and customer embeddings for semantic recommendation and similarity search
LLM Primary	GPT-4o Turbo (Azure OpenAI)	Cohort narrative generation, insight summarization, marketing copy
LLM Batch	Claude 3.5 Haiku	High-volume nightly batch: product enrichment, category summaries, email subject lines
ML Framework	XGBoost + LightGBM + PyTorch	Gradient boosting for tabular predictions; deep learning for demand forecasting
ML Platform	AWS SageMaker + MLflow	Managed training, experiment tracking, model registry, A/B testing

Architecture Principles

AI as a service layer, not embedded logic: All ML inference is isolated behind a clean API so models can be retrained or swapped without touching business logic.
Event-driven for real-time responsiveness: Orders, clickstream events, and engagement signals are published to Kafka and consumed immediately by prediction services.
Human-approved actions only: Every campaign, discount, or outreach recommended by an agent requires marketing or merchandising sign-off before execution.
Explainability by design: Every churn and LTV prediction includes SHAP-based feature attribution so business teams understand why, not just what.

3. Data Model — MySQL Schema Design

The core MySQL schema centres on the Customer entity, with related tables capturing orders, clickstream behaviour, and AI prediction outputs. All tables follow consistent audit and indexing conventions optimised for both transactional writes and analytical read patterns.

Core Entity: Customers

SQLcustomers table
-- Central customer entity with AI-derived fields
CREATE TABLE customers (
  customer_id            BIGINT PRIMARY KEY AUTO_INCREMENT,
  email_hash             VARCHAR(64)  UNIQUE,         -- hashed for PII compliance
  registration_date      DATE,
  acquisition_channel    VARCHAR(64),
  lifecycle_stage        ENUM('NEW','ACTIVE','AT_RISK','DORMANT','CHURNED','REACTIVATED'),
  predicted_ltv_tier     ENUM('CHAMPION','LOYAL','POTENTIAL','AT_RISK','LOST'),
  clv_score              DECIMAL(10,2),     -- predicted 12-month LTV
  churn_probability      DECIMAL(5,4),
  next_purchase_days     INT,             -- predicted days to next order
  preferred_category     VARCHAR(64),
  price_sensitivity      ENUM('LOW','MEDIUM','HIGH'),
  last_scored_at         TIMESTAMP,
  created_at             TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  INDEX idx_lifecycle (lifecycle_stage),
  INDEX idx_churn (churn_probability DESC),
  INDEX idx_ltv (clv_score DESC)
);

-- Order transactions
CREATE TABLE orders (
  order_id               BIGINT PRIMARY KEY AUTO_INCREMENT,
  customer_id            BIGINT REFERENCES customers(customer_id),
  order_date             TIMESTAMP,
  total_amount           DECIMAL(10,2),
  item_count             INT,
  discount_applied       DECIMAL(5,2),
  fulfilment_channel     ENUM('WAREHOUSE','DROPSHIP','MARKETPLACE'),
  status                 ENUM('PLACED','SHIPPED','DELIVERED','RETURNED','REFUNDED'),
  INDEX idx_customer_date (customer_id, order_date DESC)
);

Behavioural & AI Prediction Tables

SQLclickstream & prediction_outputs tables
-- High-volume clickstream events — primary training signal
CREATE TABLE clickstream_events (
  event_id               BIGINT PRIMARY KEY AUTO_INCREMENT,
  customer_id            BIGINT,             -- null if anonymous
  session_id             VARCHAR(64),
  event_type             ENUM('VIEW','SEARCH','ADD_CART','REMOVE_CART','PURCHASE','WISHLIST'),
  product_id             BIGINT,
  category_id            INT,
  dwell_time_ms          INT,
  occurred_at            TIMESTAMP,
  INDEX idx_customer_session (customer_id, session_id),
  INDEX idx_occurred (occurred_at DESC)
);

-- AI prediction outputs — flexible JSON for varying model schemas
CREATE TABLE prediction_outputs (
  prediction_id          BIGINT PRIMARY KEY AUTO_INCREMENT,
  customer_id            BIGINT REFERENCES customers(customer_id),
  model_name             VARCHAR(64),
  model_version          VARCHAR(32),
  prediction_type        ENUM('CHURN','LTV','NEXT_PURCHASE','SEGMENT','DEMAND'),
  prediction_value       JSON,             -- flexible output format
  shap_explanation       JSON,             -- top contributing factors
  confidence             DECIMAL(5,4),
  valid_until            TIMESTAMP,         -- prediction expiry
  created_at             TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  INDEX idx_customer_type (customer_id, prediction_type),
  INDEX idx_model (model_name, model_version)
);

Event-Driven Architecture with Kafka

PseudocodeKafka topic & consumer architecture
TOPICS:
  ecom.clickstream.raw          // Raw browser events (100k+ events/hour)
  ecom.orders.placed            // New orders — triggers LTV recalculation
  ecom.orders.completed         // Delivered orders — updates RFM features
  ecom.predictions.churn        // Churn score outputs → CRM integration
  ecom.alerts.churn-risk        // High-risk customers → retention trigger
  ecom.demand.forecast          // SKU demand forecasts → inventory system

CONSUMER GROUPS:
  prediction-service            // Triggers ML rescoring on order events
  personalization-engine        // Updates recommendation cache on segment change
  crm-integration               // Syncs scores to Salesforce / HubSpot
  inventory-service              // Consumes demand forecasts for reorder triggers
  analytics-sink                 // Streams all events to Snowflake

4. Backend — Spring Boot Prediction Service

The backend is a Spring Boot 3.x WebFlux application, chosen specifically for its reactive, non-blocking I/O model — essential for serving real-time predictions to logged-in customers within a sub-100ms budget while a nightly batch job scores all 15 million customers in parallel.

Customer Prediction Service — Core Logic

Java (Pseudocode)CustomerPredictionService.java
/**
 * Core service serving real-time predictions for a logged-in customer.
 * Called on page load — must complete in <100ms via Redis cache.
 */
@Service
public class CustomerPredictionService {

    private final RedisTemplate redisCache;
    private final FeatureStoreClient featureStore;
    private final MlInferenceClient mlClient;
    private final KafkaTemplate kafkaProducer;

    public CustomerPredictions getPredictions(Long customerId) {

        // 1. Check cache (TTL: 1 hour for most predictions)
        var cached = redisCache.get(PREDICTION_KEY + customerId);
        if (cached != null && !cached.isStale()) return cached;

        // 2. Fetch feature vector from SageMaker Feature Store
        var features = featureStore.getOnlineFeatures(customerId, FEATURE_NAMES);

        // 3. Call churn, LTV, and next-purchase models in parallel
        var churnFuture  = mlClient.predictAsync("churn-model-v3",   features);
        var ltvFuture    = mlClient.predictAsync("ltv-model-v2",     features);
        var nextPurchFut = mlClient.predictAsync("next-purchase-v1", features);

        var predictions = CustomerPredictions.builder()
            .churnProbability(churnFuture.get().getScore())
            .churnFactors(churnFuture.get().getShapExplanation())
            .predictedLtv(ltvFuture.get().getValue())
            .nextPurchaseDays(nextPurchFut.get().getDays())
            .build();

        // 4. Cache and persist
        redisCache.set(PREDICTION_KEY + customerId, predictions, Duration.ofHours(1));

        // 5. Publish churn alert if threshold exceeded
        if (predictions.getChurnProbability() > CHURN_ALERT_THRESHOLD) {
            kafkaProducer.send("ecom.alerts.churn-risk",
                new ChurnRiskEvent(customerId, predictions.getChurnProbability()));
        }

        return predictions;
    }

    /**
     * Nightly batch scoring — runs via Spring Batch across 15M+ customers.
     */
    @Scheduled(cron = "0 0 2 * * *")
    public void runNightlyBatchScoring() {
        springBatchJobLauncher.run(customerScoringJob, ...);
    }
}

5. AI & LLM Layer

As with every JoNoleecy AI implementation, this platform separates classical ML models (for numerical scoring: churn, LTV, demand) from a Large Language Model layer responsible for translating those predictions into business-readable insight and generating personalised marketing language.

LLM Selection: GPT-4o Turbo as Primary, Claude Haiku for Batch

Criterion	Why It Matters Here	Model Choice
Narrative quality	Cohort insights and campaign copy must read naturally to non-technical merchandising teams	GPT-4o Turbo — strong business-tone generation
Cost at volume	Nightly batch tasks touch millions of products and customer segments	Claude 3.5 Haiku — low cost per token for high-volume batch
Structured output	Insight payloads must parse cleanly into typed Java objects for the dashboard	Both models support reliable JSON-mode output
Text-to-SQL	Merchandisers ask natural-language questions against the Snowflake warehouse	GPT-4o Turbo with schema-grounded prompting

Cohort Insight Generation — Prompt Design

Prompt Template (Pseudocode)Nightly cohort narrative generation
SYSTEM PROMPT:
You are a senior e-commerce analyst. Your job is to turn predictive model outputs
into clear, actionable business narratives for merchandising and marketing teams.
Write in plain business language. Be specific about numbers. Always tie insights
to a recommended action. Output must be valid JSON matching the schema provided.

OUTPUT SCHEMA:
{
  "headline":                string,   // one-sentence insight
  "narrative":                string,   // 3-4 sentence explanation
  "recommended_actions":      string[],
  "urgency":                  string,   // low|medium|high|critical
  "campaign_subject_line":    string,
  "expected_recovery_rate":   string
}

---
USER PROMPT (injected dynamically per segment):
Segment: {segmentName}
Total customers: {count}
Avg churn probability: {avgChurn}
Revenue at risk (30d): ${revenueAtRisk}
Top 3 churn drivers (SHAP aggregation): {factor1}, {factor2}, {factor3}
Recent purchase category trend: {categoryTrend}
Email response rate (last campaign): {emailResponseRate}%

Generate the cohort insight now.

LLM Use Cases Across the Platform

Cohort narrative generation: nightly transformation of ML outputs into business-readable insight summaries for the analytics dashboard.
Email campaign personalization: personalised subject lines and preview text per customer segment, tied to predicted behaviour and LTV tier.
Product description enrichment (batch, Claude Haiku): semantic tags and embeddings improving recommendation relevance across the 2M+ SKU catalogue.
Natural language analytics queries: merchandisers type questions like "Which categories are driving churn in the 25–35 segment?" — the LLM generates and executes the Snowflake SQL.

6. Multi-Agent Architecture

Five specialised agents collaborate under a top-level orchestrator — each with a focused role, dedicated tools, and the ability to publish events that trigger downstream agents.

Why Multi-Agent vs. a Single LLM Call?

Churn scoring, LTV calculation, demand forecasting, and campaign optimisation each require different data, different reasoning patterns, and different failure-tolerance levels. A single monolithic prompt trying to do all four produces mediocre results everywhere; specialised agents with focused context produce substantially better outcomes at each task.

Agent Roster

🎯

Analytics Orchestrator Agent

Top-level agent receiving requests from the Spring Boot layer. Decomposes requests, routes to specialist agents, and assembles the final response. Implemented with LangGraph4j for stateful, multi-step orchestration.

📉

Churn Prediction Agent

Monitors the Kafka event stream for behavioural signals predicting churn — declining session frequency, rising return rate, category narrowing. Classifies the trigger pattern (price-driven, competitive, experience-driven, lifecycle) and recommends an intervention type.

💎

LTV Scoring Agent

Runs on every completed order to recalculate predicted 12-month Customer Lifetime Value. Segments customers into five tiers (Champion, Loyal, Potential, At-Risk, Lost) and publishes tier changes that trigger ad-bid adjustments and loyalty tier updates.

📦

Demand Forecast Agent

Runs nightly SKU-level forecasts for a 28-day horizon, ingesting historical sales, current inventory, promotional calendar, and external signals like weather and search trend data. Outputs feed directly into automated reorder triggers.

📝

Insight Narrator Agent

Transforms raw model outputs and trend data into business-readable narratives for the analytics dashboard — cohort summaries, weekly trend reports, and anomaly explanations, on schedule and on-demand.

🎯

Campaign Optimizer Agent

Given a marketing objective and budget, identifies the optimal cohort, channel mix, offer type, and timing. Campaign configurations are sent to a CRM approval queue — always requiring human sign-off before send.

7. MCP — Model Context Protocol Integration

As with the collections platform, MCP gives the agent layer structured, type-safe access to customer data, the analytics warehouse, and downstream services — without hardcoding tool implementations inside prompts.

What MCP Solves Here

Without MCP, every tool an agent needs must be described in natural language and its output parsed manually. MCP provides a typed contract: the LLM declares what it needs, the MCP server fetches it, and the result returns in a structured format the Java layer can validate.

MCP Server Design — E-Commerce Analytics Tools

MCP Tool Name	Description	Returns
`get_customer_predictions`	Returns all current predictions for a customer: churn, LTV, next purchase, segment	CustomerPredictions (JSON)
`query_customer_cohort`	Returns customers matching prediction criteria (e.g., high churn + high LTV)	Page<CustomerSummary>
`run_analytics_query`	Converts a natural language question into validated Snowflake SQL and returns results	QueryResult
`get_demand_forecast`	Returns 28-day demand forecast for a product SKU with confidence intervals	DemandForecast
`trigger_retention_campaign`	Write-tool: queues a retention campaign for a customer cohort	CampaignQueueResult

Java (Pseudocode)EcomAnalyticsMcpServer.java — MCP tool definitions
/**
 * Spring Boot MCP Server exposing e-commerce analytics tools to AI agents.
 */
@McpServer(name = "ecom-analytics")
public class EcomAnalyticsMcpServer {

    @McpTool(
        name = "run_analytics_query",
        description = "Convert a natural language question into Snowflake SQL and return results"
    )
    public QueryResult runAnalyticsQuery(String naturalLanguageQuestion) {
        var sql = textToSqlService.generateSql(naturalLanguageQuestion, SNOWFLAKE_SCHEMA);
        sqlValidator.validate(sql);   // safety check before execution
        return snowflakeClient.execute(sql);
    }

    @McpTool(
        name = "trigger_retention_campaign",
        description = "Queues a retention campaign for a customer cohort — requires human approval"
    )
    @RequiresHumanApproval(approvalType = "CAMPAIGN_SEND")
    public CampaignQueueResult triggerCampaign(
            String cohortId, String campaignType, String offerId) {
        return campaignService.queueForApproval(cohortId, campaignType, offerId);
    }
}

8. React Frontend — Analytics Dashboard

The frontend is a React 18 + TypeScript application built around React Query for server state. The primary surface is a Churn Risk Dashboard giving merchandising and retention teams a live view into at-risk revenue and actionable interventions.

TypeScript / React (Pseudocode)ChurnRiskDashboard.tsx
// Merchandising team's churn risk dashboard
const ChurnRiskDashboard: React.FC = () => {

  const { data: cohorts } = useQuery({
    queryKey: ['churn-cohorts'],
    queryFn: () => analyticsApi.getChurnCohorts({ days: 30, threshold: 0.7 }),
    refetchInterval: 5 * 60 * 1000,
  });

  // Real-time churn alert stream via WebSocket
  const [liveAlerts, setLiveAlerts] = useState<ChurnAlert[]>([]);
  useWebSocket('/ws/churn-alerts', {
    onMessage: (alert) => setLiveAlerts(prev => [alert, ...prev].slice(0, 50))
  });

  return (
    <DashboardLayout>
      <ChurnFunnelChart data={cohorts?.byLtvTier} title="At-Risk Customers by LTV Tier" />
      <RevenueAtRiskCard totalAtRisk={cohorts?.revenueAtRisk} />
      <FeatureImportanceChart features={cohorts?.topChurnFactors}
        title="Why Customers Are Churning This Month" />
      <LiveAlertFeed alerts={liveAlerts} />
      <RetentionCampaignPanel segments={cohorts?.actionableSegments}
        onTriggerCampaign={(id, type) => campaignApi.trigger(id, type)} />
    </DashboardLayout>
  );
};

Design Principle: AI Surfaces Insight, Humans Approve Action

The dashboard never auto-sends a campaign. Every retention action recommended by the Campaign Optimizer Agent is queued for human review — the marketing manager approves the batch before send, with full visibility into the AI's reasoning and predicted ROI.

9. Predictive Model Architecture

Model 1: Customer Churn Predictor (LightGBM)

Python (Pseudocode)Churn model feature engineering
# Recency-Frequency-Monetary (RFM) features
CHURN_FEATURES = {
    'days_since_last_order',        # core churn signal
    'order_count_90d',               # purchase frequency
    'revenue_trend_30_60d',          # slope of spend change

    # Engagement features
    'session_count_30d',
    'search_to_purchase_ratio',      # friction indicator
    'email_click_rate_90d',

    # Negative experience signals
    'return_rate_90d',               # dissatisfaction proxy
    'cart_abandonment_rate_30d',

    # Category and seasonality
    'promotion_dependency',          # only buys on discount
    'customer_tenure_days',
}

# Model output per customer
OUTPUT = {
    'churn_probability': float,             # 0.0–1.0
    'churn_trigger_type': str,           # price / competitive / experience / lifecycle
    'top_factors': List[ShapFactor],
    'recommended_intervention': str,
}

Model 2: Customer Lifetime Value Predictor (XGBoost)

Python (Pseudocode)Two-stage CLV model
# Stage 1: Will the customer make any purchase? (binary classification)
# Stage 2: If yes, how much revenue? (regression)
# CLV = P(purchase) × E(revenue | purchase) × expected_purchase_count

CLV_FEATURES = {
    'total_lifetime_revenue', 'avg_inter_purchase_days',
    'high_margin_category_share',
    'full_price_purchase_rate',     # willingness to pay full price
    'engagement_trend_90d',          # improving / stable / declining
    'estimated_income_band',         # from third-party enrichment
}

Model 3: Demand Forecasting (Temporal Fusion Transformer)

Python (Pseudocode)TFT demand forecast — SKU-level 28-day horizon
# Temporal Fusion Transformer: multi-horizon time series
# with static and time-varying covariates

STATIC_FEATURES = ['sku_id', 'category_id', 'price_tier', 'product_lifecycle_stage']

TIME_VARYING_KNOWN = ['promotional_flag', 'holiday_flag', 'planned_listing_price']

TIME_VARYING_UNKNOWN = ['units_sold', 'page_views', 'conversion_rate', 'weather_index']

# Output per SKU: point forecast, P10/P50/P90 quantiles for safety stock,
# and a reorder trigger with recommended order quantity

10. Key System Flows

Flow 1: Real-Time Personalization on Homepage Load

Customer Identified

JWT decoded → customer_id extracted. Prediction cache checked in Redis (<5ms hit latency).

Predictions Retrieved

Cached churn, LTV tier, next-purchase category, and price sensitivity returned — <10ms on cache hit.

Personalization Applied

Recommendation engine selects homepage modules based on customer embedding and predictions — at-risk customers see loyalty messaging, high-LTV customers see premium products.

Clickstream Logged

Page interactions streamed to Kafka, feeding the next prediction cycle.

Flow 2: Churn Alert → Retention Campaign

Churn Threshold Crossed

Order event triggers rescoring. Probability moves 0.61 → 0.78, exceeding the 0.70 alert threshold. Event published to Kafka.

Campaign Optimizer Agent Invoked

Agent fetches customer profile, LTV tier, churn trigger type, and historical campaign response rates via MCP tools.

Intervention Selected

Loyal + price-driven churn → 10% loyalty reward via email (not a blanket discount — protects margin). LLM generates personalised subject line.

Human Approval & Send

Campaign queued in CRM with full context. Marketing manager approves; campaign sent within 2 hours of the original churn signal, with automatic A/B tracking.

11. Deployment & MLOps

The platform runs on AWS EKS, with each service deployed as an independent containerised microservice, infrastructure defined in Terraform, and changes flowing through GitHub Actions CI/CD with mandatory test gates.

Capability	Implementation	Scale Target
Real-time prediction serving	Spring WebFlux + Kubernetes HPA	<50ms p99, 10K req/sec
Batch scoring (nightly)	Spring Batch + SageMaker Processing	15M+ customers in <4 hours
Feature computation	Kafka Streams + Flink	Real-time, <30s feature freshness
Model retraining (churn)	SageMaker Training Job, weekly	Full retrain in <2 hours
Model monitoring	Evidently AI + Grafana	Daily PSI/KS drift checks
LLM cost management	Prompt caching, Haiku for batch tasks	<$0.02 per customer insight generated
Model registry	MLflow on AWS	Full lineage, comparison, rollback

12. Outcomes & Metrics

Measured over a representative 6-month production period across the platform's customer base, compared against the prior rules-based baseline: