> 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/use-results-and-best-practices.md).

# Use results and best practices

Recommendation outputs are warehouse tables exposed through associated DinMo models. Use them for segmentation, activation, and analysis, while checking what each row represents.

## Identify each recommendation

| Scenario                    | Source identity          | Recommended identity          |
| --------------------------- | ------------------------ | ----------------------------- |
| Products for a user         | `user_unique_id`         | `recommended_item_id`         |
| Related products            | `item_id`                | `recommended_item_id`         |
| Users for a product         | `item_id`                | `recommended_user_unique_id`  |
| Vendor/category preferences | `user_unique_id`         | `recommended_attribute_value` |
| Users for a vendor/category | `source_attribute_value` | `recommended_user_unique_id`  |

Attribute outputs also identify the attribute role and field. The `primary_key` identifies a recommendation row; it is not the customer identifier.

A top-K table has up to K rows per source, with ranks starting at 1. An allocation table has one row per assigned user, with `ranking = 1`; this marks the assignment, not necessarily the user's unconstrained favorite.

## Interpret scores and evidence

| Field                                  | Meaning                                                                                                                                                                                                        |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `decision_score`                       | The score used for ranking or allocation. Not a probability, expected revenue, or uplift estimate.                                                                                                             |
| `score_semantics`                      | How to interpret the score. Standard ranking scores are relative to a source's candidate universe; allocation pair scores use the full scored universe. Do not compare scores across unrelated runs or scopes. |
| `attribute_score`                      | Attribute-level evidence when available; can be absent.                                                                                                                                                        |
| `vendor_affinity`, `category_affinity` | Attribute affinity labels: unavailable, weak, medium, or strong.                                                                                                                                               |
| `evidence_level`                       | Supported, limited, or general-only evidence. These are evidence-volume indicators, not statistical confidence bands.                                                                                          |
| `is_coverage_fill`                     | Whether the row completes coverage using general demand.                                                                                                                                                       |
| `primary_reason`                       | The main reason associated with the recommendation.                                                                                                                                                            |
| `decision_at`, `valid_until`           | The decision time and, when known, its exclusive expiry. Do not activate a row at or after its expiry.                                                                                                         |

Check score semantics on each output, including rankings accompanying an allocation. There is no universal score threshold that means a user is likely to buy. A missing expiry is not a guarantee of indefinite validity.

## Activate the right population

1. Confirm the expected table was published by the intended run. A withheld publication can leave the previous successful table in place.
2. Join user IDs to the customer model and item IDs to the catalog when contact details, images, prices, or URLs are needed.
3. Recheck consent, contactability, campaign exclusions, stock, and current item status.
4. Filter or order by `ranking` for the content slots you intend to deliver. If sending a list, use a destination and mapping that support that format; the source table itself remains one row per recommendation.
5. Coordinate recommendation refresh with [activation scheduling](/activations/sync-scheduling.md). Preparing future offers does not make them available to send immediately.

For allocated campaigns, use the assignment table as the audience. Join its user IDs to the companion ranking when only those recipients should receive additional recommendations.

## Keep computation focused

Use meaningful commercial segments for both sources and candidates. A small candidate catalog can still mean substantial work when scored against millions of users. Reducing K reduces output size, but does not necessarily reduce the number of pairs scored.

Start with a representative audience and realistic candidates, inspect elapsed time and delivery diagnostics, then expand. For a campaign that needs both assignment and ranking, use the [combined allocation scenario](/intelligence/product-recommendations/audiences-and-allocation.md#assignment-and-ranking-from-one-calculation) instead of running two independent scorings.

If coverage is low, check excluded sources, eligible candidate counts, seen-item rules, and evidence before increasing K. If many results are general-only, check repeated-user history and identifier consistency before treating the issue as a ranking problem.


---

# 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/use-results-and-best-practices.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.
