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. 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 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.