tensorturnBETA
HomeUse Cases

How to Build a Recommendation System Without Code

You can build a recommendation system in TensorTurn by framing it as a supervised ranking problem: upload your interaction history (which users saw or bought which items), describe the goal in chat, and it trains a propensity model — usually XGBoost or scikit-learn — that scores how likely each user is to engage with each item, then deploys a /predict API you call for candidate items and sort by score. TensorTurn is not a turnkey collaborative-filtering engine with pre-built user and item embeddings; instead it builds the ranking model that most production recommenders actually use to re-rank candidates.

How recommendation becomes a model you can train

A recommender is fundamentally a ranking problem: given a user and a candidate item (plus context), predict a relevance score, then sort the items by that score. In practice you train a supervised model on logged interactions where the label is whether the user engaged — clicked, added to cart, purchased or watched. TensorTurn builds exactly this scoring model. You supply the candidate items to score (for example, everything in a category, recently added items, or a popularity shortlist) and the model orders them per user. Be clear-eyed about the boundary: it does not do candidate generation or embedding-based retrieval for you.

What data you need

SignalExample featuresWhy it helps
Userdays since signup, past purchases, top category, avg spendcaptures taste and activity level
Itemcategory, price, brand, days since launch, popularitydescribes what is being recommended
Contexthour, weekday, device, placementthe same item is relevant at different moments
Crossuser's purchases in this item's category, price vs user's averagethe user-item interaction is what actually drives relevance

How to build a recommendation model with TensorTurn (no code)

How it's evaluated

The most useful offline metric is ROC-AUC, which is literally the probability the model ranks a relevant item above an irrelevant one — exactly what a recommender needs. PR-AUC matters because positives are rare (most impressions are not clicked). Two honest caveats: offline metrics only approximate real recommendation quality, and the only trustworthy test of a recommender is an online A/B test on live traffic, because offline data cannot show how users react to new suggestions. And leakage is dangerously easy — a feature like 'purchased_later' or an item field only known after the interaction will make offline scores look perfect and fail in production. Trust the health check.

Honest limits

TensorTurn builds the ranking and scoring model, not the entire recommendation stack. You still handle candidate generation (which items to score), cold start (new users and items have thin features, so lean on item and context signals), and freshness (retrain as behavior drifts). For catalogs of millions of items you would not score every item on every request — score a shortlisted candidate set and let the model order it.

Deploy as an API

Publish an authenticated /predict endpoint on Modal with a SHA-256-hashed Bearer key, per-call logging and scale-to-zero. At request time, send the user's features paired with each candidate item, take the returned scores, and sort to produce the ranked recommendations. The playground gives cURL, JavaScript, Python and Rust snippets to wire it into your app.

Start building free

Frequently asked questions

Does TensorTurn do collaborative filtering with user and item embeddings?

Not out of the box. It builds a supervised ranking model over the features you provide, which is how most production recommenders re-rank candidates. You bring the candidate items; the model scores and orders them.

What data do I need?

Logged interactions with an engagement label, plus user, item and context features — including negative examples (shown but not engaged), not only the positives.

Which algorithm will it pick?

Usually XGBoost or a scikit-learn classifier for tabular signals; a PyTorch or Keras model is possible for richer data. You describe the goal and it chooses and self-heals.

How do I know if it's any good?

Offline, use ROC-AUC and PR-AUC. In truth, only a live A/B test proves a recommender, because offline metrics can't see how users respond to new recommendations.

How do I handle new users or items (cold start)?

Lean on item and context features that exist immediately. Brand-new users with no history get popularity- or category-based fallbacks until they generate signal.

Can I use my own GPU?

Yes. Connect one machine, or pool several of your own, with a one-line, outbound-HTTPS-only command that works behind any firewall.