Next Best Product (NBP) Recommendations

Recommend the right next product to every customer — personalized, at scale, with no custom ML pipeline required.

The NBP workflow from Treasure AI's machine learning platform (AI Signal) generates a ranked list of products — or services, or content — most likely to resonate with each customer, based on their transaction history. It learns from who bought what and when, then predicts what each customer is most likely to want next. The recommendations feed directly into Treasure AI features like Journeys, Triggers, Personalization, Segment Builder, and Agent Console, giving marketing, CRM, and digital teams a ready-to-activate personalization signal without building a recommender from scratch. The solution offers three complementary recommendation algorithms under one workflow:

Collaborative filtering (ALS) learns latent preferences via matrix factorization across your entire user base. It discovers patterns like "users who bought X also tend to buy Y" without needing explicit item metadata. It is the highest-quality personalization option and works best for known users with rich transaction history.

Item-similarity (similar_to_latest) recommends items most similar to each user's most recent purchase. It works for any user with at least one transaction and is fast and resilient when new items appear often.

Trending items (popular) returns the most-purchased or most-viewed items across the whole user base. It handles cold-start users who have no history at all and serves as a reliable universal fallback.

Common use cases:

• Personalize product carousels on your website or app based on each user's predicted interests
• Power personalized email campaigns with per-customer product recommendations
• Build cross-sell and upsell journeys triggered by a customer's next-best-product list
• Recommend content (articles, videos, shows) to keep users engaged between purchases
• Solve the cold-start problem by combining popular for new users with als for known users

Who benefits most: Lifecycle marketers, personalization teams, and CRM managers who need per-customer recommendations across millions of profiles — without a dedicated ML platform or data science team.

NBP AI Signals requires a transaction-level table — one row per purchase (or view, click, or other interaction). Column names are configurable via parameters.

NBP AI Signals produces up to three output tables depending on your configuration: a per-customer recommendations table, an optional similar-items table, and an optional metrics table.

User Recommendations Table — one row per customer, with a ranked array of recommended items:

Similar Items Table (optional, when similar_items_table is configured) — for each item, its most similar peers:

Training Metrics Table (optional, when metrics_table is configured) — stores model performance per training run:

A sample of the recommendations table after prediction with a six-item topk:

A sample of the similar items table (from als or similar_to_latest):

Reading the output: rec_items is ordered by predicted relevance — the first ID is the top recommendation for that user. Array length matches the topk parameter (default 10, max 100). The similar items table is useful for "customers who bought this also liked…" style widgets and for fallback recommendations when a user is not in the trained model.

NBP supports three algorithms, each with different strengths. You can run them separately and merge the outputs downstream.

The pipeline has two stages, training and prediction, and each accepts its own configuration. Parameters fall into two groups: common parameters that apply to all algorithms, and algorithm-specific parameters.

Common parameters (all algorithms):

als-specific parameters:

popular-specific parameters:

similar_to_latest-specific parameters:

Tuning notes:

• tunable: true on als — Enable when model quality matters more than predictable resource use.
• filter_num above 0 — Use on datasets with very long-tail items (e.g., millions of SKUs) to cut training memory significantly.
• filter_viewed: true — Use for product recommendations where repeat purchases are rare; leave it false for consumables.
• lastk on similar_to_latest — Raise to 5 when users have multi-item baskets and the latest item alone doesn't represent intent well.

NBP AI Signals runs in two stages: a training workflow that fits and registers the model, and a prediction workflow that scores customers using the registered model. The two stages can run on different cadences. For example, train weekly and predict daily or hourly, which keeps compute costs down without letting your recommendations go stale.

The workflow structure is the same for all algorithms; the difference is in the solution_arguments block. Pick the tab that matches your chosen algorithm.

# nbp_train_als.dig
# Treasure Workflow: NBP AI Signals — ALS Training
# Fits the collaborative filtering (ALS) model on your transaction
# history and registers it under `model_name`.

_export:
  user_column: user_id
  item_column: item_id
  tstamp_column: timestamp
  input_dataset: purchases
  algorithm: als

# Step 1: Submit the training job
+train:
  http>: https://ml-batch-api.treasuredata.com/v1/runs/
  method: POST
  headers:
    - authorization: ${secret:td.apikey}
    - X-TD-ML-SESSION-ID: ${session_id}
    - X-TD-ML-ATTEMPT-ID: ${attempt_id}
  store_content: true
  content:
    input_table: rec_ml_datasets.${input_dataset}
    output_table: rec_ml_datasets.${input_dataset}_${algorithm}_outputs
    solution_name: nbp_train
    solution_arguments:
      model_name: ${input_dataset}_${algorithm}
      algorithm: ${algorithm}
      user_column: ${user_column}
      item_column: ${item_column}
      tstamp_column: ${tstamp_column}
      tunable: true
      similar_items_table: rec_ml_datasets.${input_dataset}_${algorithm}_similar

+print_response:
  echo>: "Training job submitted. Response: ${http.last_content}"

# Step 2: Poll until training completes
+train_poll_status:
  http>: https://ml-batch-api.treasuredata.com/v1/runs/${JSON.parse(http.last_content)['id']}/status
  method: GET
  headers:
    - authorization: ${secret:td.apikey}

# nbp_predict_als.dig
# Treasure Workflow: NBP AI Signals — ALS Prediction
# Loads the ALS model registered under `model_name` and scores
# customers with per-user product recommendations.

_export:
  user_column: user_id
  item_column: item_id
  tstamp_column: timestamp
  input_dataset: purchases
  algorithm: als

# Step 1: Submit the prediction job
+pred:
  http>: https://ml-batch-api.treasuredata.com/v1/runs/
  method: POST
  headers:
    - authorization: ${secret:td.apikey}
    - X-TD-ML-SESSION-ID: ${session_id}
    - X-TD-ML-ATTEMPT-ID: ${attempt_id}
  store_content: true
  content:
    input_table: rec_ml_datasets.${input_dataset}
    output_table: rec_ml_datasets.${input_dataset}_${algorithm}_recommendations
    solution_name: nbp_predict
    solution_arguments:
      model_name: ${input_dataset}_${algorithm}
      algorithm: ${algorithm}
      user_column: ${user_column}
      item_column: ${item_column}
      tstamp_column: ${tstamp_column}
      topk: 10

+print_response:
  echo>: "Prediction job submitted. Response: ${http.last_content}"

# Step 2: Poll until prediction completes
+pred_poll_status:
  http>: https://ml-batch-api.treasuredata.com/v1/runs/${JSON.parse(http.last_content)['id']}/status
  method: GET
  headers:
    - authorization: ${secret:td.apikey}

What these workflows do: The training workflow submits a job that fits the chosen algorithm, evaluates it on a holdout set, writes metrics to your output table (if configured), and registers the trained model under model_name. The model persists at the account level for 6 months. The prediction workflow loads that registered model and scores the customers in your input table, writing per-customer recommendations to a separate output table. The polling steps handle the ML Batch API's behavior of returning HTTP 408 while a job is still running — Treasure Workflow automatically retries until it receives HTTP 200.

Why split training from prediction? Training is expensive and only needs to run when your product catalog or customer base has changed materially — typically once a week. Prediction is cheap and benefits from running often, usually daily or hourly, so that recently active customers receive fresh recommendations. Splitting the two stages lets you tune each cadence independently.

Combining algorithms: To cover both known and cold-start users, run training and prediction separately for als, similar_to_latest, and popular, then merge the output tables in a downstream SQL step — prioritizing als first, falling back to similar_to_latest, then popular.

NBP is designed to handle enterprise-scale datasets. The table below shows measured runtimes across profile counts, without parallelization, to establish a baseline.

Baseline performance (single task):

With 8-way parallel prediction:

Guidelines:

• Under 10M profiles: No parallelization needed. A single 64 GiB instance handles all three algorithms.
• 10M–100M profiles: Parallelize prediction across 8 tasks (max concurrency per account). ALS still needs 128 GiB instances at this range.
• Over 100M profiles: ALS cannot recommend for all profiles without training on the full set. Use similar_to_latest or popular as the primary algorithm, optionally training on a 10% sample. Apply filter_num to trim long-tail items.

Contact your Treasure AI account team if your dataset exceeds 500 million profiles to discuss infrastructure and pricing options.

• ALS cannot recommend for users not in the training data. Pair it with similar_to_latest or popular to cover new customers.
• Models expire after 6 months. Re-train before the expiration window to avoid prediction failures.
• similar_to_latest cannot handle cold items. Items must appear at least once in the training data to be recommended. In most real deployments, cold items aren't a significant problem.
• Training is infrequent by design. NBP assumes weekly (or similar) full retraining, with more frequent prediction runs on the saved model. Partial or online training is not supported.
• Parallelization has overhead. Below 10M profiles, parallelizing prediction is slower than a single task due to data-splitting cost. Only parallelize at larger scales.
• ALS resource usage is less predictable with tunable: true. Optuna-driven tuning can shift memory and time per run. Set tunable: false for stable, reproducible resource use.
• Pre-aggregated data is not used. NBP needs raw transactions, not customer-level aggregates. For aggregate-based segmentation, use RFM AI Signals instead.