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

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

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.
Merge B2B accounts, contacts, or households	Profile Resolution	Anchor matching on email, domain, or account ID with anchored fuzzy matching 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 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, lifecycle marketing, and next best action — all rooted in your own warehouse.

What to read next

If you decided...	Go to
Profile Resolution first	Profile Resolution → Create your first Profile Resolution project
Event Stitching first	Event Stitching → Event profile graph
Both eventually	Start with one. Add the other once the first is trusted in production.
You need vocabulary first	Identity Resolution concepts

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?

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.