You've built the product. Traffic is growing. But average order value is flat, and users churn before they find the features that would make them stay. This is often not a marketing problem — it's a discovery problem. A well-built recommendation engine quietly solves it by surfacing the right product, plan, or content at the right moment, without the user having to go hunting. The challenge is knowing which approach to build and in what order, because getting this wrong wastes engineering months on a system that underperforms a simple sort.
Understanding the Two Core Paradigms
Before writing a line of code, you need to be honest about what data you actually have. Recommendation algorithms divide into two families, and picking the wrong one for your data situation is one of the most common early mistakes.
Collaborative Filtering
Collaborative filtering learns from collective behaviour: users who liked A also liked B, so we recommend B to anyone who liked A. The appeal is that it requires no understanding of the items themselves — it discovers relationships purely from interaction signals. The problem is the cold-start problem: new items get no recommendations until they accumulate interactions, and new users get no personalisation until they generate signal.
Two main variants:
- User-based CF: Find similar users, then recommend what they engaged with. Computationally expensive at scale; works best when your user base is in the thousands, not millions.
- Item-based CF (matrix factorisation): Decompose a user-item matrix into latent factors. Techniques like SVD and ALS (used in Spark MLlib) scale much better. This is what most production systems run at their core.
Content-Based Filtering
Content-based filtering recommends items similar to ones a user has already engaged with, based on item attributes — category, price range, tags, text descriptions. It solves the item cold-start problem cleanly, because new items are characterised immediately by their metadata. The weakness: it can trap users in a recommendation bubble, over-serving them variations of things they already know about.
Hybrid Approaches
Production systems almost always combine both. A common pattern: use content-based signals to handle cold-start, then blend in collaborative signals once a user has 10–20 meaningful interactions. The blending can be as simple as a weighted average of scores or as sophisticated as a meta-learner (a lightweight model that learns the optimal blend per user segment).
Choosing Your Signals
The quality of your recommendations depends less on algorithm choice than on signal quality. Every interaction a user has is a potential signal — but not all signals carry equal weight.
| Signal Type | Strength | Notes |
|---|---|---|
| Purchase / conversion | Very strong | Explicit intent; use as positive ground truth |
| Add to cart / wishlist | Strong | Intent without commitment; weight slightly below purchase |
| Page dwell time (>30s) | Medium | Filter out pages where user likely left tab open |
| Click-through | Weak–Medium | Easily inflated by position bias; deboost top-of-page items |
| Search queries | Strong | High intent; map to item taxonomy carefully |
| Returns / cancellations | Negative signal | Suppress or downrank similar items |
One point practitioners often underestimate: position bias. Items shown at the top of any page receive more clicks regardless of relevance. If you train on raw click data without correcting for position, you'll teach your model to recommend things that used to appear at the top — a self-reinforcing loop that degrades diversity over time. Inverse propensity scoring is the standard correction.
A Pragmatic Rollout Plan
Rather than building a full personalisation stack before you have evidence it helps, treat this as a staged rollout with measurable gates at each phase.
Phase 1: Baseline (Week 1–2)
Start with non-personalised rules: "bestsellers in category", "frequently bought together" (based on co-occurrence in the same basket), and "recently viewed." These are simple joins and counts, can run on your existing database, and establish a performance baseline. Measure click-through rate and conversion rate per recommendation placement.
Phase 2: Content-Based Layer (Week 3–6)
Build item embeddings from your product catalogue. For text-heavy items (SaaS features, articles, products with descriptions), TF-IDF or sentence embeddings (using a model like all-MiniLM-L6-v2) give you dense vector representations. Store them in a vector index (FAISS for on-prem, or a managed service). Now you can answer "find me items similar to this one" in milliseconds. A/B test this against Phase 1 baselines.
Phase 3: Collaborative Filtering (Month 2–3)
Once you have a few thousand users with meaningful interaction histories, train a matrix factorisation model. ALS in Spark MLlib or a lightweight Implicit library implementation both work well at mid-scale. Schedule weekly retrains initially; move to daily once the model proves its value.
Phase 4: Blend and Serve (Month 3–4)
Build a retrieval-and-ranking pipeline: the retrieval step generates candidate items (typically 100–500) using collaborative or content signals; the ranking step scores candidates using a gradient-boosted model that incorporates user context (device, session recency, segment). This separation keeps inference fast even as the catalogue grows.
Infrastructure Considerations
You don't need a massive data platform to start. A few realistic technology choices:
- Small scale (<100K users): PostgreSQL for interaction logs, Python (Pandas + Scikit-learn or Implicit), FAISS for vector search, cron-scheduled retrains.
- Medium scale (100K–5M users): Kafka for real-time event streaming, Spark for batch training, Redis for serving pre-computed recommendation lists, feature store (Feast or Hopsworks) to share features between training and serving.
- Large scale (>5M users): Dedicated ML platform (Vertex AI, SageMaker, or self-managed Kubeflow), real-time feature computation, multi-stage ranking pipelines, shadow testing infrastructure.
The most important infrastructure decision is the serving layer. Precomputing recommendations for every user and storing in Redis gives sub-millisecond retrieval but goes stale between recomputes. Real-time retrieval is always fresh but adds latency. Most teams start with precomputed and add real-time signals (like current session context) only when they have evidence of the latency-freshness tradeoff mattering.
Evaluation: What to Measure
Offline metrics give you a development signal, but they're not your North Star.
| Metric | What it measures | Limitation |
|---|---|---|
| Precision@K | Fraction of top-K recs the user actually liked | Doesn't reward diversity or serendipity |
| Recall@K | Coverage of items the user would have liked | Needs held-out test interactions |
| NDCG@K | Ranking quality, position-weighted | Complex; less intuitive for product teams |
| Coverage | % of catalogue that gets recommended | High coverage doesn't mean good recommendations |
Run A/B tests or multi-armed bandit experiments in production. The business metrics that matter are: recommendation-influenced revenue, click-through rate per placement, and for SaaS specifically, feature adoption rate and time-to-activation for new users. Offline metrics should only be used to filter out obviously bad models before running live experiments.
Common Pitfalls to Avoid
- Over-recommending best-sellers: Without a diversity constraint, most collaborative models converge on popular items. Deliberately inject long-tail items at a 10–15% ratio.
- Ignoring business rules: Your recommendation system should never surface out-of-stock products, items the user already owns, or content behind a paywall the user hasn't subscribed to. Build a post-filtering layer for business constraints before any recommendation reaches the UI.
- Training on biased data: If you've previously shown rules-based recommendations, your training data reflects those choices, not unbiased user preferences. This is survivorship bias at the data layer — acknowledge it and correct where possible.
- Skipping explainability: "Because you viewed X" labels increase user trust and click-through. Even a simple template-based explanation derived from the retrieval signal helps conversion.
Frequently Asked Questions
How much interaction data do I need before collaborative filtering works?
A practical minimum is around 50,000 user-item interactions from at least 1,000 distinct users. Below that, the latent factor matrix is too sparse to generalise. Use content-based filtering exclusively until you cross that threshold, then blend in collaborative signals gradually.
Should I build a recommendation engine myself or use a managed service?
Managed services like AWS Personalize, Google Recommendations AI, or Azure Personalizer reduce time-to-value significantly — you can have a baseline running in days. The trade-off is cost at scale and less control over the model architecture. For most startups, starting with a managed service and migrating a custom model once you understand your data patterns is the pragmatic path.
How do I handle the cold-start problem for new users?
Three standard approaches: (1) Ask users to select interests or categories during onboarding — even 3–5 preferences dramatically improves early recommendations. (2) Use demographic or referral-source signals to assign a starting segment. (3) Default to editorial "trending in your segment" recommendations until the user generates enough signal to personalise individually.
How often should I retrain the recommendation model?
It depends on how fast your catalogue and user behaviour change. Weekly retrains work for most e-commerce platforms with a stable catalogue. SaaS platforms releasing features rapidly may need daily retrains for the content-based layer. Collaborative models can often tolerate weekly retraining since cumulative preferences change slowly, while real-time session context should be applied at serving time regardless of training cadence.
When you're ready to build this, Mexilet can help — explore our computer vision services and AI solutions.
If you're ready to move from guesswork to a data-driven recommendation layer, the team at Mexilet Technologies can help you design and build the right architecture for your platform — from initial signal instrumentation through to a production-grade serving layer. Reach out to discuss your specific requirements and get a no-obligation assessment of where a recommendation engine would move the needle for your business.