> 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/configure-and-refresh.md). # 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 `0` to 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. Each scheduled or manual prediction cycle then waits for a successful full training run whose data cutoff covers that prediction request. Requests covered by the same training can share its resulting model. ### 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 | Choice | What it controls | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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](/intelligence/product-recommendations/audiences-and-allocation.md). | | Refresh schedule | When to recompute and publish this scenario's results. | When you create or manually run a prediction, DinMo places the request in the same queue as scheduled predictions. The prediction waits for a successful full training run whose data cutoff covers the request. A request that arrives after the training cutoff requires another training run. If training fails or is canceled, the dependent prediction cycle ends without publishing results from an older 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. Each scheduled or manual prediction cycle follows a full **TRAIN** then **PREDICT** sequence. Prediction requests covered by the same training cutoff can share the resulting model. Changing the learning objective, population, history, or required model capabilities changes the training configuration. Changes to a prediction's segment, K, or delivery settings do not change that configuration, but the next prediction cycle still waits for a successful training run whose data cutoff covers its request. Give each scenario a schedule aligned with its data and campaign deadlines. Allow time for source updates, full training, 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](/intelligence/product-recommendations/recommendation-use-cases.md#item-availability), then schedule campaign delivery for the appropriate opening time. Next: [Understand performance](/intelligence/product-recommendations/understand-performance.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/configure-and-refresh.md?ask=&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.