> 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/choose-your-approach.md). # Choose your project type DinMo Identity Resolution covers two capabilities. Pick the one that matches your use case — you can add the other later. ## [Profile Resolution](/identity-resolution/profile-resolution.md) Detect and merge duplicate customer records across different source models, using rule-based matching. Use it when your CRM, e-commerce, or app tables describe the same people. ## [Event Stitching](/identity-resolution/event-stitching.md) Stitch anonymous and identified activity into a single customer journey, using graph-based matching. Use it when you need to connect pre-login behavior to logged-in events. ## Pick by use case | You want to... | Use | Why | | ------------------------------------------------------------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | Build a one-row-per-customer table for your data team and CRM | Profile Resolution | Resolves duplicate records, picks winning values, gives you `dinmo_id` as a stable join key. | | Detect duplicate customer records pre-activation | Profile Resolution | See [How customer deduplication works](/identity-resolution/customer-deduplication.md). | | Merge B2B accounts, contacts, or households | Profile Resolution | Anchor matching on email, domain, or account ID with anchored [fuzzy matching](/identity-resolution/fuzzy-matching.md) when needed. | | Analyze a user journey across anonymous and identified events | Event Stitching | Connects events through identifier observations without needing a master profile first. | | De-anonymize visitors after they log in | Event Stitching | The event profile graph naturally connects pre-login and post-login activity through shared identifiers. | ## Pick by data you have | You have... | Use | | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Customer, account, contact, or subscriber tables with stable primary keys | Profile Resolution | | Event, session, activity, or interaction tables with identifier columns | Event Stitching | | Both | Both — configured as two separate projects, joined in the warehouse on a shared identifier. | | Neither (raw or semi-structured data) | Model the data first into either profile-like or event-like tables, then come back to this page. | ## Side-by-side | | Profile Resolution | Event Stitching | | -------------------------------------- | ------------------------------------------------ | --------------------------------------------------------------- | | Input | Profile-like source models | Event source models | | Primary ID | `dinmo_id` | `dinmo_stitched_profile_id` | | Main output | `identity_golden`, one row per resolved customer | 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`) | | Changes existing IDs | Profiles can merge across runs | Event profiles can merge with redirect history | | Idempotent on rerun | Yes | Yes | | Probabilistic? | No (anchored fuzzy stays conservative) | No (fully deterministic) | | Touches the other capability's outputs | No | No | | Best for | Single source of truth per customer | Behavioral analysis across anonymous and known activity | ## When to use both The most common pattern in production: 1. **Run Profile Resolution on your customer-like tables.** You get `dinmo_id` and a [golden record](/identity-resolution/golden-record.md) per resolved customer. 2. **Run Event Stitching on your event tables.** You get `dinmo_stitched_profile_id` and per-event attribution into a separate event profile graph. 3. **Join them in your warehouse when you need attribution.** Use `identity_event_profile_identifier_values` to surface the identifiers on an event profile, then join those identifiers to `identity_matched_ids` to land on the `dinmo_id`. DinMo does not auto-link `dinmo_id` and `dinmo_stitched_profile_id` today. The two ID spaces stay independent so each capability can be trusted on its own. You define the join on identifiers whose data quality you control, and you decide whether a join row is strong enough to act on. Once you adopt both, you have a foundation for use cases like [hyper-personalisation](https://www.dinmo.com/cdp/customer-data/hyper-personalisation/), [lifecycle marketing](https://www.dinmo.com/data-activation/use-cases/lifecycle-marketing/), and [next best action](https://www.dinmo.com/data-activation/artificial-intelligence/next-best-action/) — all rooted in your own warehouse. ## What to read next | If you decided... | Go to | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Profile Resolution first | [Profile Resolution](/identity-resolution/profile-resolution.md) → [Create your first Profile Resolution project](/identity-resolution/profile-resolution/get-started.md) | | Event Stitching first | [Event Stitching](/identity-resolution/event-stitching.md) → [Event profile graph](/identity-resolution/event-stitching/event-profile-graph.md) | | Both eventually | Start with one. Add the other once the first is trusted in production. | | You need vocabulary first | [Identity Resolution concepts](/identity-resolution/concepts.md) | ## Frequently asked questions ### Should I always run Profile Resolution before Event Stitching? No. They are independent. Run Profile Resolution when you need a canonical customer master. Run Event Stitching when you need a behavioral journey graph. Many teams run Event Stitching first because their first business question is about behavior, not about a master ID. ### Can Event Stitching replace Profile Resolution? No. Event Stitching produces `dinmo_stitched_profile_id`, which is a behavioral grouping key. It is not designed to be a customer master ID for activation, CRM joins, or analytics that need one canonical row per customer. ### Can Profile Resolution replace Event Stitching? No. Profile Resolution does not process event-level grain. It works on profile-like records with stable primary keys. ### How do I join Profile Resolution and Event Stitching outputs? Today, the join is yours to define in the warehouse, on a shared identifier such as email or user ID. DinMo intentionally keeps the two ID spaces independent so each can be trusted on its own, and so you can choose which identifier you trust for the join. ### Is this the same as an [identity graph](https://www.dinmo.com/cdp/customer-data/identity-resolution/identity-graph/)? Profile Resolution implements an identity graph at the customer-profile grain. Event Stitching builds a separate graph at the event-profile grain. They share the underlying concept — linking records through identifiers — but they operate on different inputs and produce different outputs. --- # 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/choose-your-approach.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.