Configure and refresh
Configure the intelligence once, then create recommendation scenarios with their own business rules and refresh schedules. The interface calls these scenarios predictions.
Configure the intelligence
Select the prepared user, item, and interaction models. Map IDs, event timestamps and types, optional strength, vendor or category, and lifecycle fields as applicable.
Choose the Learning objective independently from prediction audiences and delivery settings. Every prediction that reuses the trained model shares this objective.
Configure the learning population and history
Under Learning population and history, choose the Priority learning population:
All users keeps every eligible user.
One or more user segments always retains users in any selected segment within the configured history and volume limits. Additional users outside those segments can still contribute learning signal.
Use Advanced volume limits when needed:
Interaction history (days): use only interactions from this period before training. Leave it empty to retain all available history.
Minimum interactions per additional user: require additional users to have enough interactions. The default is 2.
Maximum interactions per user: retain each user's most recent interactions. Leave it empty to retain all of them.
Maximum additional users: retain the most active users outside the priority population. Set it to
0to use only the selected population. Leave it empty to apply no additional-user limit.
Select Save and schedule training to request a training run. You can train the intelligence before creating any prediction. Creating or changing a prediction does not change these learning settings, and existing compatible models remain available while a new training run is processed.
Measure quality on recommendable products only
Enable Measure quality on recommendable products only? and select a segment on the product model when only part of the catalogue can actually be recommended.
Offline quality metrics then consider only products in that segment that existed at each historical cutoff. User observations whose objective events all concern products outside the segment are excluded from the evaluation.
This setting changes how training quality is measured, not what the intelligence learns or which candidates a prediction can deliver. Each prediction configuration retains its own candidate scope. Changing the evaluation scope requires a new training run.
Configure each scenario
Recommendation use case and grain
Whether results are users, individual items, vendors, or categories.
Source scope
Who or what receives a recommendation.
Candidate scope
The items, users, or attribute values allowed in the result.
Objective event and horizon
The behavior and time window the scenario targets; not a promised conversion or a campaign send date.
Top K
The maximum number of results per source in the ranking.
Previously seen items
Whether previous interactions should exclude a candidate. Allow repeats when repeat purchases or contributions are meaningful.
Completion and coverage
Whether to deliver evidence-backed results only or fill missing positions, and the minimum delivery expected.
Audience allocation
Optional unique-customer assignment and target distribution. See audience allocation.
Refresh schedule
When to recompute and publish this scenario's results.
When you create a prediction, DinMo reuses an available compatible model. If no compatible model exists, the prediction waits for training instead of using an incompatible model.
Balance coverage and evidence
Evidence-only delivery can return fewer than K results. Filling with best available candidates can improve coverage when personalized evidence is sparse. Such rows are identified as coverage fill; they should not be presented as equally personalized recommendations.
Filling does not bypass candidate segments, availability, seen-item exclusions, or item self-exclusion. If the eligible universe is too small, increasing K or allowing fill cannot create more eligible candidates.
The delivery policy determines whether unmet requirements allow a partial publication or withhold it. A technically successful run is not enough to establish that a fresh, usable table was published.
Training and refresh schedules
Training learns from the configured learning population and interaction history. Running a recommendation scenario reuses a compatible trained model to score its requested scope and publish results.
Changing the learning objective, population, history, or required model capabilities requests a new training run. Changes to a prediction's segment, K, or delivery settings do not change the learning configuration and do not require retraining when a compatible model is available.
Give each scenario a schedule aligned with its data and campaign deadlines. Allow time for source updates, training when needed, recommendation generation, and the downstream activation sync. An activation schedule alone does not refresh recommendations.
For tomorrow's offers, use an explicit item segment and the actual preparation time. Follow the availability rules, then schedule campaign delivery for the appropriate opening time.
Next: Understand performance.
Last updated