> 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/event-propensity/limits-and-best-practices.md).

# Use results and best practices

Turn Event Propensity scores into a controlled business policy. A score helps prioritize subjects; it does not decide the best treatment or prove that treatment will work.

## Eligibility and minimum data requirements

Check the [data requirements and readiness thresholds](/intelligence/event-propensity/prepare-data.md#eligibility-and-minimum-data-requirements) before training. A warning can allow training to proceed, but performance still needs review before activation.

### History required by horizon

Choose a horizon that leaves time to act and meets the [minimum common-history requirement](/intelligence/event-propensity/prepare-data.md#history-required-by-horizon). Earlier subscription history helps reconstruct past cycles; it does not replace missing behavioral coverage in the common reliable period.

## Choose an actionable target

Use the earliest reliable event that represents the outcome you want to influence. For subscription retention, a well-tracked `cancellation_requested` event can be more useful than `subscription_ended`: the effective end may occur after the customer's decision.

Keep end movements to reconstruct lifecycle state and evaluate outcomes. Select eligible subscription states that fit the policy, rather than prioritizing subscriptions already pending cancellation for an early-warning campaign.

A short horizon is more responsive but leaves less preparation time. A longer one requires more history and can weaken the signal. Do not choose a horizon only because it produces the best offline metric.

## Preserve history and avoid leakage

Keep stable event names, the business occurrence time, and complete earlier subscription movements. Declare when each source became reliable; missing events must not be interpreted as inactivity.

| Leakage risk                                         | Safer approach                                         |
| ---------------------------------------------------- | ------------------------------------------------------ |
| Current cancellation status copied to past events    | Reconstruct status from timestamped lifecycle events.  |
| Effective end date populated only after cancellation | Use it only from the date it became known.             |
| Post-event support reason or refund code             | Exclude it unless available before the scoring cutoff. |
| Today's offer or price applied to every past event   | Use the historized value known at each cutoff.         |

Temporal evaluation cannot repair incorrectly historized inputs. Exclude identifiers, free text, and operational fields without durable business meaning.

## Activate scores safely

1. Check the latest scoring batch, cutoff, prediction window, coverage, and [score semantics](/intelligence/event-propensity/understand-scores-and-reasons.md#read-the-score).
2. Restrict recipients using current consent, contactability, business eligibility, and contact policy.
3. Use a calibrated probability for an absolute risk threshold, or rank eligible subjects for a capacity-limited campaign. A frozen reference percentile does not guarantee an exact current audience size.
4. Combine the score with business value and relevant signed reasons. A decreasing-score reason is a mitigating factor, not a risk driver.
5. For subscription-grain outputs, account for several subscriptions belonging to one profile when managing contact frequency.

The current population is scored in full. Large history or input scopes can still require narrowing to fit processing limits; there is no universal source-row maximum that guarantees a run will fit.

## Measure the effect of the action

Compare with a simple business-rule baseline before scaling. Use a small set of treatment variants and a randomized control group receiving the existing treatment or no additional treatment.

Log the score, reason, offer, channel, timing, delivery, and outcome. Measure incremental retention or conversion, not response rate alone. Do not automatically give the largest incentive to every high-risk subject: some would stay without it, while others would leave regardless.

A probability is an estimate, not certainty for an individual. Reasons are not causal evidence, and the model cannot recover signals absent from its inputs.

## Monitor and retrain

Monitor source freshness and taxonomy, score distribution, calibration, lift, reason coverage, and results across important business groups. New offers, channels, or behaviors can make the model less representative.

Retrain after material changes to the business, historical inputs, target, horizon, or mappings. Changing the scoring population alone does not require retraining. See [Configure and refresh](/intelligence/event-propensity/configure-and-train.md#retraining-and-configuration-changes).


---

# 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/event-propensity/limits-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.