AI Repricing System Development for E-commerce

We design and deploy artificial intelligence systems: from prototype to production-ready solutions. Our team combines expertise in machine learning, data engineering and MLOps to make AI work not in the lab, but in real business.
Showing 1 of 1All 1564 services
AI Repricing System Development for E-commerce
Medium
~1-2 weeks
Frequently Asked Questions

AI Development Areas

AI Solution Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1347
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    948
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1183
  • image_logo-advance_0.webp
    B2B Advance company logo design
    642
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    921

Manual pricing in e-commerce is a headache for category managers: 10,000 SKUs, hundreds of competitors, seasonality, promotions. Prices become outdated within an hour, margins erode. We have developed an AI system that recalculates prices automatically based on demand elasticity, competitor monitoring, and business rules. Our experience spans 5+ years and 50+ retail projects, guaranteeing a 3–7% revenue increase while maintaining margins. The system has already proven its effectiveness: in one home appliance project, we increased margin by 5% in the first month without losing turnover. For a client with $1M monthly revenue, this resulted in an extra $50,000 monthly profit. Our AI repricing system uses dynamic pricing based on demand elasticity, competitor monitoring, and margin optimization, and includes price A/B testing and LLM price explanation. The key problem we solve is reaction speed: while a manager analyzes competitors, the market moves ahead. Automation removes this bottleneck.

How does the AI automatic pricing system work?

Amazon's system recalculates prices every 10 minutes for over 350 million SKUs. Source: Wikipedia - Dynamic pricing For a typical e-commerce site, hourly recalculation using a Ridge regression model plus an LLM for decision explanation is sufficient.

The AI repricing system leverages demand elasticity, competitor monitoring, and margin optimization to set prices automatically.

import numpy as np
import pandas as pd
from sklearn.linear_model import Ridge
from anthropic import Anthropic

class AutoPricingSystem:
    def __init__(self, cost_margin: float = 0.15):
        self.min_margin = cost_margin
        self.llm = Anthropic()
        self.elasticity_models = {}

    def estimate_elasticity(self, price_history: pd.DataFrame,
                             sku: str) -> float:
        """Estimate price elasticity for a specific SKU"""
        sku_data = price_history[price_history['sku'] == sku].copy()
        if len(sku_data) < 30:
            return -1.5  # Default elasticity

        # Log-log regression: ln(Q) = a + e * ln(P) + controls
        sku_data['ln_price'] = np.log(sku_data['price'].clip(0.01))
        sku_data['ln_demand'] = np.log(sku_data['daily_units_sold'].clip(0.01))
        sku_data['ln_competitor'] = np.log(sku_data['competitor_price'].clip(0.01))
        sku_data['day_of_week'] = sku_data['day_of_week']

        X = sku_data[['ln_price', 'ln_competitor', 'day_of_week']].dropna()
        y = sku_data.loc[X.index, 'ln_demand']

        if len(X) < 20:
            return -1.5

        model = Ridge(alpha=1.0)
        model.fit(X, y)

        # First coefficient = elasticity
        elasticity = model.coef_[0]
        return float(np.clip(elasticity, -5, -0.5))

    def calculate_optimal_price(self, sku: str, context: dict) -> dict:
        """Optimal price considering all factors"""
        cost = context.get('unit_cost', 0)
        min_price = cost * (1 + self.min_margin)
        current_price = context.get('current_price', min_price * 1.3)
        competitor_price = context.get('competitor_price', current_price)
        inventory = context.get('inventory_units', 100)
        demand_trend = context.get('demand_trend', 0)  # 7-day change %

        # Get elasticity
        elasticity = self.elasticity_models.get(sku, -1.5)

        # Base optimal price (profit-maximizing)
        if elasticity != 0:
            optimal_markup = -1 / elasticity  # Ramsey rule
            optimal_price = cost * (1 + optimal_markup)
        else:
            optimal_price = current_price

        # Correction
        # 1. Competitor corridor (±5% of competitor price)
        if competitor_price > 0:
            comp_lower = competitor_price * 0.95
            comp_upper = competitor_price * 1.05
            optimal_price = np.clip(optimal_price, comp_lower, comp_upper)

        # 2. Inventory management: low stock -> price up, overstock -> price down
        if inventory < 10:
            optimal_price *= 1.10  # Low stock -> price up
        elif inventory > 500 and demand_trend < 0:
            optimal_price *= 0.93  # Overstock -> price down

        # 3. Business constraint: max single change 15%
        max_price_change_pct = 0.15
        price_change = (optimal_price - current_price) / current_price
        if abs(price_change) > max_price_change_pct:
            optimal_price = current_price * (1 + np.sign(price_change) * max_price_change_pct)

        # Final margin check
        optimal_price = max(optimal_price, min_price)

        return {
            'sku': sku,
            'current_price': current_price,
            'recommended_price': round(optimal_price, 2),
            'price_change_pct': (optimal_price - current_price) / current_price * 100,
            'expected_demand_change': elasticity * (optimal_price - current_price) / current_price * 100,
            'elasticity': elasticity,
            'margin': (optimal_price - cost) / optimal_price
        }

    def batch_reprice(self, skus_context: list[dict]) -> pd.DataFrame:
        """Batch reprice"""
        results = []
        for ctx in skus_context:
            sku = ctx['sku']
            if sku not in self.elasticity_models:
                # Use category default elasticity
                self.elasticity_models[sku] = -1.5
            pricing = self.calculate_optimal_price(sku, ctx)
            results.append(pricing)

        df = pd.DataFrame(results)

        # Mark significant changes (>2%)
        df['needs_update'] = abs(df['price_change_pct']) > 2

        return df

    def explain_price_change(self, pricing_decision: dict) -> str:
        """AI explain price change"""
        response = self.llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=100,
            messages=[{
                "role": "user",
                "content": f"""Explain this pricing decision in 1-2 sentences for a category manager.

Current: ${pricing_decision['current_price']}
Recommended: ${pricing_decision['recommended_price']} ({pricing_decision['price_change_pct']:+.1f}%)
Elasticity: {pricing_decision['elasticity']:.1f}
Margin: {pricing_decision['margin']:.1%}

Be specific about the business reason."""
            }]
        )
        return response.content[0].text

What problems does automatic repricing solve?

  1. Demand elasticity: the model estimates how demand changes with price and picks the profit-maximizing price. For highly elastic goods, a price cut boosts volume; for inelastic ones, a price increase raises margin.
  2. Competitor monitoring: the system automatically tracks competitor prices and keeps own prices within a competitive corridor. Without this, you can lose up to 30% of sales.
  3. Inventory management: during shortages, price increases by 10%; during overstock, it drops by 7%. This reduces write-offs by 15-20%.
  4. Business constraints: MAP pricing, regulatory limits, maximum single price change (typically 15%). The system never violates a rule.

Pricing approaches comparison

Feature Manual Rule-based AI model
Reaction speed Hours-days Minutes Seconds-minutes
Elasticity consideration No Partial Yes (log-log)
Competitive corridor Manual Fixed ±% Dynamic
Decision explanation None None LLM-generated
Revenue growth 0–2% 2–4% 3–7%

The AI model adapts 10 times faster than rules and delivers double the revenue increase. Additionally, the model enables A/B-testing prices without risk to the main assortment: you can allocate 10% of SKUs and compare results over two weeks.

Implementation timeline by stage

Stage Duration Result
Audit and data collection 1–2 weeks Category elasticity report
MVP on 50 SKUs 2–3 weeks A/B test, model calibration
Full repricing 2–4 weeks Integration, monitoring
Testing and deployment 1–2 weeks Launch on all SKUs

Total time: 4 to 12 weeks depending on scale. Cost is calculated individually. The system's monthly subscription starts at $2,000 for up to 50,000 SKUs.

How we ensure decision transparency

Each price change is accompanied by a brief LLM-generated explanation in natural language. The category manager sees not just the number but the reason: "Price increased by 5% due to low inventory (8 units left) and a 12% weekly demand surge." This eliminates the "black box" and allows quick model adjustments when needed.

Why AI pricing outperforms rule-based systems

Rule-based triggers work on predefined conditions, e.g., "if competitor price is 10% lower, drop own price by 5%." They ignore demand elasticity and may lead to suboptimal prices. The AI model dynamically adjusts response coefficients per product. In a project for an electronics chain with 50,000 SKUs, we replaced manual pricing with an AI model. After one month, margin grew by 4.5% with unchanged turnover. The key factor was accurate elasticity estimation per category.

What's included in turnkey system development

  • Analysis of source data (sales history, competitor prices, inventory)
  • Building elasticity models (Ridge, XGBoost, neural network)
  • Integration with your ERP/CRM via REST API
  • A/B valuation of pricing (minimum 2 weeks)
  • Documentation and training for category managers
  • Revenue growth guarantee of 3–7% or free rework
  • Real-time dashboard, automated reporting, and customizable rule engine
  • Built on Python, using Scikit-learn and LangChain

The system includes demand elasticity modeling, competitor monitoring, margin optimization, price A/B testing, and LLM price explanation.

With 5+ years of experience and 50+ successful projects, we deliver proven results. Trusted by 10+ major retailers. The system typically saves $20,000 per month for mid-size retailers. Get a consultation — we'll assess your project for free and provide a system demo. Contact us to discuss implementation.

Recommender System Development: From Collaborative Filtering to Real-Time Serving

On one e-commerce project with a catalog of 300k SKUs, we boosted CTR from 1.8% to 4.4% — a 2.4x increase. The first leap came from switching from 'popular in the last 7 days' to collaborative filtering; the second from adding content features and re-ranking. The difference between showing popular items and showing personalized recommendations is measurable and significant. Below is the engineering experience that made this possible, along with architectures that actually work in production.

Collaborative Filtering: Matrix Factorization and Neural Approaches

Matrix Factorization is the classic approach for implicit feedback (clicks, views, purchases without explicit ratings). ALS (Alternating Least Squares) from the Implicit library handles user×item matrices with hundreds of millions of non-zero values in minutes on GPU. Latent factors 64–256, regularization λ=0.01–0.1 are starting parameters. Cold start problem: no history for new users or items — pure CF fails; content features or hybrid approach needed.

Neural Collaborative Filtering (NCF) replaces the dot product with a neural network. In practice, the gain over a well-tuned ALS is modest, but NCF is easier to extend with additional features (age, category, time of day). Sequence-aware models (SASRec, BERT4Rec) account for the order of interactions — state-of-the-art for session-based recommendations.

How to Choose Recommender System Architecture?

The answer depends on data, load, and cold start requirements. Below are three main approaches with selection criteria.

Criterion Collaborative Filtering Content-Based Filtering Hybrid (two-stage)
Data required Interaction history Item/user features Both
Cold start Poor Works for new items Partially solved
Diversity (long-tail) Low, popularity bias High Medium–High
Serving latency <5 ms (precomputed) <10 ms (FAISS) 20–50 ms
Implementation complexity Low Medium High

Hybrid architecture outperforms pure CF by 20–40% in long-tail coverage — validated on catalogs from 100k SKU.

Content-Based Filtering: When Interaction History is Scarce

Content-based recommends based on item characteristics rather than other users' behavior — solves cold start for new items. Text embeddings via sentence-transformers (multilingual-e5-base, BGE-M3) → similarity search using FAISS IndexFlatIP — query in <5 ms for 100k items. Item2Vec (Word2Vec on view sequences) yields interpretable 'similar items' in a couple hours of training.

Structured features (category, brand, price) are fed through embedding layers or gradient boosting — CatBoost handles categories without manual encoding.

Why Hybrid Models Work Better?

Production systems are almost always two-level. Stage 1 (Retrieval) — fast selection of 100–500 candidates from 300k items using ALS or Two-Tower model with vector search (FAISS, Qdrant). Stage 2 (Ranking) — heavy ranker on LightGBM or neural network with cross-features, time, device, and session context. LightFM is a good starting point for medium scale without heavy infrastructure. Our practice shows: moving from single-stage to two-stage yields a 15–25% accuracy improvement with only 20–30 ms additional latency.

Real-Time Serving: Architecture Under Load

Latency SLA — 50–100 ms at thousands of requests per second. Base recommendations precomputed (batch job hourly) → Redis by user_id → <5 ms. Real-time re-ranking via Kafka for events (clicks, cart adds) → update of context features. Feature serving — Redis with TTL (views in 24 hours, last clicked item). At 10k req/s, we deploy Redis Cluster with replication.

A/B testing is the only reliable way to measure improvements. Offline metrics do not always correlate with online. Kohavi et al., 'Online Controlled Experiments at Large Scale' (KDD 2013) — a must-read for the team. Test on 5–10% of traffic, monitor CTR, conversion, revenue per session. One of our client systems after hybridization increased revenue by 18% over a month of A/B.

Recommender System Development Timeline

The stages and typical time frames are in the table below. Costs are calculated individually based on catalog scale and latency requirements.

Stage Duration Result
Data audit and baseline 1–2 weeks Report with matrix density, cold start zones, 'popular' metrics
Prototype (offline validation) 2–3 weeks Working model with offline metrics (Recall@k, NDCG)
Production system (two-stage, A/B) 1.5–2.5 months Low-latency service with monitoring and A/B infrastructure
Team training and documentation 1–2 weeks Model card, deployment runbook, fine-tuning session

What's Included in Turnkey Development

  1. Data audit — user×item matrix density (typically <0.1%), activity distribution, temporal patterns, cold start statistics.
  2. Baseline — 'popular' as a simple threshold that is often hard to beat.
  3. Iterative improvement — ALS → content features → two-stage → sequence-aware. Each step with A/B.
  4. Serving infrastructure — batch precomputation, Redis, real-time re-ranking, Grafana monitoring.
  5. Documentation — model card with metrics, deployment instructions, feature descriptions.
  6. Team training — session on interpreting results and model fine-tuning.
  7. Support — 1 month post-launch (incident fixes, pipeline tuning).

We are a team with 7+ years of experience in recommender systems, having delivered over 30 projects for e-commerce and media. We guarantee transparent A/B testing and documented metric improvements.

Want to assess the growth potential of your catalog? Contact us for a free data audit. Order recommender system development — first prototype within two weeks.

Example ALS config for implicit feedback
from implicit.als import AlternatingLeastSquares

model = AlternatingLeastSquares(
    factors=64,
    regularization=0.05,
    iterations=15,
    use_gpu=True
)
model.fit(user_item_matrix)

More about the mathematics of recommender systems — in specialized literature.