> 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/prepare-data.md). # Prepare your data Event Propensity Scoring needs identifiable, timestamped, partitioned event history with enough positive and negative examples to evaluate the requested target. ## Technical prerequisites * Event Propensity Scoring enabled in the workspace. * A source supported by the intelligence, with the User model and every Event model on the **same connection**. * Read access to the input models and permission to create or update scoring outputs. Check the [source setup requirements](/integrations/data-sources.md) using the credentials configured in DinMo. * Raw Event models with usable physical partition metadata, stable [primary keys](/models/primary-keys.md), and a one-to-many (`HAS_MANY`) relationship from the selected User model. Do not substitute pre-aggregated profile totals for raw events: DinMo needs event times to reconstruct what was known at historical observation dates. ## Required models and mappings | Model | Requirement | Purpose | | ---------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------ | | User | Required | Current population to score and optional fields to copy for activation. | | Behavioral Event | One stream required in generic mode; optional in subscription mode | Usage, navigation, purchases, communications, or other tracked behavior. | | Lifecycle Event | Required in subscription mode | Subscription state, movements, terms, and target labels. | Use the same stable profile key across these models. The current User model does not restrict the historical subjects used for training. Every Event stream needs: | Mapping | Requirement | | -------------------------------- | --------------------------------------------------------------------------------------------------- | | Event ID | Stable, non-null identity for deterministic deduplication. | | Profile ID | Key linked to the User model. | | Event timestamp | Business occurrence time, not ingestion time. | | Event name | Categorical field identifying the business event. | | Partition column and granularity | Physical partition field with hour, day, or month granularity. It can be the event timestamp field. | ## Subscription lifecycle data Subscription mode also needs a stable Subscription ID and mappings for `subscription_started`, `cancellation_requested`, and `subscription_ended`. Source event names can differ: map their values or rules to these canonical movements. Retain all earlier lifecycle history, including previous cycles and reversals, so each subscription's state can be reconstructed. Scoring is at `(profile_id, subscription_id)` grain: one person can have several scored subscriptions. Optional subscription attributes include offer family, effective price, commitment end, billing frequency, and channel. These must be historized. Do not copy today's price, offer, or cancellation status onto earlier events if it was not known then. ## Select meaningful model inputs You choose which compatible Event fields DinMo may use. Useful inputs include device, content category, channel, quantity, duration, engagement value, and historized subscription terms. Do not select free text, opaque IDs, join keys, or values that reveal the future target. Structural mappings are already part of the event contract and do not need to be selected again. User fields copied into outputs are activation data, not a substitute for historical Event inputs. | Input | Guidance and limit | | ----------------------- | ------------------------------------------------------------------------------------------------- | | Behavioral event names | Around 10 recommended; at most 50 selected values per stream. | | Lifecycle movements | At most 10 canonical movements. | | Additional model inputs | 10 or fewer recommended; at most 30 per stream. | | Categorical values | Keep meaningful categories below 50; sparse or high-cardinality fields can fail readiness checks. | ## Eligibility and minimum data requirements These requirements determine whether training can proceed, not whether the model will deliver useful business lift. | Blocking requirement | Minimum | | --------------------------- | -------------------------------------------------------------------------------------- | | Prediction horizon | 3 to 90 days. | | Common stable history | At least six times the horizon. | | Usable event values | At least 2. | | Positive subjects | At least 100 in **each** training and evaluation period. | | Negative subjects | At least 100 in **each** training and evaluation period. | | Event integrity | Stable identities, valid business timestamps, and deterministic deduplication. | | Source continuity | No unexplained gaps in the period declared complete. | | Event-table partitioning | Valid physical partition column and granularity; required for production execution. | | Subscription reconstruction | Subscription identity and required lifecycle movements available in subscription mode. | A positive subject performs the target within the future horizon; a negative subject does not. Missing partitioning blocks production execution. Recommended levels are at least **5 usable event values**, **500 deduplicated target episodes**, and **1,000 historical subjects**. Falling below a recommendation produces a warning rather than blocking training. ### History required by horizon | Horizon | Minimum common stable history | | ------: | ----------------------------: | | 7 days | 42 days | | 14 days | 84 days | | 30 days | 180 days | | 60 days | 360 days | | 90 days | 540 days | With multiple streams, history is measured over their common reliable period. Earlier lifecycle events still describe previous cycles, but do not extend that common period when behavioral data is unavailable. The target need not occur every day if tracking is continuous and every period has sufficient class counts. ## Check before training Check key consistency, duplicates, time zones, source freshness, partition continuity, and any changes in event meaning. Declare when each source became complete: missing history must not be interpreted as inactivity. Exclude future-dated events and incorrectly historized inputs. Next: [Configure and refresh](/intelligence/event-propensity/configure-and-train.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/event-propensity/prepare-data.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.