Smart E-Commerce System with AI Recommendation Engine and Customer Behavior Analytics

មូលសង្ខេប / Abstract

ពាក្យគន្លឹះ

1. Introduction

Modern e-commerce platforms are no longer limited to displaying products and processing customer orders. As online stores continue to offer a wider range of products, customers may find it difficult to quickly identify items that match their interests. At the same time, merchants need a better understanding of customer behavior to support decisions related to product selection, promotions, cross-selling, and customer retention. A recommendation system can help address these challenges by analyzing customer interactions and suggesting products that are more relevant to each user.

The Smart E-Commerce System developed by our Group combines the main functions of an online shopping platform with a machine learning recommendation engine and customer behavior analytics. The project aims to provide personalized product recommendations, improve the overall shopping experience, increase the possibility of purchase, and help merchants better understand customer preferences. To achieve this, the system collects information from customer activities such as product browsing, clicks, wishlist actions, cart activities, and previous purchases. These interactions are then used to support both product recommendations and business analysis.

A key part of this project is that the recommendation engine is integrated directly into the complete e-commerce system instead of being developed as a separate machine learning experiment. The system supports different users, including customers, vendors, and administrators, and the overall design is documented through Data Flow Diagrams (DFDs), UML diagrams, an Entity Relationship Diagram (ERD), database structures, and working user-interface screens. For customers with enough interaction history, the system uses collaborative filtering and product information to generate personalized recommendations. For new users or customers with limited interaction history, popular products are provided as an alternative. This approach allows the recommendation feature to remain useful while supporting the normal operations of the e-commerce platform.

 

Figure 1. Overall DFD of the Smart E-Commerce System, showing customer, merchant, admin, database, and recommendation components.

2. Literature Review and Related Work

Recommendation systems are commonly used in e-commerce platforms to help customers discover products that match their interests. One popular technique is Collaborative Filtering (CF). This method learns from the behavior of different customers. For example, if two customers have viewed, added to cart, or purchased similar products, the system can use this information to recommend other products that one customer may be interested in. Previous research has shown that customer activity and product information can be useful for improving recommendations, especially when customer ratings are limited [1].

An important part of Collaborative Filtering is identifying similarities between users or products. One common method is Cosine Similarity, which measures how similar two users or products are based on their interaction patterns. This method works well with e-commerce data because customers normally interact with only a small number of products from a large catalog. However, Collaborative Filtering also has some limitations. For example, a new customer may not have enough browsing or purchasing history for the system to understand their interests. This is commonly known as the cold-start problem [2]. Previous studies also show that the method used to calculate similarity can affect the quality of recommendations [3].

Researchers have also studied Hybrid Recommendation Systems, which combine more than one recommendation technique. Instead of depending only on customer behavior, a hybrid system can also consider product information such as category, name, description, or other product characteristics. Previous studies have found that combining different recommendation approaches can help the system understand customers with different interests [4]. Other studies have also used customer activities such as clicks and purchases to improve recommendation results in real e-commerce environments [5].

Based on these ideas, our project uses a hybrid recommendation approach. The system mainly learns from customer activities such as product views, clicks, wishlist actions, add-to-cart activities, and purchases. Collaborative Filtering is used to identify patterns from customer-product interactions, while Content-Based Filtering uses product information to find similar products. The system combines these methods to provide more personalized recommendations. For customers who do not yet have enough activity history, popular products are recommended as an alternative.

Compared with previous studies, this project does not focus only on developing a recommendation model. The recommendation engine is integrated into a complete e-commerce platform that includes customer shopping, vendor product and order management, administrator functions, customer behavior analytics, and transaction processing. This allows the project to demonstrate how machine learning can be used as part of a practical e-commerce system rather than as a separate experimental model.

3. Materials and Methods

3.1 System Architecture and Actors

The architecture is organized around three principal human actors: Customer, Merchant/Vendor, and Admin. Customers register or log in, browse and search products, receive recommendations, add products to cart, complete checkout and payment steps, track orders, and submit ratings or reviews. Merchants manage products and inventory, process orders, view sales analytics, and respond to customer reviews. Administrators manage users, merchants, categories, system configuration, and reports.

Figure 2. Machine-learning DFD Level 2. The recommendation request is routed through history checks, collaborative filtering, cosine-similarity computation, caching, and recommendation output.

3.2 Data Model and Behavioral Signals

The database design includes entities for users, products, product images, categories, carts, cart items, inventory, orders, order items, payments, reviews, and supporting system records. These transactional entities provide the foundation for an implicit or explicit user-item interaction matrix. Purchase history, search history, product views/interactions, and ratings/reviews are especially relevant to recommendation.

Figure 3. Entity Relationship Diagram used by the prototype to connect users, products, carts, orders, payments, reviews, and related data.

Table 1. Recommended feature interpretation based on the interaction sources shown in the project design.

3.3 Data Cleaning and Preprocessing

Before model training, interaction data should be checked for missing user or product identifiers, duplicate events, invalid ratings, inconsistent timestamps, and products or users that no longer exist. For implicit feedback, repeated interactions can be aggregated into an interaction strength. A practical weighting scheme can assign progressively larger weights to views, cart additions, purchases, and positive ratings; however, the exact weights must be documented from the final implementation rather than assumed.

The user-item matrix is typically sparse. For evaluation, a chronological split is preferable to a purely random split because it better simulates the real task of predicting future customer behavior from past behavior. Users with too few interactions should be separated into a cold-start analysis group or served by a popularity fallback.

3.4 Hybrid Recommendation Algorithm

The recommendation engine follows a hybrid item-to-item approach, combining customer behavior with product information. As illustrated in Figure X, the process begins by building a user-product interaction matrix from activities such as views, clicks, wishlist actions, add-to-cart actions, and purchases. The system then processes this information through two recommendation methods: Collaborative Filtering and Content-Based Filtering. Their results are combined to produce the final recommendation score.

Figure X. Hybrid item-to-item recommendation process used in the Smart E-Commerce System.

3.5 Training, Testing, and Evaluation Protocol

The code contains an explicit temporal offline-validation procedure. Interactions are ordered per user and the algorithm attempts to hold out the latest previously unseen high-intent product event, where high-intent events are click, wishlist, add-to-cart, or purchase. Users with fewer than two interaction records, or without an eligible unseen high-intent item, are not included in the validation set. The remaining records form the training set, after which the hybrid recommender is rebuilt and Top-10 recommendations are compared with each held-out relevant product.

Table 2. Evaluation metrics recommended for the final recommendation experiment.

3.6 Software Implementation

The Phase 2 material demonstrates a browser-based e-commerce prototype with separate customer, vendor, and admin interfaces. The customer interface includes product discovery, account registration and login, deals, catalog browsing, cart, address entry, payment selection, and order review. The vendor interface includes dashboard information, product management, and export functionality, while the admin interface supports platform-level management and reporting.

Figure 4. Customer landing page of the implemented SmartShop prototype.

Figure 5. Vendor portal dashboard of the implemented prototype.

3.7 Implicit-Feedback Feature Engineering

Behavioral events are converted into weighted implicit feedback. The implemented base weights are 1.0 for view, 1.5 for click, 2.0 for wishlist, 3.0 for add-to-cart, and 5.0 for purchase. Each score is multiplied by the daily event count and an exponential time-decay factor. With the default 45-day half-life, an otherwise identical interaction contributes half of its original recency weight after 45 days. The resulting scores are aggregated by user-product pair into a SciPy CSR sparse matrix, while the same scores are accumulated into the popularity vector.

Behavior event	Base weight	Interpretation
View	1.0	Weak implicit interest
Click	1.5	Stronger product engagement
Wishlist	2.0	Explicit save/interest signal
Add to cart	3.0	High purchase intent
Purchase	5.0	Strongest positive implicit signal

Table 3. Event weights implemented in app/ml/preprocessing/interactions.py.

3.8 Model Configuration and Reproducibility

The recommendation system uses a set of predefined parameters to control how customer behavior is processed and how recommendations are generated. The model uses customer interaction data from the most recent 180 days, while more recent activities are given greater importance through a 45-day time-decay period. A customer needs at least five product interactions before the system can generate personalized recommendations; otherwise, popular products are recommended as a fallback. For each product, the system can identify up to 30 similar products and precompute up to 100 recommendations for faster access. By default, the API returns 10 recommended products to the customer at a time. The generated recommendation results are stored in Redis for up to 48 hours before they need to be refreshed. Using the same configuration throughout the experiment helps ensure that the model can be tested consistently and that the evaluation results can be reproduced.

Parameter	Default value	Role
Training window	180 days	Limits behavior events used for model training
Event half-life	45 days	Controls recency decay
Minimum interactions for CF	5	Warm-user threshold
Neighbors per item	30	Candidate-neighbor depth
Maximum precomputed recommendations	100	Size of stored ranking
API recommendation batch	10	Default returned Top-K
Cache TTL	172,800 s (48 h)	Redis/model serving lifetime

Table 4. Default machine-learning configuration found in app/core/config/settings.py.

3.9 Training, Publication, and Online Serving Architecture

After training is completed, the system saves the new model as a versioned file and stores the generated recommendation results in Redis. Only after all required data has been successfully stored does the system activate the new model version. This process helps prevent customers from receiving incomplete recommendations while a new model is being prepared.

When a customer requests recommendations, the system first checks Redis for personalized recommendations. If they are not available, it checks the popular-product recommendations. If Redis cannot provide the result, the system tries to use the saved model file. As a final backup, it retrieves suitable products directly from the SQL database. A similar process is used when customers request similar products, with products from the same category used as a fallback when necessary.

This approach keeps the more resource-intensive machine learning training process separate from the customer-facing API. It also makes the recommendation service more reliable because the system has several backup options if Redis, the trained model file, or another recommendation component is temporarily unavailable.

 

Figure 8. Code-derived architecture of the implemented hybrid recommendation pipeline.

3.10 Application Technology Stack and ML APIs

The project is developed as a full-stack e-commerce application, with different technologies used for the web interface, backend services, database, and machine learning components. The backend is built using FastAPI with asynchronous SQLAlchemy for database operations, while PostgreSQL 16 is used as the main database for storing application data.

To improve the performance of the recommendation system, Redis 7 is used to store recommendation results and information about the currently active model. RabbitMQ and Celery support background processes, such as scheduled or resource-intensive tasks, so these operations do not interrupt the normal user experience. The customer-facing web application is developed using Next.js 15.

For the machine learning component, the system uses NumPy, SciPy, and scikit-learn. SciPy sparse matrices are used to efficiently represent customer-product interactions, while scikit-learn provides tools such as NearestNeighbors for finding related products.

The system also provides several API endpoints for accessing recommendation features. These allow the application to request personalized recommendations, find similar products, and check the current recommendation model status. The model-status function also provides information about the active model version and its training results, making it easier to monitor the recommendation system.

API / component	Purpose
GET /recommendations	Returns personalized recommendations for the authenticated user
GET /recommendations/similar/{product_id}	Returns item-to-item similar products
GET /recommendations/status	Returns model readiness, version, generation time, metrics, and serving source
Redis recommendation keys	Stores popular, per-user, per-product, and metadata rankings
Versioned ML artifact	Provides serving path when Redis is unavailable
SQL fallback	Provides bounded behavior/popularity/category results when no trained bundle is available

Table 5. Recommendation-serving interfaces and resilience mechanisms implemented in the source code.

3.7 Synthetic Experimental Dataset

Since real customer interaction data was not available for this academic project, a synthetic dataset was created to test and evaluate the recommendation system. The data set represents 500 simulated customers, 150 products across 10 product categories, and 15,158 customer interaction events collected over a simulated period of 180 days. Each customer was given different product and category preferences so that their shopping behavior would be more realistic. As a result, customers were more likely to interact with products that matched their simulated interests rather than selecting products completely at random.

The dataset includes five types of customer activities: view, click, wishlist, add to cart, and purchase. Since these activities show different levels of customer interest, different weights were assigned to each action. A product view was given a weight of 1.0, click 1.5, wishlist 2.0, add to cart 3.0, and purchase 5.0. This means that stronger actions, such as purchasing a product, have more influence on the recommendation model than simply viewing a product. The system also applies a 45-day time-decay setting, which gives more importance to recent customer activities than older ones.

For model evaluation, the latest suitable high-interest interaction from each eligible customer was separated from the training data and used for testing. This resulted in 498 customers being included in the validation process, while the remaining 14,660 interaction events were used to build the customer-product interaction matrix and train the recommendation model.

The synthetic dataset was created specifically for testing and demonstrating the machine learning component of this project. It does not represent actual customer or production data. Although it allows the recommendation system to be tested in a controlled and repeatable way, simulated customer behavior may not fully represent how customers behave in a real e-commerce environment. Therefore, testing the model with anonymized real-world customer data would be an important area for future improvement.

4. Results

4.1 Functional Implementation Results

The supplied project evidence confirms that the system has progressed beyond conceptual diagrams to an implemented web prototype. The customer side shows working interface flows for authentication, product browsing, deals, cart, checkout, payment-method selection, and order review. The vendor side includes a dashboard and product-management interface, while the admin side includes platform summary cards and management functions. These outputs demonstrate that the recommendation component is embedded within an operational commerce workflow.

Figure 6. Product catalog interface showing category/price filtering and product cards.

Figure 7. Administrator dashboard with platform summary indicators and reporting area.

4.2 Machine Learning Evaluation Results

To evaluate the recommendation engine, we used a synthetic e-commerce dataset because real production customer data was not available. The experiment included 500 simulated customers, 150 products, and 15,158 behavioral events. We held out the latest eligible high-intent interaction from each customer for testing, giving 498 validation users. Three approaches were compared: a popularity baseline, collaborative filtering, and the final hybrid model combining 75% collaborative filtering with 25% content-based similarity. The results below are measured from this synthetic experiment and should not be interpreted as production-customer performance.

Table 6. Synthetic dataset and training statistics.

The following table separates model performance from dataset statistics. This makes it easier to see how each recommendation approach performed on the same validation set.

Table 7. Top-10 recommendation performance on the synthetic experimental dataset.

How to read Table 7. Precision@10 shows how many of the ten recommended products were relevant. Recall@10 shows how often the held-out relevant product was recovered in the Top-10 list. MAP@10 rewards correct recommendations that appear nearer the top of the list. Catalog Coverage shows how much of the product catalog appeared across recommendation lists. The Hybrid model achieved the strongest overall result, with Recall@10 of 0.5803 and MAP@10 of 0.3204.

After the final database is seeded with the intended experimental interactions, run the recommendation training task and capture the metrics returned by the training bundle. Populate Table 6 exactly from that output. A simple bar chart can then compare Precision@10, Recall@10, and catalog coverage; matrix density should be discussed separately because it measures sparsity rather than quality. The final defense should also state the number of validation users so that the audience understands how many users contributed to the offline accuracy metrics.

5. Discussion

The project architecture is well aligned with the practical requirements of a recommender-enabled e-commerce platform. Behavioral data is generated naturally through browsing, search, cart, purchase, and review processes, reducing the need for a separate data-collection application. The recommendation DFD also makes the decision logic understandable: identify the user, verify that enough history exists, compute collaborative recommendations, cache them, and return ranked products.

The implemented recommender is stronger than the original slide description because it is hybrid. Collaborative item neighbors capture collective behavior, while TF-IDF content neighbors use product name, category, attributes, and featured status. The 75/25 blend favors behavioral evidence while preserving a content signal. The recency-decayed event weights also distinguish a purchase from a casual view and reduce the influence of older behavior. Nevertheless, sparse matrices and limited interaction history can still reduce neighbor quality, making the five-interaction threshold and cold-start popularity strategy important operational safeguards.

A remaining limitation is not the absence of evaluation logic, but the absence of final captured evaluation output in the submitted source archive. The code already performs a temporal hold-out and calculates Precision@10, Recall@10, and catalog coverage. However, an academic result must report values produced from the final dataset, together with the number of eligible validation users and matrix density. The final report should therefore be updated once the team runs training against the completed dataset and records the returned metrics.

The system can be extended toward a hybrid recommender. Product category, text, price range, and other item attributes can support content-based recommendations for cold-start products, while collaborative signals remain useful for returning users. Additional improvements include time-decay weighting, session-aware recommendations, diversity/novelty metrics, and periodic retraining. For larger datasets, approximate-nearest-neighbor or matrix-factorization methods may improve scalability.

6. Conclusion and Future Work

This study presents a Smart E-Commerce System that integrates a deployable hybrid recommendation engine and customer behavior analytics with customer, merchant, and administrator workflows. Source-code review confirms a two-branch recommender: implicit-feedback collaborative item similarity and TF-IDF content similarity, combined with a 75/25 hybrid blend when both signals are available. Behavior is weighted by event intent and time decay, while cold-start users are supported by a popularity-based strategy. The implementation further separates offline training from online serving through versioned artifacts, Redis publication, and SQL fallbacks.

The synthetic evaluation demonstrates that the implemented recommendation pipeline can be tested reproducibly and that personalized methods substantially outperform the popularity baseline in the generated environment. Future work should validate these findings using anonymized real-world interaction data, evaluate cold-start users separately, tune the hybrid weighting, and add diversity, novelty, latency, and scalability measurements.

Acknowledgment

The authors acknowledge Norton University and the course lecturer for the project and journal-style paper guidance. The group also acknowledges all members who contributed to system analysis, interface implementation, database design, recommendation logic, testing, and documentation.

References

[1] Y. H. Cho and J. K. Kim, “Application of Web usage mining and product taxonomy to collaborative recommendations in e-commerce,” Expert Systems with Applications, vol. 26, no. 2, pp. 233–246, 2004, doi: 10.1016/S0957-4174(03)00138-6.

[2] H. J. Ahn, “A new similarity measure for collaborative filtering to alleviate the new user cold-starting problem,” Information Sciences, vol. 178, no. 1, pp. 37–51, 2008, doi: 10.1016/j.ins.2007.07.024.

[3] “Evaluating the Effectiveness of Collaborative Filtering Similarity Measures: A Comprehensive Review,” Procedia Computer Science, vol. 235, pp. 2641–2650, 2024, doi: 10.1016/j.procs.2024.04.249.

[4] Y. Li, L. Lu, and L. Xuefeng, “A hybrid collaborative filtering method for multiple-interests and multiple-content recommendation in E-Commerce,” Expert Systems with Applications, vol. 28, no. 1, pp. 67–77, 2005, doi: 10.1016/j.eswa.2004.08.013.

[5] H. Hwangbo, Y. S. Kim, and K. J. Cha, “Recommendation system development for fashion retail e-commerce,” Electronic Commerce Research and Applications, vol. 28, pp. 94–101, 2018, doi: 10.1016/j.elerap.2018.01.012.