CH16-02: Use Cases, Data, and Model Requirements
Goal
The previous section separated commerce AI into workload shapes. This section turns those ideas into requirements. Before choosing Azure AI Foundry, Azure OpenAI, Azure AI Search, Azure Machine Learning, or an analytics platform, the team needs to know what decision the AI system influences and what happens when it is wrong.
The durable idea is:
AI requirements must name the data source, the decision being influenced, and the risk of being wrong.
The Short Version
The easy question is:
Which model should we use?
The better architecture question is:
What data is allowed to influence which decision, how fast must the answer be, and how do we measure harm or value?
AI requirements should describe data, decision, latency, risk, explainability, privacy, and metrics together.
Use-Case Matrix
| Use Case | Data Sources | Serving Path | Main Metrics | Main Risk |
|---|---|---|---|---|
| Product recommendations | Catalog, interactions, orders, inventory, customer context where allowed. | Product page, home page, email, app feed. | Clicks, conversion, add-to-cart, revenue, availability impact. | Irrelevant, unfair, unavailable, or privacy-invasive recommendations. |
| Search relevance | Catalog, query logs, clicks, purchases, synonyms, product metadata. | Search API and ranking pipeline. | Search success, zero-result rate, conversion, latency. | Poor discovery, biased ranking, stale catalog results. |
| Fraud detection | Orders, payment attempts, device signals, account history, risk signals. | Checkout or post-order risk workflow. | Fraud caught, false positives, manual review rate, latency. | Blocking legitimate customers or allowing abuse. |
| Demand forecasting | Orders, inventory, promotions, seasonality, events, returns. | Planning and replenishment workflows. | Forecast error, stockout rate, excess inventory, planning stability. | Overbuying, stockouts, poor seller or warehouse decisions. |
| Support assistant | Policy docs, order data, customer history, support cases. | Support-agent workspace or customer support flow. | Resolution time, answer quality, escalation rate, safety incidents. | Exposing wrong data, giving incorrect policy guidance, unsafe automation. |
| Seller assistant | Seller catalog, policy docs, listing quality, seller orders. | Seller portal assistant and content tools. | Listing quality, time saved, moderation pass rate, seller satisfaction. | Cross-seller data exposure, poor content, policy violations. |
| Content moderation | Product images, descriptions, reviews, seller content, policy rules. | Listing and review workflow. | Precision, recall, review workload, appeal rate. | Allowing harmful content or blocking legitimate sellers. |
This matrix helps architects avoid vague requirements like "add AI to search" or "use a chatbot." Each row creates a different architecture.
Data Requirements
Commerce AI depends on several data families:
Product catalog data: titles, descriptions, images, categories, attributes, price, availability, and seller-provided content.
Interaction events: impressions, clicks, searches, add-to-cart events, purchases, returns, ratings, and feedback.
Order history: order state, payment status, refunds, shipping, delivery, and customer-visible events.
Inventory signals: stock levels, warehouse availability, replenishment timing, and substitutions.
Support data: tickets, chat transcripts, policy articles, resolutions, and escalation outcomes.
Seller data: seller identity, catalog quality, performance, policy status, and marketplace activity.
Fraud signals: risk flags, device or session signals, chargebacks, velocity patterns, and review outcomes.
Data quality matters. A recommendation model trained on stale catalog data can promote unavailable items. A support assistant grounded in old policy can create bad customer outcomes. A fraud model trained on biased or poorly reviewed labels can hurt legitimate customers.
Latency and Correctness
Latency requirements vary by use case:
| Workload | Latency Pressure | Correctness Pressure |
|---|---|---|
| Recommendations | Low latency during page or app rendering. | Must avoid harmful, unavailable, or obviously irrelevant results. |
| Search ranking | Low latency for search experience. | Must return relevant, current, permission-appropriate results. |
| Fraud scoring | Very sensitive during checkout or payment flow. | High, because false positives and false negatives are both costly. |
| Demand forecasting | Often batch or scheduled. | Important, but measured over planning windows rather than milliseconds. |
| Support assistant | Interactive but can tolerate more latency than checkout. | High, especially for policy, refunds, privacy, or account guidance. |
This is why a fraud workload should not be designed like a recommendation carousel. A wrong recommendation may reduce conversion. A wrong fraud decision can block a legitimate order, allow abuse, trigger manual review cost, or create compliance exposure.
Privacy, Consent, and Data Minimization
Personalization depends on customer and behavioral data, so privacy and consent are design inputs. The architecture should define:
Which data can be used for personalization.
Which data is excluded or minimized.
How customer consent or preference choices affect training and serving.
How long events and features are retained.
Which teams can access raw, feature, and model-output data.
How sensitive data is masked, aggregated, or protected.
Data minimization matters because collecting more data than needed increases risk without always improving the result.
Metrics and Feedback Loops
Each workload needs metrics before production rollout:
| Workload | Useful Metrics |
|---|---|
| Recommendations | Click-through, conversion, add-to-cart, revenue impact, diversity, inventory availability, latency, cost. |
| Search relevance | Query success, zero results, reformulation rate, conversion, ranking quality, latency. |
| Fraud detection | Fraud prevented, false positives, false negatives, manual review rate, customer friction, audit findings. |
| Forecasting | Forecast error, stockouts, overstock, planning stability, downstream operational impact. |
| Support assistant | Answer helpfulness, citation quality, escalation rate, handle time, safety incidents, agent feedback. |
| Moderation | Precision, recall, review queue size, appeal outcomes, policy violations, seller impact. |
AI workloads should be measured by behavior and business outcomes, not only model accuracy. A model can score well offline and still harm the product if it increases latency, promotes unavailable inventory, or frustrates support agents.
Common Mistakes
Reusing personal data without clear consent, purpose, or retention rules.
Building model pipelines without defining business and safety metrics.
Ignoring stale catalog, policy, support, or inventory data.
Treating all AI use cases as if they have the same latency and risk profile.
Optimizing offline model quality while ignoring online behavior and user impact.
If Someone Asks You
What requirements should you collect before designing an e-commerce AI workload?
A good answer is:
I collect the data sources, the decision being influenced, the serving path, latency expectations, privacy and consent rules, explainability needs, safety concerns, and metrics. Recommendations, fraud detection, forecasting, search relevance, and assistants all need different requirements. I also ask who owns the data, how feedback is captured, how wrong outcomes are reviewed, and how the workload can be rolled back.
What You Should Remember
The design follows the data, the decision, the metric, and the risk.
Questions to Check Understanding
Which AI use cases need real-time data?
Why does fraud detection need different controls from recommendations?
What metrics prove an AI workload is helping rather than only running?