> For the complete documentation index, see [llms.txt](https://docs.dinmo.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dinmo.io/intelligence/product-recommendations/recommendation-use-cases.md).

# Choose a recommendation use case

Choose what needs a recommendation and what may be recommended. DinMo calls these the source and candidate scopes.

## Match the output to the business need

| Business need                                    | Source → candidates                     | Result                                                                             |
| ------------------------------------------------ | --------------------------------------- | ---------------------------------------------------------------------------------- |
| Personalized products or offers                  | Users → items                           | Up to K ranked items per user.                                                     |
| Related products                                 | Items → items                           | Up to K related items per source item, excluding the item itself.                  |
| An audience for each offer                       | Items → users                           | Up to K ranked users per item. The same user may appear in several audiences.      |
| Brand or category preferences                    | Users → vendor or category values       | Up to K ranked values per user. Requires the corresponding item attribute mapping. |
| An audience for each brand or category           | Vendor or category values → users       | Up to K ranked users per value. Audiences may overlap.                             |
| One campaign audience distributed between offers | Users → items, with audience allocation | At most one assignment per selected user, plus a separate top-K ranking.           |

In configuration, these correspond to user-to-item, item-to-item, item-to-user, and user-to-attribute directions. A vendor or category grain changes the entity being recommended; it does not return a specific product.

For example, to rank tomorrow's sales for each customer, use the sale or deal IDs as items. Ranking vendors answers a different question when a vendor has several sales.

## Define both scopes

A source scope determines who or what receives a recommendation. A candidate scope determines what can appear in the result. Restricting one does not restrict the other.

For personalized offers, a typical setup is:

* **Sources:** customers who can be contacted for this campaign.
* **Candidates:** items matching the campaign's stock, visibility, status, and activity rules.

Use [segments](/segments/visual-builder.md) to express those rules. They are resolved for the run; recheck eligibility before activation if the data has changed.

For vendor or category scenarios, the selected items define the available attribute values. Use the product grain when item-level eligibility and item-level output are essential.

## Item availability

An explicit item segment can include offers that have not opened yet, allowing you to prepare tomorrow's campaign today without changing the decision date.

* For products recommended to users and related products, this applies to the **candidate item segment**.
* For users recommended to an item, this applies to the **source item segment**.
* A user segment alone does not enable future items.

Future items explicitly selected this way are not excluded merely because they open after the scenario's objective horizon. Items with a known end date at or before the decision time remain excluded. Without an explicit item segment, future-opening items remain excluded.

The source item of a related-products scenario can be historical or ended: it is the reference item, not the offer being delivered. Historical evaluation retains its own chronological availability rules.

Preparing a recommendation is not permission to activate an offer early. Schedule delivery using the catalog's opening dates and recheck current availability.

For non-overlapping campaign audiences, continue with [Build and allocate audiences](/intelligence/product-recommendations/audiences-and-allocation.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.dinmo.io/intelligence/product-recommendations/recommendation-use-cases.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.