> 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/identity-resolution/concepts.md). # Concepts This page is the single glossary for Identity Resolution in DinMo. Profile Resolution and Event Stitching share many concepts, but each capability also has its own specific vocabulary. When in doubt, this page is the source of truth. Other Identity Resolution pages link here instead of re-defining terms. ## Common concepts These terms apply to both Profile Resolution and Event Stitching. | Term | Definition | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identifier | A column that can connect records to the same real-world entity: email, phone, user ID, customer ID, anonymous ID, device ID, account ID, and so on. | | Identifier observation | A standardized identifier value as it appears on one source row. | | Standardization | Rules applied to identifier values before matching, such as trim, lower-case, or removing plus-tags in emails. Also called normalization. | | Blocked value | An identifier value that DinMo will not use for matching, but still records in audit history. Useful for placeholders like `unknown`, `null`, `test@test.com`. | | Anchor identifier | A high-confidence identifier that anchors the identity of a profile and protects it against unsafe merges from weaker identifiers. | | Priority | The order in which DinMo evaluates identifiers. Lower number means stronger and runs first. | | Conflict | A situation where matching would violate a configured guardrail, for example exceeding a maximum number of profiles per identifier value. | | Audit history | Per-run records that explain matching decisions, kept in the warehouse alongside the published outputs. | For more on why identifiers are the foundation of customer data unification, see DinMo's guide to the [identity graph](https://www.dinmo.com/cdp/customer-data/identity-resolution/identity-graph/). ## Profile Resolution concepts These terms are specific to [Profile Resolution](/identity-resolution/profile-resolution.md), the capability that resolves duplicate profile-like records into canonical customer profiles. | Term | Definition | | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`dinmo_id`](/identity-resolution/dinmo-id.md) | The resolved profile ID assigned by DinMo. One real-world customer maps to one `dinmo_id`. | | Identity graph (project) | The full Profile Resolution configuration: source models, identifiers, [matching rules](/identity-resolution/profile-resolution/matching-rules.md), golden fields, outputs, and schedule. See also DinMo's article on the [identity graph concept](https://www.dinmo.com/cdp/customer-data/identity-resolution/identity-graph/). | | Matching rule | One way two records can be linked, composed of one or more criteria combined with AND. Multiple rules are alternatives, combined with OR. | | Criterion | One condition inside a matching rule: an identifier and a match type such as `EXACT` or `FUZZY_STRONG`. | | [Golden record](/identity-resolution/golden-record.md) | One row per resolved `dinmo_id` with chosen winning values per field. The warehouse representation of a [single customer view](https://www.dinmo.com/cdp/customer-data/single-customer-view-scv/). | | [Survivorship rule](/identity-resolution/survivorship-rules.md) | The strategy used to pick the winning value for each golden record field, such as latest non-null or model-priority. | | Unresolved record | A source row excluded from the golden record because it has missing data or because matching would violate a guardrail. | ## Event Stitching concepts These terms are specific to [Event Stitching](/identity-resolution/event-stitching.md), the capability that builds an event profile graph from event records. | Term | Definition | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `dinmo_stitched_profile_id` | The resolved event-profile key produced by Event Stitching. Independent from `dinmo_id`. | | Event profile | A group of events that DinMo can safely connect through configured identifier policies. A profile is counted in product surfaces when it is not merged and holds at least one identifier value still within its temporal window. | | Known profile | An event profile that holds at least one active anchor identifier (typically `user_id`, `email`, `phone`). Known profiles can be joined in the warehouse through identifiers you trust. | | Anonymous profile | An event profile with active identifiers but no active anchor. Anonymous profiles capture behavior across pre-login activity; they cannot be reached through CRM until an anchor identifier is observed. | | Event profile graph | The full structure of event profiles, including their identifier history and merge history. See [Event profile graph](/identity-resolution/event-stitching/event-profile-graph.md). | | Identifier policy | The per-identifier configuration used by Event Stitching: priority, anchor flag, maximum unique values, maximum profiles per value, temporal window, and blocked values. | | Stitching stage | One pass of the matching engine for one priority level. Stronger stages run first and protect the graph against weaker ones. | | Redirect | A record showing that one event profile was merged into another. Use `resolved_dinmo_stitched_profile_id` to follow redirects automatically. | | Demotion | An identifier value kept in audit history but disabled for further matching because using it would create an unsafe merge. | | Conflicted identifier value | An identifier value quarantined because it would have linked too many distinct profiles. Conflicted values become `inactive_demoted` — they remain visible in audit but no longer participate in matching. | | Temporal window | The period during which an identifier value is active for matching, measured from its first event-time observation. Past the window, the value remains in audit history but no longer creates new matches. | | Run window | The bounded `[window_start, window_end)` interval of event timestamps a single Event Stitching run processes. | | Partition manifest | The history of processed run windows for an Event Stitching project. Used to detect overlaps, support idempotent reruns, and drive scheduled continuation. | | Attribution status | The published status of an event in `identity_event_profile_attribution`. Values: `stitched`, `excluded`. | | Identifier status | The published status of an identifier value in `identity_event_profile_identifier_values`. Values: `active`, `inactive_expired`, `inactive_demoted`, `blocked`. | For background on tracking events as the foundation of behavioral analysis, see DinMo's guide to [event tracking](https://www.dinmo.com/cdp/customer-data/event-tracking/). ## How the two capabilities relate | | Profile Resolution | Event Stitching | | -------------------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------- | | Input | Profile-like source models (customers, accounts, contacts, subscribers) | Event source models (purchases, sessions, page views, app events) | | Primary ID | `dinmo_id` | `dinmo_stitched_profile_id` | | Main output | `identity_golden` | Event profile graph and per-event attribution | | Matching style | Exact and anchored fuzzy matching | Deterministic, priority-based stages | | Creates new IDs? | Yes — `dinmo_id` | Yes — `dinmo_stitched_profile_id` (independent from `dinmo_id`) | | Probabilistic matching? | No | No | | Touches the other capability's output? | No | No | You can run them together. DinMo does not auto-link `dinmo_id` and `dinmo_stitched_profile_id` today; the join is done in your warehouse on a shared identifier such as email or user ID. See [Choose your approach](/identity-resolution/choose-your-approach.md) for the use case mapping. ## Frequently asked questions ### Is `dinmo_id` the same as `dinmo_stitched_profile_id`? No. `dinmo_id` is the resolved customer profile ID produced by Profile Resolution, anchored on profile-like records. `dinmo_stitched_profile_id` is the resolved event-profile ID produced by Event Stitching, anchored on event records. They live in independent ID spaces. ### Why two different identity layers? A customer master ID and a behavioral journey ID have different lifecycles. Profile Resolution merges canonical customers when they share strong identifiers. Event Stitching groups events into behavioral profiles using deterministic per-stage policies. Keeping them separate means each layer can be trusted on its own, and you decide when and how to join them. For the underlying graph concept that informs both, see DinMo's guide to the [identity graph](https://www.dinmo.com/cdp/customer-data/identity-resolution/identity-graph/). ### Does DinMo do probabilistic identity matching? No. DinMo uses deterministic matching for both capabilities. Profile Resolution adds anchored [fuzzy matching](/identity-resolution/fuzzy-matching.md) on top of an exact criterion, but it never guesses without explicit evidence. ### What is the difference between an identifier and an anchor? An identifier is any value that can connect records, such as email or device ID. An anchor is an identifier explicitly marked as strong profile evidence. Anchors protect a profile against unsafe merges from weaker identifiers and must be configured with strict limits. ### What does `excluded` mean in Event Stitching outputs? It means the event was processed but not attached to an event profile. The `reason` column explains why: for example `no_matchable_identifier`, `conflicted_identifier_value`, or `limit_conflict`. ### Do I need both Profile Resolution and Event Stitching? Not at first. Most teams start with one capability and add the other once the first is trusted. [Choose your approach](/identity-resolution/choose-your-approach.md) walks through which one fits your current use case. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.dinmo.io/identity-resolution/concepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.