How to Build an AI Product Recommendation Engine for eCommerce

The difficult part of product recommendations is deciding which items deserve to appear together. Similarity and compatibility work hand in hand to help customers compare, pick and purchase. Retailers are looking to develop AI product recommendation engine logic that accounts for these relationships and recommends the right product at the right time.

There is a growing investment in retail technology to achieve this goal. According to Adobe’s 2026 AI and Digital Trends report, 63% of retail and consumer goods brands use agentic or generative AI to design customer journeys and activate them across different channels. Customers also prefer conversational product discovery. 25% of respondents say they rely on AI-powered platforms for information and purchasing recommendations.

Commercial measurement deserves the same attention as model selection. Salesforce’s 2026 commerce research found that only 32% of organizations had fully defined AI success metrics and KPIs. Before choosing an architecture, the team should decide what a better recommendation must achieve. For example, more accessory purchases, higher contribution margin per order, or more completed purchases after product comparison. 

The Persentra AI case shows how retail teams can put recommendation technology into daily use. The Australia-based company provides privacy-first personalization using anonymous shopper interaction signals. Its existing AI technology needed a retailer-facing dashboard that merchandisers could operate without engineering support for routine changes.

The Computools team developed the React and TypeScript frontend for the Systema Control Centre and connected it to the client’s existing personalization backend.

Merchandisers could adjust recommendation carousels, smart search settings, and targeted product feeds, then review performance in one interface. Reported project outcomes included 25% higher average order value, an 18% increase in conversion rate, and 50% faster rule updates. The case highlights that retail teams need controls to act on recommendation performance as campaigns and catalogs change.  An AI recommendation system for eCommerce connects interaction data, product relationships, retrieval models, and ranking decisions. 

This article explains how to develop that decision-making layer, evaluate its contribution to sales, and integrate it with the retailer’s existing commerce systems.

Develop AI product recommendation engine logic around the purchase decision

The first task is defining the recommendation objective for each placement.

“Customers also bought” and “Similar products” may occupy identical-looking carousels, but their logic differs. One identifies complementary items; the other helps shoppers compare substitutes. Mixing these objectives produces confusing selections.

For product recommendation system development, document what the customer is doing, which product relationships matter, and how the retailer will measure success.

This approach also aligns with AI transformation services, where AI capabilities are designed around business workflows and measurable outcomes rather than isolated technical features. 

Select one initial objective with enough traffic and reliable product data. For example, a retailer of specialist equipment might start with related accessories because the relationships between products are usually clear and the objective can easily be measured.

Define acceptable behavior with respect to the objective. Should the engine suggest lower-cost alternatives? How should it behave toward items already in the shopping basket? Which products require compatibility checking?

Answers to these questions establish the selection rules, training labels and evaluation criteria.

Step 1. Establish product identity and observable shopping signals

An engine requires a representation of both products and shopping activities.

Product variants (e.g. color and size) should be represented as individual entities. Consider an example of a shoe. In this case, a customer selects a size of a model, and then buys a shoe of a particular color. An engine is required to represent all the variants and relationships between them and not collapse them to a single product.

Next, create mappings between the canonical identifiers of your storefront, product information system, order management system and inventory feeds. Capture the relationships in your database when they are relevant.

Finally, you need to identify events of user interaction. Some of these events may include product views and searches, selecting filter options, adding to basket, purchasing and being shown product recommendations.

The order of events in user interaction affects the level of customer behavior personalization. A customer who has viewed a premium listing and then applied a lower-price filter provided a constraint. To build a recommendation system that can capture this kind of constraint, timestamps and session context should be stored.

Each recommendation impression should record:

• the request and placement identifiers;
• the products displayed and their positions;
• the model and configuration versions;
• the relevant session context;
• whether a fallback selection was used.

Purchase events should come from a dependable transaction source. Duplicate browser events and repeated order notifications need deduplication before they enter training or reporting.

Persentra AI uses interactions shoppers have with products for product discovery. For a similar engine, attach each event to a session ID, product/variant ID, timestamp, and placement. The system can then tell the difference between a shopper viewing camera bodies as opposed to the shopper building a camera accessory bundle. 

Treat search queries and recommendation clicks as identifiable events. Search queries can represent purchase intent and clicks on recommendations can show post-purchase behavior. 

For retaining identifiers, attributes, and changes across retail systems, refer to Computools’ guide on real-time product catalog synchronization.

Step 2. Turn interaction history into training examples

Shopping records have to be decoded to be used as model inputs.

Purchasing is a stronger signal than a quick product view, but meaning depends on the goal. For accessory recommendations, selling a bundle containing the accessories would be a strong signal. For alternatives, comparison behavior and subsequent product selection may carry more information.

Define labels separately for each task. Avoid assigning arbitrary event weights and treating the resulting score as a universal measure of preference.

Exposure is also important. A product a shopper never saw gives you very little evidence of their interest. A product that was displayed may have received very few clicks due to its position, for example.

When creating negative examples, tell the difference between displayed products that were never engaged with and products sampled from the catalog. 

Use only the information available at the time of the decision to create features. The historical training record should contain the price and availability as well as the shopper’s activity at that time. Purchases that happened later should be part of the outcome label, not the input features.

Evaluate on a later time period than the training data. TensorFlow’s retrieval tutorial identifies this time-based approach as the likely choice for an industrial recommendation system.

For fashion retailers, product attributes may originate in design and lifecycle systems. The guide to integrating PLM with eCommerce offers additional reading on bringing those attributes into the commercial catalog.

Step 3. Retrieve candidates from several product relationships

An engine serving a large assortment needs an efficient way to select a manageable candidate pool.

Google’s recommendation guidance separates candidate generation from scoring and re-ranking. This allows the system to search broadly first, then apply more detailed evaluation to a smaller selection.

A recommendation algorithm for eCommerce should reflect the product relationship required by the placement. Several retrieval methods may contribute candidates:

For machine learning product recommendations, a two-tower retrieval model is one option. One network represents the shopper or session; another represents products. Their embeddings allow the system to retrieve products with a strong match to the shopping context.

Product embeddings can be precomputed and stored in an approximate nearest-neighbor index. The session representation is generated from current features when a request arrives. TensorFlow’s official tutorial demonstrates this separation and index-based serving.

Combine candidate sources, remove duplicates, and preserve the origin of each item for evaluation. This reveals whether product similarity, purchase relationships, or session signals are contributing useful selections.

A co-purchase pattern still needs interpretation. Two products may appear together because of a promotion; compatibility should come from validated product relationships.

Step 4. Rank for purchase relevance and commercial contribution

Retrieval supplies plausible products. Ranking decides which deserve the limited positions available.

An AI-powered product recommendation engine should evaluate candidates using information that the retrieval stage could afford to simplify: price fit, compatibility, recent shopper actions, prior exposure, delivery eligibility, and purchase likelihood.

A structured ranking model may use features such as:

• similarity to the current product or session;
• relationship to items already in the basket;
• price difference from recently considered products;
• category-level popularity and seasonality;
• available variants and fulfillment conditions;
• previous impressions and interactions.

Take care when choosing training objectives. Click probability is useful to anticipate user engagement, but the commercial team needs to account for purchases, contribution margin and returns.

As for personalized eCommerce recommendations, one of the suggested solutions is to rank for purchase relevance and assess margin as a separate commercial measure. Another is to incorporate estimated contributions into the ranking objective. The second approach requires reliable cost data and testing to assess how it affects shopper relevance.

Apply hard eligibility rules before expensive scoring where practical, then revalidate changeable conditions before delivery. A highly ranked accessory must be compatible with the selected device. 

Re-ranking can be used to improve the final assortment. For example, we may re-rank to ensure a diverse set of alternatives, or a useful spread of price points. Google’s re-ranking strategy focuses on adding constraints, as well as improving diversity and freshness of the final result. 

Step 5. Design for new shoppers, new products, and sparse categories

A personalized product recommendation engine needs useful behavior before extensive history exists.

For a new visitor, use the current category, search terms, selected filters, and first product interactions. As the session develops, recent actions provide a stronger basis for selection.

For a new product, descriptive attributes can support initial retrieval. A model relying only on learned product identifiers needs a defined strategy for products introduced after training.

Reserve controlled opportunities for new items to receive exposure. Set limits around eligibility and relevance, and measure whether this exploration produces useful interactions.

Lean categories require special treatment. For example, a specialist-parts retailer may have thousands of products with infrequent purchases. In this case, purchase patterns may not be very useful. However, technical specifications, related products, or compatibility may be more relevant.

New visitors, repeat visitors, new products, and low-volume categories may all require special treatment. An overall good result may conceal poor coverage in the parts of the assortment that are most relevant to a particular business unit.

The default should also follow the placement. A comparison carousel in a popular product may make sense to include popular alternatives in that category. A “basket” accessory may need to include complements, even if the model hasn’t learned a lot.

Launch an AI product recommendation engine within 1–3 months, match shoppers with more relevant products in real time, increase conversion and average order value, and grow revenue without adding manual merchandising work.

Contact Us →

Step 6. Serve decisions with fresh context and traceable outputs

We developed an interface using React and TypeScript to connect Persentra AI’s existing backend to the recommendation and discovery controls for retailers. For a similar dashboard, define a complete update flow. For example, a merchant edits a carousel setting, the frontend validates the user input, the API accepts or rejects the change, and the interface displays the confirmation. In case the setting is not saved, the interface needs to maintain the previous value and show which setting is not saved. Defining the integration contract this way, makes it very clear for both the frontend and backend teams what is expected of them.

For real-time product recommendations, you need to split learning of the recommendation model from the update that occurs during a shopping session.

Recent browsing, basket contents, and selected filters can update online features between training runs. Stock and prices follow their own synchronization requirements. Retraining learns broader relationships from accumulated data.

AWS documents that recent interaction events influence recommendations before retraining for supported approaches, but new-item and bulk-data behavior varies by use case. The implementation should specify these update paths individually.

The request should include placement, market, session, current product, and relevant basket details. The response should include the requested product with ID, along with request ID, model version, config version and fallback status.

Keep the IDs returned by the APIs separate from presentation details. For current product details (price, image, etc), use the commerce layer APIs.

A session cache is appropriate to maintain candidate lists of expensive calculations (i.e., Product to Product candidate lists).

Explain the reasons for fallback selections. Unavailable features, insufficient candidates and model errors should be logged.

Recommendations are also dependent on seller availability and listing/fulfillment quality. The guide to marketplace management applications provides further context on those operating dependencies.

Step 7. Evaluate retrieval, ranking, and business impact separately

To build an AI recommendation engine for eCommerce use cases successfully, measure where the selection process succeeds and where it loses relevant products.

Retrieval evaluation asks whether suitable products entered the candidate pool. Ranking evaluation asks whether they received useful positions. Eligibility evaluation asks whether the returned selection met retail constraints.

Use offline evaluation to narrow the models worth testing. Then run a controlled experiment with consistent visitor assignment and a predefined primary measure.

Persentra AI’s dashboard displayed recommendation activity, conversion signals, AOV impact, and revenue contribution. Analytics review time reportedly fell by 35%. 

Build comparable views around individual placements. For a cart accessory carousel, show impressions, clicks, attributed purchases, and accessory attachment rate, with filters for date and device. Display the active configuration alongside those results so merchants can investigate what changed.

These placement-level metrics are recommendations for the new engine, extending the case’s documented performance views. 

Step 8. Manage model releases and recommendation feedback

To develop an AI product recommendation engine, consider a retrieval model and its feature definitions as a unit. Also consider a deployed model and its retrieval index as a unit. Release these models and components together.

An updated query model may create embeddings that are not compatible with a previously released product index. Version these models and components together and test the end to end deployment path before you increase the traffic.

The model registry should store the training date and time along with the dataset version and evaluation results. It should store the feature definitions and approval record. Keep a known good release for rollback.

Measure the impact of placement, category and shopper segment. Look at conversion rate and other related metrics to understand the why.

Track product exposure and promotions. Product recommendations impact the interaction data that is used to train the system; repeatedly endorsing a product can strengthen its perceived popularity. Look at the distribution of promotional exposure and compare it to commercial and relevance metrics. Keep controlled discovery opportunities.

Treat a deployed model, its feature definitions, and its retrieval index as a coordinated release.

Retraining frequency should follow assortment turnover, changing demand, and observed model quality. Catalog refreshes and session updates may need much faster schedules.

Maintain data-removal and retention workflows across historical storage, online features, and future training inputs. Record access to sensitive data and keep identity mappings controlled.

Budget for the cost per useful recommendation

Implementation cost depends on the quality of existing data, the number of placements, catalog complexity, and the amount of custom modeling required.

Running costs include event processing, feature storage, index updates, inference, training, and monitoring. Estimate them using request volumes and the expected complexity of each placement.

A product-page alternative list may use mostly precomputed candidates. A basket recommendation may need to evaluate several products, compatibility relationships, and current availability on each request. Their cost profiles differ.

Use traffic and latency tests to decide where caching, batch computation, or a simpler model produces the best tradeoff.

The article on marketplace data-platform costs offers additional context on the ingestion, governance, and storage work behind the engine.

The investment decision should connect measured incremental contribution with ongoing operating cost and the effort required to maintain the system.

Put recommendation decisions to work with Computools

Computools helps retailers connect recommendation logic with the systems that determine whether a suggestion is useful and purchasable.

Through retail software development services and eCommerce software development, the team connects product relationships, inventory, orders, and storefront workflows. This gives the engine access to the commercial conditions behind each selection.

Data engineering establishes dependable interaction records and model inputs. AI development supports retrieval and ranking evaluation against the retailer’s objectives. Web development services bring recommendations into shopper placements and give business users accessible controls.

The Persentra AI case illustrates the operating side of this work. Persentra AI supplied the personalization technology; Computools developed the React and TypeScript frontend for the Systema Control Centre and connected it to the existing backend. Merchandisers gained controls for recommendations, discovery settings, and performance review.

The case reports a 25% higher average order value, 18% higher conversion, 50% faster rule updates, and 40% fewer engineering requests. These results show the importance of making recommendation capabilities manageable for retail teams.