Disclaimer: The views expressed herein are for reference only and don't necessarily represent the official views of Alibaba Cloud.
Most e-commerce revenue comes from repeat customers, and much of it is driven by product discovery.
Personalised recommendations based on user behaviour consistently outperform generic bestseller lists by increasing clicks and average order value.
What once required large data science teams can now be built much faster with tools like Alibaba Cloud Platform for AI (PAI).
This guide explains how to turn raw behavioural data into a real-time recommendation API for your e-commerce store.
Before jumping into the console, it helps to understand what the pipeline actually does.
A production recommendation system is not a single model. It is a multi-stage process with each stage reducing a large pool of candidates down to a smaller, more relevant set.
The process includes multi-channel matching, where the inference module uses item-based collaborative filtering, semantic matching, hot matching, and operation strategy matching to retrieve thousands of candidates.
This is followed by exposed content deduplication based on users' read history, and finally a ranking stage where the module calls item and user features and returns the ranked results.
In simpler terms, the pipeline works in two main stages:
Stage 1: Recall (Matching). Starting from your full product catalogue, which might be thousands or millions of items, the recall stage narrows the field down to a few hundred candidates that have some relevance to the current user. Collaborative filtering is the most widely used algorithm here because it works well with behavioural data alone, without requiring detailed product metadata.
Stage 2: Ranking. The ranking stage takes those few hundred candidates and orders them by predicted relevance for the specific user. Ranking models use richer feature sets including user profile data, item attributes, and context signals like time of day or device type.
For this tutorial, you will build a system using collaborative filtering for recall, deployed through PAI's visual designer interface with no code required, and served through PAI Elastic Algorithm Service (EAS) as a real-time API.
Collaborative filtering is worth understanding briefly because it shapes how you need to prepare your data.
The classic explanation is this: users A and C have similar tastes. Both like rice and milk. User A also likes lamb. Because their tastes are similar, we assume user C would also like lamb and treat that as a recommendation.
This is standard collaborative filtering based on data statistics: find similar users or items, then identify a recommendation logic based on the correlations between them.
In practice, your algorithm does not work with "rice" and "lamb" but with product IDs and user IDs. The input is a behaviour table recording which users interacted with which products.
The output is a similarity matrix that maps each product to the products most often co-viewed or co-purchased alongside it.
This means collaborative filtering does not need your product descriptions, pricing, or category tags to work.
It only needs a record of who did what. That makes it one of the most practical starting points for teams who have transaction history but have not yet built a full product feature store.
The full stack you will build uses five Alibaba Cloud services working together:
MaxCompute stores your raw behaviour data (user events) and the processed training data. It is the data layer that PAI reads from during model training.
OSS (Object Storage Service) stores the temporary model artefacts and pipeline outputs generated during PAI Designer runs.
PAI Designer provides the visual drag-and-drop canvas where you build and run your recommendation pipeline. No code is needed for the core collaborative filtering workflow.
PAI EAS (Elastic Algorithm Service) deploys your trained model as a scalable REST API endpoint that your e-commerce platform calls to get recommendations in real time.
DataWorks schedules the PAI Designer pipeline to re-run on a regular basis, so your model is retrained on fresh behavioural data automatically.
The overall architecture works like this: first, you generate collaborative filtering result data from your raw data in PAI Designer and obtain model output tables.
Next, you migrate the output tables to the serving layer. Then, you configure a policy for the tables through PAI. Finally, you convert this policy to a PAI-EAS service. The whole set of services can be automated.
Before starting, have the following in place:
AliyunPAIFullAccess, AliyunMaxComputeFullAccess, and AliyunOSSFullAccess to use all features in this guideIf you do not yet have behavioural data ready, PAI Designer's preset templates include sample data you can use to test the pipeline before connecting your own tables.
Your collaborative filtering model learns from a behaviour table. Log in to the MaxCompute console and create the following table structure in your project:
CREATE TABLE IF NOT EXISTS ecommerce.user_behavior (
user_id STRING COMMENT 'Unique user identifier',
item_id STRING COMMENT 'Unique product identifier',
event_type STRING COMMENT 'Type of interaction: view, cart, purchase',
event_time STRING COMMENT 'Timestamp in YYYY-MM-DD HH:MM:SS format',
dt STRING COMMENT 'Partition date in YYYYMMDD format'
)
PARTITIONED BY (dt STRING)
LIFECYCLE 365;Insert some sample rows to test with:
INSERT INTO ecommerce.user_behavior PARTITION (dt='20260501')
VALUES
('U001', 'P101', 'purchase', '2026-05-01 10:23:00'),
('U001', 'P102', 'view', '2026-05-01 10:25:00'),
('U001', 'P103', 'cart', '2026-05-01 10:27:00'),
('U002', 'P101', 'purchase', '2026-05-01 11:00:00'),
('U002', 'P104', 'purchase', '2026-05-01 11:05:00'),
('U003', 'P102', 'view', '2026-05-01 14:00:00'),
('U003', 'P103', 'purchase', '2026-05-01 14:10:00'),
('U003', 'P104', 'view', '2026-05-01 14:12:00');In production, this table will be populated by your site's event tracking system, typically through a DataWorks pipeline that ingests clickstream or purchase events from your application logs on a daily schedule.
One important design decision at this stage is how to weight different event types. A purchase should carry more signal than a page view.
A common weighting scheme assigns a score to each event type: purchase gets a weight of 5, add-to-cart gets 3, and view gets 1. You can encode this weighting as a numeric column in your behaviour table, or handle it in the SQL preprocessing step inside Designer.
Log in to the PAI console. In the left navigation pane, click Workspaces and select your workspace. From the workspace page, navigate to Model Development and Training > Visual Modeling (Designer).
PAI-Designer eliminates coding barriers for ML teams by offering a visual, drag-and-drop canvas that connects TensorFlow, PyTorch, and MaxCompute components into end-to-end pipelines, accelerating model iteration without writing a single line of code.
On the Designer page, click the Preset Templates tab. Look for the section labelled Recommended Algorithms - Product Recommendation.
In the Recommended Algorithms - Product Recommendation section of the Preset Templates tab, click Create. In the Create Pipeline dialog box, configure the parameters.
You can use their default values. The value specified for the Pipeline Data Path parameter is the OSS bucket path for temporary data and models generated during the runtime of the pipeline.
Set the Pipeline Data Path to your OSS bucket, for example:
oss://your-pai-bucket/recommendation-pipeline/Click Create. Designer generates a pre-built recommendation pipeline on the canvas. This template gives you a complete collaborative filtering workflow out of the box, which you will then connect to your own data in the next step.
The pre-built template contains a data source node, several preprocessing components, the collaborative filtering algorithm node, and an output node.
You need to point the data source node at your MaxCompute behaviour table.
Configure the data source node:
Click the Read Table node on the canvas. In the configuration panel on the right, set the following:
ecommerce.user_behavior
dt=20260501 (or use a scheduling variable like dt=${bizdate} for automated runs)After adding the data source component, switch to the Fields Information tab in the node configuration section to view the field details. This helps you confirm the schema matches what the downstream components expect.
Configure the collaborative filtering node:
Click the collaborative filtering algorithm component in the pipeline. Set the following parameters:
| Parameter | Recommended Value | Notes |
|---|---|---|
| User Column | user_id |
Column containing unique user identifiers |
| Item Column | item_id |
Column containing unique product identifiers |
| Rating Column | event_weight |
Numeric column encoding interaction strength |
| Number of Recommendations | 20 |
Items to recommend per user |
| Similarity Type | item |
Item-based CF; scales better than user-based for large catalogues |
If your behaviour table does not have a pre-computed event_weight column, add a SQL Script component upstream of the collaborative filtering node to compute it:
SELECT
user_id,
item_id,
CASE event_type
WHEN 'purchase' THEN 5
WHEN 'cart' THEN 3
WHEN 'view' THEN 1
ELSE 0
END AS event_weight
FROM ecommerce.user_behavior
WHERE dt = '${bizdate}'
AND event_type IN ('purchase', 'cart', 'view')Drag the SQL Script component onto the canvas, paste the query above, and connect it between the Read Table node and the collaborative filtering node.
Configure the output node:
The pipeline produces two output tables: a user-to-item recommendations table (for personalised recommendations per user) and an item-to-item similarity table (for "customers also viewed" style widgets).
Set both output paths to MaxCompute tables in your project:
ecommerce.cf_user_recommendationsecommerce.cf_item_similarityClick the run icon in the upper-left corner of the canvas to execute the full pipeline. The designer shows a progress indicator on each node as it moves through the stages.
After a component runs, you can right-click it and select View Data to view the generated data.
For specific components, Machine Learning Designer converts data into graphs and charts to display complex data and analysis results in an intuitive and easy-to-understand manner.
Once the pipeline completes, right-click the output node and select View Data. You should see rows like:
user_id | item_id | score
---------|-----------|--------
U001 | P104 | 0.87
U001 | P105 | 0.73
U002 | P102 | 0.91
U002 | P103 | 0.82
...Each row represents a recommendation: user U001 has an 87% predicted affinity for product P104 based on the collaborative filtering model. The score is a normalised similarity metric, not a probability, but higher scores indicate stronger predicted relevance.
If the output looks reasonable given your input data, you are ready to deploy.
PAI Designer can deploy your trained model directly to EAS, Alibaba Cloud's managed online inference service. EAS provides a scalable REST API endpoint with automatic resource allocation and pay-per-use billing.
In the Designer pipeline, click the output node and select Deploy to EAS from the node's action menu. Configure the service:
product-recommendation-cf
Click Deploy. EAS creates the service and provides an endpoint URL and an access token after a few minutes.
After you deploy the model service, go to the Elastic Algorithm Service page. In the Service Method column, find the service and click Invocation Method to view its endpoint and token information.
Save both the endpoint URL and the token. You will use them in the next step to call the API from your application.
Your e-commerce platform calls the PAI EAS endpoint to get recommendations for a specific user. Here is a Python example that retrieves the top 10 recommendations for a given user ID:
import os
import json
import requests
EAS_ENDPOINT = os.environ.get("PAI_EAS_ENDPOINT")
EAS_TOKEN = os.environ.get("PAI_EAS_TOKEN")
def get_recommendations(user_id: str, top_n: int = 10) -> list:
"""
Fetch the top N product recommendations for a given user.
Returns a list of product IDs ordered by relevance score.
"""
headers = {
"Authorization": EAS_TOKEN,
"Content-Type": "application/json"
}
payload = {
"user_id": user_id,
"top_n": top_n
}
try:
response = requests.post(
EAS_ENDPOINT,
headers=headers,
json=payload,
timeout=2.0 # Recommendation APIs should respond within 200ms in production
)
response.raise_for_status()
result = response.json()
return result.get("item_ids", [])
except requests.exceptions.Timeout:
print(f"Recommendation service timed out for user {user_id}. Falling back to bestsellers.")
return []
except Exception as e:
print(f"Recommendation service error: {e}")
return []
# Example usage in your product listing page handler
user_id = "U001"
recommendations = get_recommendations(user_id, top_n=10)
print(f"Recommended products for {user_id}: {recommendations}")A few important implementation details:
Set a short timeout. Recommendation APIs sit in the critical path of a page load. If the service is slow or unavailable, your page should fall back to a default product list rather than making the visitor wait. The 2-second timeout in the example above is conservative; in practice, EAS responses for collaborative filtering are typically under 100 milliseconds.
Build a fallback. Always define a fallback for when the recommendation API returns empty results or errors. The fallback could be globally popular products, category bestsellers, or recently viewed items stored in session. A page that shows something relevant is always better than a page that shows nothing while waiting for the recommendation service.
Cache recommendations where appropriate. For logged-in users browsing your homepage, you can cache recommendations server-side for 10 to 15 minutes. Recommendations do not need to change with every page load to be effective, and caching dramatically reduces the load on your EAS service at peak traffic times.
Collaborative filtering for registered users is only half the picture. A significant portion of your visitors are anonymous: they have no user ID in your system and therefore no personalisation history to train on.
For anonymous visitors, the item-to-item similarity table you generated alongside the user recommendations table is the right tool. Given the product a visitor is currently viewing, you look up the most similar items in the similarity table and display them as "Customers also viewed" or "You might also like."
def get_similar_items(item_id: str, top_n: int = 8) -> list:
"""
Fetch items most similar to the given item_id.
Used for anonymous visitors and product page widgets.
"""
headers = {
"Authorization": EAS_TOKEN,
"Content-Type": "application/json"
}
payload = {
"item_id": item_id,
"top_n": top_n,
"mode": "item_similarity" # Tells EAS to use the I2I table
}
try:
response = requests.post(
EAS_ENDPOINT,
headers=headers,
json=payload,
timeout=2.0
)
response.raise_for_status()
return response.json().get("item_ids", [])
except Exception as e:
print(f"Item similarity error for {item_id}: {e}")
return []This function takes the product the visitor is currently viewing and returns the eight most similar products.
Display these in a "Related Products" section on your product detail page. For visitors who never log in, this widget does more recommendation work than any personalised model could, because it operates on product-level signals that apply to every visitor viewing that item.
A recommendation model trained once on historical data gets stale quickly. New products are added to your catalogue.
Seasonal trends shift purchase behaviour. Customer preferences change. The model needs to be retrained regularly on fresh data to stay accurate.
You can use DataWorks tasks to periodically schedule Machine Learning Designer pipelines offline and automatically synchronize PAI models to Object Storage Service during task scheduling.
To set this up:
DataWorks will now run your full recommendation pipeline automatically every night: reading fresh behaviour data from MaxCompute, retraining the collaborative filtering model, writing updated recommendation tables, and pushing the updated model to EAS.
File paths in DataWorks scheduling support variables. For example, you can use a path like oss://examplebucket.oss-region.aliyuncs.com/${variable}/example.csv. Using scheduling parameters as variables means the recurring schedule reads from or writes to different storage paths on each run.
Use the ${bizdate} scheduling variable in your MaxCompute read query so each run pulls the previous day's behaviour data automatically.
Collaborative filtering is a strong starting point, but it has known limitations worth planning around.
Cold start for new products: A new product that has no interaction history cannot appear in collaborative filtering recommendations because there is no behavioural signal for the model to learn from. Address this by adding a "new arrivals" or "popular in category" slot alongside your personalised recommendations until the new product accumulates enough interactions.
Cold start for new users: A brand new user or an anonymous visitor has no personal interaction history. Address this with the item-to-item similarity approach from Step 7, or with a globally popular products fallback.
Popularity bias: Collaborative filtering naturally surfaces popular products more often because popular products appear in more user interaction records. Less popular products, even if highly relevant to a specific user, tend to be underrepresented. Address this by reserving some recommendation slots for "hidden gem" products: relevant but lower-visibility items that your business benefits from surfacing.
When you are ready to move beyond collaborative filtering, PAI offers more advanced approaches through the PAI-Rec platform.
PAI-Rec supports multiple recall methods, including global hot recall, which ranks popular items based on click events, etrec collaborative filtering, Swing item similarity, and DSSM vector recall.
For ranking, it supports MultiTower for single-objective ranking and DBMTL for multi-objective ranking.
The PAI-Rec platform also provides a full experiment management system that lets you run A/B tests between different recommendation algorithms without changing your application code, comparing click-through rates and conversion rates between model variants before committing to a full rollout.
A recommendation engine that is not measured is not improving. Before going live, define the metrics you will track and make sure you have the infrastructure to capture them.
Click-through rate on recommendations (CTR): Of the recommendation widgets shown, what percentage are clicked? This is the most direct measure of recommendation relevance. A very low CTR suggests the recommendations are not matching what users actually want.
Recommendation-to-purchase rate: Of users who click a recommendation, what percentage complete a purchase? This connects recommendation quality directly to revenue.
Coverage: What percentage of your product catalogue is appearing in recommendations across all users? Very low coverage means the model is over-concentrating on a small subset of products, which hurts both diversity and long-tail product discovery.
Lift over baseline: Compare conversion rates between users who saw personalised recommendations and users who saw a generic bestseller list. This is the metric that justifies continued investment in the recommendation system.
Track all of these metrics by logging recommendation impressions and clicks to a MaxCompute table.
You can then build a performance dashboard in Alibaba Cloud Quick BI that refreshes daily alongside your other marketing metrics, giving your team a single view of how the recommendation engine is performing relative to broader campaign activity.
Here is the complete pipeline, end to end:
The whole system runs automatically once it is set up. The only ongoing intervention required is monitoring the performance metrics and periodically adjusting model parameters as your catalogue and user base grows.
In this guide you built a production-grade product recommendation engine on Alibaba Cloud, covering:
The collaborative filtering approach you built here is a practical first step.
It delivers genuine personalisation from day one using only behavioural data, with no need for detailed product metadata or a dedicated machine learning team.
As your data volume and team confidence grow, the same PAI infrastructure supports more advanced ranking models and real-time feature updates, all from the same workspace.
Code examples in this article are for illustrative purposes. API parameter names and console navigation reflect Alibaba Cloud PAI as of early 2026. Always refer to the official documentation for current SDK versions and endpoint formats before deploying to production.
How to Host and Scale Marketing Landing Pages on Alibaba Cloud OSS and CDN
14 posts | 3 followers
FollowAlibaba Clouder - May 11, 2020
Iain Ferguson - January 6, 2022
Alibaba Cloud Project Hub - November 15, 2021
Alibaba Clouder - April 1, 2021
Kalpesh Parmar - October 10, 2025
Alibaba Clouder - September 25, 2020
14 posts | 3 followers
Follow
Intelligent Robot
A dialogue platform that enables smart dialog (based on natural language processing) through a range of dialogue-enabling clients
Learn More
ApsaraVideo Media Processing
Transcode multimedia data into media files in various resolutions, bitrates, and formats that are suitable for playback on PCs, TVs, and mobile devices.
Learn More
Architecture and Structure Design
Customized infrastructure to ensure high availability, scalability and high-performance
Learn More
Realtime Compute for Apache Flink
Realtime Compute for Apache Flink offers a highly integrated platform for real-time data processing, which optimizes the computing of Apache Flink.
Learn MoreMore Posts by Kalpesh Parmar