Imagine: an assortment of 50,000 products, but the "Popular" widget keeps showing the same items. Conversion drops, average order value stagnates. Personalization is the only way out. We develop custom product recommendation engines that solve this problem. Unlike ready-made "black boxes," our solutions are transparent: you control the logic, data, and budget. Over 50 online stores already use our recommendations — average conversion uplift is 12–18%.
Standard widgets stop working when catalog exceeds 10,000 positions. Users expect personalization; without it, LTV decreases. We offer phased implementation: from simple rules to ML models. At each stage you see business metrics and can stop once goals are met. Our engineers hold AWS Machine Learning certifications and have over eight years of experience with recommendation systems for e-commerce.
With 10+ years of e-commerce experience and 50+ implementations, we deliver proven results. Typical implementation costs range from $5,000 for rule-based to $20,000 for ML-based systems. Clients see an average ROI of 300% within the first year.
Which Recommendation Algorithm to Choose for Your Store?
Choice depends on data volume and goals. The table below shows typical scenarios.
| Level | Approach | Applicability |
|---|---|---|
| Basic | Rule-based (popular, new, discounted) | Starting any store |
| Intermediate | Item-based collaborative filtering | 10k+ orders in DB |
| Advanced | Matrix factorization (ALS, SVD) | 100k+ events |
| Enterprise | Deep learning (two-tower, BERT4Rec) | ML infrastructure |
For 80% of stores, intermediate level is optimal: collaborative filtering based on orders, supplemented by content signals. For example, for a store with 50,000 orders, personalized blocks outperform rule-based ones by 3x in CTR.
Why Collaborative Filtering Works?
Collaborative filtering uses real purchase patterns, not expert rules. It automatically finds non-obvious connections: if sneaker buyers often order socks, the system picks that up. An additional advantage is scalability: as the catalog grows, recommendation quality does not degrade but improves. Our co-purchase matrix identifies product pairs often bought together. We implement it via materialized views and a PHP service.
CREATE MATERIALIZED VIEW product_cooccurrences AS SELECT oi1.product_id AS product_a, oi2.product_id AS product_b, COUNT(DISTINCT oi1.order_id) AS cooccurrence_count FROM order_items oi1 JOIN order_items oi2 ON oi1.order_id = oi2.order_id AND oi1.product_id != oi2.product_id JOIN orders o ON oi1.order_id = o.id WHERE o.status = 'completed' GROUP BY oi1.product_id, oi2.product_id HAVING COUNT(DISTINCT oi1.order_id) >= 3; CREATE INDEX idx_cooc_product_a ON product_cooccurrences(product_a, cooccurrence_count DESC); Materialized view update via nightly cron: $schedule->command('db:refresh-cooccurrences')->dailyAt('03:00');
Class to fetch similar products:
class CollaborativeRecommender { public function getSimilar(int $productId, int $limit = 8): Collection { $recommendedIds = DB::table('product_cooccurrences') ->where('product_a', $productId) ->orderByDesc('cooccurrence_count') ->limit($limit) ->pluck('product_b'); return Product::whereIn('id', $recommendedIds) ->where('is_active', true) ->orderByRaw("array_position(ARRAY[" . $recommendedIds->implode(',') . "]::bigint[], id)") ->get(); } } For logged-in users we add a personal approach: select categories from recent orders and offer products from them that the user hasn't purchased. This approach is simple to implement and gives good results from the start.
Advanced Level: ML Recommendations in Python
For stores with over 100,000 events, we integrate an ALS model using implicit. A FastAPI microservice is deployed separately and communicates with PHP over HTTP.
# recommendations_service/main.py import implicit import numpy as np from scipy.sparse import csr_matrix from fastapi import FastAPI app = FastAPI() model = implicit.als.AlternatingLeastSquares(factors=64, iterations=20) @app.get("/recommendations/user/{user_id}") async def user_recommendations(user_id: int, n: int = 12): user_idx = user_id_to_idx.get(user_id) if user_idx is None: return {"items": get_popular_fallback(n)} ids, scores = model.recommend(user_idx, user_item_matrix[user_idx], N=n) product_ids = [idx_to_product_id[i] for i in ids] return {"items": product_ids, "scores": scores.tolist()} The PHP backend caches results for 30 minutes and falls back to rule-based if the service is unavailable.
Event Tracking for Model Training
Recommendation quality directly depends on data. We set up event collection: views, cart additions, and purchases. Data is stored in a separate table:
CREATE TABLE recommendation_events ( id BIGSERIAL PRIMARY KEY, event_type VARCHAR(30) NOT NULL, user_id BIGINT, session_id VARCHAR(64), product_id BIGINT, metadata JSONB, created_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX idx_rec_events_user ON recommendation_events(user_id, created_at DESC); Events come via an API and are used for nightly model retraining.
How to Implement Recommendations in 10 Days?
Recommendation system development is an iterative process. We break it down into stages:
- Data and infrastructure audit (1–2 days). Check DB schema, data availability and quality, current architecture.
- Approach selection (1 day). Decide optimal level: rule-based, collaborative, or ML. Align with you.
- Pipeline development (3–5 days). Create materialized views, microservice, or ML model. Set up API for recommendations.
- Frontend integration (1–2 days). Embed widgets on site via REST or GraphQL. Set up event tracking.
- A/B testing (2–4 weeks). Compare algorithms, pick best. Our A/B testing recommendations help you choose the best algorithm.
- Documentation and training (1 day). Transfer knowledge to your team.
| Stage | Duration | Result |
|---|---|---|
| Audit | 1–2 days | Data report |
| Approach selection | 1 day | Technical specification |
| Development | 3–5 days | Working backend |
| Integration | 1–2 days | Widgets on site |
| A/B test | 2–4 weeks | Best algorithm |
| Documentation | 1 day | Instructions |
ML model training details
For ALS model, user-item matrix factorization takes 2–3 hours for 100k events. Retraining occurs nightly. For quality control we use precision@k and recall@k metrics.What's Included in Development?
We deliver the full package: from data audit to documentation and team training. A typical project includes:
- Audit of current data schema and infrastructure
- Architecture selection: rule-based, collaborative, or ML
- Implementation of computational pipelines (materialized views, cron, or ML service)
- Frontend integration via REST/GraphQL API
- Event tracking and analytics setup
- A/B testing of algorithms
- Documentation, training, and 2 weeks of support
- Increase average order value through personalized recommendations
Development timeline: from 10 working days. Implementation budget is calculated individually based on project complexity. Request a preliminary assessment of your project — contact us for a consultation.
Our team has 10+ years of e-commerce experience, over 50 implementations, and certified engineers. We provide transparent reporting and guarantee results. Order end-to-end recommendation system development — get a tool that truly boosts sales.







