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, [email protected].
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.

Profile Resolution concepts

These terms are specific to Profile Resolution, the capability that resolves duplicate profile-like records into canonical customer profiles.

Term	Definition
dinmo_id	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, golden fields, outputs, and schedule. See also DinMo's article on the identity graph concept.
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	One row per resolved dinmo_id with chosen winning values per field. The warehouse representation of a single customer view.
Survivorship rule	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, 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.
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.

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 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.

Does DinMo do probabilistic identity matching?

No. DinMo uses deterministic matching for both capabilities. Profile Resolution adds anchored fuzzy matching 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 walks through which one fits your current use case.