Predictive E-commerce on Aito

Turn Your Commerce Platform into a Predictive Application

A predictive application is an operational SaaS where the data layer doesn't just store transactions — it predicts the next one. Predictive e-commerce means search results that re-rank for the customer in front of you, recommendations that learn from every click and purchase, demand forecasts that drive replenishment, inventory reorders that come with revenue-at-risk-in-€, markdowns that pick the discount that clears in three months at the highest recoverable margin, and churn risk surfaced before a customer goes silent.

Aito is the predictive database underneath. Every prediction comes back with a probability, top-3 alternatives, and a $why factor decomposition. No retraining, no MLOps, no separate ML pipeline alongside your storefront or merchandising tables.

Live Reference: ecommerce.aito.ai

ecommerce.aito.ai is our open-source reference implementation of a predictive e-commerce platform — 16 production-ready views built on _predict, _relate, _search, _recommend, _estimate, and _evaluate. PetNord is a synthetic Nordic-flavoured pet-store dataset generated deterministically from data/generate_fixtures.py (seed 42) to drive the demo: 658 SKUs, 3,000 customers, 12,215 orders, 38,013 order lines, 6,000 reviews, a 26,496-row customer-month panel for churn modelling, and 11,090 SKU-month rows for demand forecasting. Numbers cited from PetNord below are computed against this fixture — reproducible against the live demo, not customer outcomes.

Explore the Use Cases →  ·  Try the Live Demo →  ·  Source on GitHub →

What's Inside the Predictive E-commerce Reference

Sixteen views grouped under seven AAA-aligned sections, all reading from a single Aito database.

Overview

• 📊 Dashboard — KPI grid, top purchase patterns via six parallel _relate calls, segment cards via _search, recent orders. The same query body Bought Together runs per anchor — the 2.7× dental-treats lift surfaces in both views.

Assist (consumer-facing intelligence)

• 🔍 Smart Search — Predictive re-ranking. Same query string, different goal per persona. The right column flips entirely when you switch between Maija (cat owner), Olli (multi-pet small dog), and Saara (large-breed dog).
• ✨ For You — Personalised tile grid. Catalog re-ranks in under 300 ms per persona pill click. Same _recommend shape minus the name match.
• 🛒 Bought Together — Co-purchase lift via order-level _relate. In the PetNord fixture, dog dry-food → dental treats at ~2.7× baseline, wet food at ~1.7×, accessories at ~1.7×.
• 🛍 Cart Completion — Checkout-funnel personalisation. Top add-on suggestion per cart with confidence + expected uplift in €.

Analyze

• 📈 Purchase Analytics — Monthly orders + revenue (24 months), top-10 SKUs by line count, per-segment KPIs, per-segment category mix.
• 🔗 Pattern Explorer — Full lift band on display: positive (green, lift ≥ 1.5), neutral (grey), protective (red, lift < 0.7). The "what's NOT bought together" side of the equation, plus richer fields per row.

Understand (retention intelligence)

• 💬 Feedback — Multi-field _predict over review text: category, sentiment, suggested assigned-to agent, AND forward-looking churn risk — all from the text alone, in one round-trip.
• 📉 Churn — Panel-data churn prediction. 100 active customers scored by P(churn in 3 mo). Drivers via _relate × 5. Held-out accuracy via _evaluate. The killer Understand view.

Operate (the merchandiser's workbench)

• 📦 Demand Forecast — Per-SKU next-month units forecast via 25 parallel _predict over a monthly_sales panel. Seasonality drivers via four parallel _relate calls. Honest accuracy via _evaluate on a held-out 300-row sample.
• 🏷️ Inventory — Reorder queue ranked by revenue at risk in €, per-row ? opens the demand forecast's $why. Plus an overstock list with tied-capital figures. The merchandiser's daily dashboard.
• 💶 Price Intelligence — Per-SKU fair-band stats from price history (mean ± 1.5σ, outliers flagged). Three parallel _relate over discount bands surface sweet-spot patterns: "promo-priced toys lift 2.4× vs list price."
• ✂️ Markdown — For each overstock SKU, _estimate units_sold runs at five markdown levels (0/5/10/15/20%). The view picks the markdown that clears the excess in 3 months at highest recoverable margin. Honest "won't clear in horizon" flag when no markdown ≤ 20% works.

Re-engage

• ↩️ Win-back — For each currently-churned customer (top-20 by lifetime €), _recommend product_sku from winback_campaigns goal {responded: true} ranks products by predicted email response rate; _estimate order_value_eur gives the AOV forecast per suggestion. In the PetNord fixture, the view reports €1,354 predicted recoverable revenue across 20 targets at €30 send cost — a 45× expected-ROI illustration of the workflow.

Automate

• ⚡ Product Filling — Five product attributes (pet_type, category, weight_kg, dietary, tax_class) predicted in parallel from a single product's name + brand. All five at ≥ 0.87 confidence in ~480 ms. Catalog enrichment as a query.
• 🧪 Evaluation — Four _evaluate calls in parallel, three pass, one honest failure. The "Return Risk" model deliberately fails its 10 pp threshold — the ~3% returned rate has no signal Aito can beat the baseline on, and the view renders that as a red row. Failing loudly is the trust-building moment.

Every view ships with a hero screenshot, working code, and a use-case guide. Same operators across all 16 features.

The Nine Quotable Moments

The demo's narrative anchors — each is a stable, reproducible number computed against the synthetic PetNord fixture, not a customer outcome. The point is to show what the operators produce given clean reference data:

How Much Can You Automate? (The Honest Answer)

Two things are true at once.

The verifiable facts. Aito has shipped predictive infrastructure in production since 2018; on the operational side, Nordic enterprise AP deployments have run at 95%+ accuracy on thousands of invoices per month — same _predict, same $why decomposition. On the commerce side, the structural regularity of consumer purchase data (catalog taxonomies, segment behaviour, seasonality, replenishment cycles) makes _recommend and _relate produce statistically meaningful results on a few hundred impressions per segment, and _predict produce calibrated forecasts on a panel of SKU-month rows.

The conditional answer. All commerce transactions are super-regular at their core. Catalog taxonomies are stable across years, suppliers map to categories, customer segments behave predictably, and seasonality repeats on calendar cycles. What differs between commerce tenants is how much of your incoming volume matches prior patterns with sufficient history vs. arrives as a first-time pattern. Predictive e-commerce is a conditional-probability engine that works the same way on each transaction; how many of your transactions benefit from it depends on the volume mix.

Why commerce data is statistically usable to begin with

Consumer purchase data has more structure than typical ML training data. Catalog taxonomies are durable: product categories, brands, attributes, and tax classes are stable across years. Repeat customers behave consistently: someone who bought cat litter and lactose-free cat treats this month will likely behave the same way next month. Seasonality repeats: Q4 gifting, summer outdoor goods, back-to-school. Segment effects compound: similar customers do similar things, so a few hundred orders per segment carries real predictive signal.

This is why on regular commerce data, three observations of a stable multi-field pattern produces meaningful conditional probability. The top confidence bucket carries near-zero realized error in production — Aito's confidence is calibrated, so when it says >95%, the realized rate matches.

Three pattern-repetition profiles, three different ranges

Underneath all three, the engine is the same: same _recommend / _predict / _relate / _estimate shapes, same calibrated confidence. What changes between deployments is the volume mix.

The conditional-probability machinery is the same across all three profiles. What differs is how much of your incoming volume matches prior patterns with ≥3 prior examples vs. arrives as a snowflake.

Find your profile in 15 minutes: run _evaluate on a held-out slice of your real data. Per-target accuracy and per-confidence-bucket calibration tell you which range your tenants sit in.

What production actually looks like

A predictive e-commerce stack splits naturally into three layers, and the volume mix above determines how much each layer carries:

• Consumer-facing (Smart Search, For You, Bought Together, Cart Completion). Works on segment-level signal, so meaningful results emerge on tens of thousands of impressions per segment. Mostly-recurring and mixed tenants get strong persona-conditioned re-ranking; mostly-snowflake tenants get category-band recommendations rather than SKU-level.
• Merchandiser-facing (Demand Forecast, Inventory, Price, Markdown). Needs at least 6-12 months of SKU-month history. Mostly-recurring tenants get high-confidence forecasts on the top 80% of SKUs by revenue; the long-tail SKUs surface as low-confidence and route to manual judgement with $why rendered.
• Retention-facing (Churn, Win-back, Feedback). Needs a customer-month panel for churn (12+ months ideal). Works across all three profiles because the panel always has structure — what varies is which drivers carry the signal (recency / category mix / review sentiment).

A predictive e-commerce product covering tenants with a heavier snowflake share will see lower headline accuracy at the SKU level — that's the data, not the model. Both numbers are correct, and both are useful, as long as your UI is field-level confidence-aware.

The Override → Learn Loop

Merchandiser bumps the recommended reorder qty from 12 to 18 at 14:00:23. The next request for a similar SKU — different SKU, same category, similar velocity — reflects the new pattern in its conditional probability. No retrain queue. No model deploy. No A/B holdout.

Same loop covers a merchant tagging a recommended cross-sell as "no thanks", a buyer overriding the markdown level for an SKU, a CRM lead overriding the recommended win-back product, an analyst correcting a category prediction during catalog enrichment. Every override trains the next prediction.

This is why predictive e-commerce scales differently than rule-based personalisation engines. Rules rot; predictions improve with every override.

The End-to-End Workflow Loop

The signature interaction in predictive e-commerce is one loop that crosses the consumer-facing / merchandiser-facing boundary without ever crossing a model boundary:

1. 🔍 Customer browses — Smart Search re-ranks results for their segment via _recommend.
2. ✨ For You surfaces what the segment buys; persona switch re-ranks the grid in <300 ms.
3. 🛒 Cart fills — Cart Completion suggests the cross-sell via _relate with predicted uplift in €.
4. 📦 Order ships — Demand Forecast and Inventory update; reorder queue surfaces with revenue at risk in €.
5. 📉 If the customer goes silent, Churn ranks them by P(churn in 3 mo) with $why drivers.
6. ↩️ Win-back picks the product to re-engage them with at predicted email response rate.

Every override trains the next prediction. Same operators across the whole loop. Same Aito DB. No model boundary between the consumer-facing and merchandiser-facing surfaces.

Try Live E-commerce Predictions

Run the same predictions used by ecommerce.aito.ai directly from this page. These queries hit our hosted PetNord database — no signup, no setup.

{
  "from": "orders",
  "where": {
    "line_categories": {
      "$match": "dog_dryfood"
    }
  },
  "relate": "line_categories",
  "limit": 8
}

Multi-Tenant SaaS Pattern

If you're building a predictive e-commerce product for multiple merchants, the same Aito table serves every tenant. merchant_id (or shop_id / customer_id) in the where clause scopes the conditional probability to that merchant's history. accounting.aito.ai runs 255 tenants this way on one shared Aito DB, sub-100 ms predictions, no per-tenant model or retraining schedule.

{
  "from": "order_lines",
  "where": { "merchant_id": "SHOP-0123", "customer_pet_size": "large" },
  "recommend": "product_sku",
  "goal": { "customer_segment": "dog_owner" },
  "limit": 12
}

Same query shape, different merchant_id returns a different ranking — because the conditional probability is computed only over that merchant's rows. No per-tenant index, no per-tenant model, no per-tenant retraining schedule.

Three Signature Interaction Patterns

Three small, reusable components carry the predictive-application UX. Anyone porting this pattern keeps them.

PredictionExplanation — the $why renderer

Pure component that turns Aito's $why factor tree into:

1. Prediction value + confidence bar
2. Base rate (baseP)
3. Top 3-5 pattern matches with token-level highlighting — the words in the product name, the categories on the cart, or the phrases in the review that contributed
4. The multiplicative chain baseP × lift₁ × lift₂ × … = finalP
5. Top 2-3 alternatives, clickable to override

LiftHint / ConfidenceBar — the calibrated annotation

A small badge anchored to a recommended SKU, a cross-sell, or a forecast value. Renders the lift or confidence as a coloured pill: green for strong (lift ≥ 1.5, confidence ≥ 85%), grey for neutral, faint red for the protective band (lift < 0.7). Merchant tooling — and savvy consumers, via a "why am I seeing this?" tooltip — gets a calibrated signal instead of a black box.

SmartField — three-state input

Single DOM input that's the same field whether the value came from a prediction or the user. Three visual states: empty / predicted (gold-italic with a 🤖 badge) / user (normal). Tab promotes, Esc rejects, typing replaces. Used in Product Filling (catalog enrichment) and any merchandiser form where Aito has a credible guess.

These match the patterns in the Smart Forms and Prediction Explanations guides.

Predictive E-commerce vs. Rule-Based Personalisation

Traditional commerce personalisation means: write a segmentation rule, write a recommendation rule, write a cross-sell rule, write a markdown rule. Maintain them. Watch them rot. Hire vendors to fill the gaps.

A predictive e-commerce stack flips it: load your orders and impressions, query for predictions, promote patterns to merchant-visible rules with governance. No retraining, no MLOps, no feature engineering. The data is the model.

Prove It on Your Data in 15 Minutes

The fastest way to disqualify Aito for your e-commerce use case is to run _evaluate on a slice of your real data.

1. Export 10K orders + impressions (or product views) from your store as CSV — customer, product, segment, category, timestamp, anything else you'd predict on.
2. Upload to a free Aito sandbox.
3. Run _evaluate on a held-out slice for top-k recommendation accuracy, demand forecast accuracy, churn AUC, or whatever target matters for your roadmap.
4. Compare to always-recommend-bestseller, always-predict-popular, and whatever you have today.

If the lift over baseline is convincing, schedule a technical review. If not, you've spent an afternoon.

_evaluate is the same operator that powers the Evaluation view on ecommerce.aito.ai. Same code path you'd use in production to monitor accuracy per merchant.

Build vs. Buy: The Honest Math

For a 5-15 person product team building a predictive e-commerce SaaS:

Build it yourself. A working prediction loop with multi-tenancy, retraining, evaluation, and override capture takes ~6 months and ~1.5 FTEs (one ML engineer, ~0.5 backend for plumbing). At €100-130K loaded ML salary plus infrastructure: year-1 TCO €200-400K, year-2 €120-200K maintenance. Plus you're operating retraining infrastructure in production while shipping new features.

Drop in Aito. API key and SQL-like queries, 1-2 weeks to a working prediction loop. Multi-tenancy is merchant_id (or shop_id) in the where clause. Aito plans start at €0 (sandbox), €75/mo (small production), €350/mo (growth) — see pricing. You give up some control over model internals; you gain ~5 months of engineering and the right to delete user data without a model-retraining ticket.

The breakeven question. Time to first paying merchant matters more than build-vs-buy purity. Six months later means six months less revenue and a smaller dataset to learn from when you do ship.

How This Compares: Algolia, Klevu, Shopify Magic, Klaviyo, GPT-4 + a Vector DB

The honest alternatives we hear:

vs. Algolia AI Recommendations / Klevu / NoSto / Searchspring / Boost (commerce search & rec vendors). These bolt on as services with their own data ingestion, taxonomy, and UI patterns. They work, but: (a) they own your prediction layer and the taxonomy decisions inside it; (b) they cover search and recs but stop at the storefront, leaving demand forecast, markdown, churn, and win-back for separate vendors; (c) the same pixel reports to several SaaS products rather than one substrate. Aito is the database underneath your own features, so the predictions are yours, the taxonomy is yours, and a single substrate covers consumer-facing AND operational.

vs. Shopify Magic / Magento Live Search / BigCommerce native AI. Great if you're a merchant on that platform. Useless if you're a platform vendor building a competing or complementary product. Aito is the substrate for the team building the platform feature.

vs. Klaviyo / Recharge / Bloomreach (retention and personalization vendors). These ship CRM + email + retention workflows. They own segmentation and campaign delivery. Aito does the predictive scoring underneath: which customer to win back, which product to offer, how to price the offer. Most predictive e-commerce roadmaps end up running one of these and Aito — the CRM for the workflow, Aito for the score.

vs. GPT-4 + a vector database for product reasoning. LLMs reason well over unstructured input but cost ~1-3 sec per call, are opaque (no $why), and don't learn from corrections. For volumetric commerce work — thousands of impressions/day per merchant — the unit economics break. Use LLMs for free-form customer-message classification or product-description generation, Aito for the structured prediction.

vs. building it on scikit-learn / Vertex AI / SageMaker. You can. You'll spend the 6 months above. The thing you build is a worse predictive database with retraining infrastructure you operate.

Where Predictive E-commerce Fits

For commerce SaaS platform vendors. Shopify-class, headless commerce, niche vertical platforms, marketplace platforms. Bake predictions into your product. Smart Search, For You, demand forecast, markdown, churn, and win-back become default features instead of premium add-ons or third-party integrations. Multi-tenancy is merchant_id in where — same pattern accounting.aito.ai runs across 255 tenants on a single Aito DB.

For e-commerce agencies and integrators. Shopify Plus shops, headless commerce agencies, BigCommerce / Magento / WooCommerce dev shops, freelancers running multi-client retainers. Aito is forkable (Apache 2.0), the PetNord demo doubles as a client pitch deck, and one Aito plan can drive predictions across a portfolio of small clients. See the Partner page for the agency programme.

For ERP vendors with a commerce module. Oscar Software, ERPly, Visma, Lemonsoft, NetSuite — if your product spans accounting + commerce + inventory, the same Aito instance running AP coding and PO routing also runs demand forecast, markdown, churn, and win-back for the commerce side. One substrate, three product surfaces.

Throughput & Sizing Per Plan

Latency is per-prediction in the 20-50 ms range, sub-200 ms P95 at scale. Throughput is what you provision for:

Worked example. A predictive commerce SaaS with 200 merchants averaging 500 product impressions + 50 cart events per merchant per day = ~110K events/day. Each impression triggers ~2 predictions (re-rank + cross-sell), each cart event triggers ~1 (completion suggestion) = ~270K predictions/day. Comfortable on Prod (€350/mo, unlimited). Storage at ~10K rows per merchant fits 1 GB; extends as you grow.

For multi-tenant SaaS beyond ~500 merchants or multi-region deployments, contact us — Enterprise pricing is per-instance with dedicated infrastructure.

Security, Compliance & Data Residency

• EU data residency by default. Hosted in AWS Frankfurt (eu-central-1). US deployment on request.
• Encryption. TLS 1.2+ in transit; AES-256 at rest.
• Tenant isolation. Per-customer Aito instances by default; shared multi-tenant pattern is opt-in.
• DPA. GDPR-aligned Data Processing Agreement on request.
• Audit logging. Every API call logged with timestamp, key ID, query, and response time.
• Right to be forgotten. No model artifact derived from user data — DELETE the rows and predictions reflect it from the next query forward. Important for GDPR Article 17 in consumer-facing e-commerce.
• PII handling. PetNord uses anonymous customer_id (CUST-NNNNN). The recommended pattern: keep PII in your own DB, send Aito the segment / behaviour / event signals scoped per customer_id.

We do not currently hold a SOC 2 Type II attestation; we share our security posture and pen-test results under NDA. For procurement that requires SOC 2 today, contact us.

Platform Stability & Long-Term Commitment

E-commerce platforms ship for 10+ years. Before you bet a product roadmap on Aito:

• API stability. The core query API (_predict, _relate, _search, _recommend, _estimate, _evaluate, _match) has been stable since the v1 release in 2018. We version at the API level — breaking changes ship as new endpoints, never as silent behavior changes on existing ones.
• Deprecation policy. Minimum 12 months notice before any deprecation. Migration guides published with each.
• Operating history. Aito has run in production since 2018 across multiple corporate owners — Nordic enterprise AP deployments processing thousands of invoices per month at 95%+ accuracy. See About for the current corporate posture.
• Source of truth, not lock-in. Your data goes in via standard JSON. It comes out via _search. There is no proprietary format you can't export. Worst case migration: read your rows, write them somewhere else.
• Open-source reference implementations. The accounting, ERP, and e-commerce reference apps are Apache 2.0. If our company posture changes, the patterns we taught remain yours to operate.

For company posture, funding, and team — see About or contact us for current details under NDA. Multi-year procurement reviews welcome.

Get Started

Ready to ship a predictive commerce product — or add predictive features to one you already operate?

Try ecommerce.aito.ai → — see what 16 predictive e-commerce views look like, live.

Read the source on GitHub → — Apache 2.0, 16 use-case guides, 20 architecture decision records.

Download the demo product sheet (PDF) → — 11-page reference for platform builders and integrators showing what your e-commerce product could look like with predictions native to every screen.

Schedule a Technical Review → — walk through your specific commerce automation use cases with our team.

Start Free Trial — point Aito at your own order and impression data in our sandbox environment.

Why we built all of these on one substrate

Predictive Accounting, Predictive ERP, and Predictive E-commerce are not three separate products. They are three instances of the same pattern: a SaaS application designed around the premise that the user should never make a decision the data has already made for them. The substrate is a predictive database. Prediction becomes a query rather than a project.

For the full architectural argument, see The Predictive Application. The canonical explanation of why per-prediction cost determines what gets built, and what changes when that cost collapses.