Identity resolution for startups: connect web, app, CRM and billing correctly

Last updated: 1 October 2026.

Start with the decision the identity map must support

Identity resolution determines which identifiers and records refer to the same entity. For a startup, the useful outcome might be measuring activation across web and mobile, stopping acquisition emails after signup, or connecting product adoption to an account's renewal.

Pick one of those decisions before designing the graph. Write down the required entity, systems and acceptable delay. An account renewal report needs account membership and billing relationships. A personal onboarding message needs the right individual and a permitted destination address. Those are different contracts.

The practical foundation is a durable mapping from source identifiers to your own person and account IDs. Keep the reason for each mapping. A spreadsheet of unexplained pairs will eventually become a production integration nobody trusts.

Do not require a known person for every anonymous visit. Missing evidence is a valid state. Turning every browser into a named customer is an impossible acceptance criterion for a system that respects what its data actually establishes.

Separate people, accounts, devices and contact details

Consider this illustrative B2B SaaS situation. Nadia belongs to two workspaces. Her colleague Omar belongs to one of them. Both workspaces use a finance team's shared billing address. Nadia also visits from a laptop and phone.

The model needs two people, two accounts, membership relationships, browser identifiers and billing records. Matching everything through the shared address would collapse people and businesses that must remain separate.

Use four distinct concepts:

• Person: your durable identifier for an individual using the product.
• Account: the organisation, workspace or subscription owner relevant to the business model.
• Source identifier: a record key within a particular application, tenant and environment.
• Relationship: a person belongs to an account, a billing customer pays for an account, or a session was authenticated as a person.

An account membership is not evidence that two people are identical. An invoice recipient is not necessarily the person using the product. A browser identifier can be shared or replaced. An email address is a contact attribute whose reliability depends on how it was collected and maintained.

Keep relationships explicit. If your product has separate identities within each customer tenant, preserve that separation unless the application actually supports and verifies a global person identity. Cross-tenant consolidation should be a deliberate product decision.

Deterministic and probabilistic matching solve different problems

Deterministic matching applies an explicit rule, such as the same authenticated application ID appearing in two systems. Probabilistic matching estimates whether records belong together using uncertain evidence. A fuzzy string comparison can also be a deterministic rule; a similarity score alone is not a calibrated probability of identity.

For an early-stage product with authenticated users, start with authoritative IDs and explicit application relationships. They give you an explainable foundation without requiring a matching model or an identity vendor.

Exact matching still inherits the quality of its input. Two contacts with finance@example.com match exactly, but may represent different people. A hard-coded unknown value matches thousands of records perfectly and incorrectly. “Deterministic” describes the rule, not a guarantee of truth.

Segment's Unify documentation says its profile matching is deterministic and uses first-party data; it does not support probabilistic matching. Treat that as a description of the mechanism, then assess your own identifier quality. Segment Unify FAQs

Use uncertain matches as candidates for investigation until you have justified the downstream consequences. A suggestion for a data steward and an automatic change to a customer's account require different evidence. Never use a marketing identity graph to grant login access or account permissions.

Collect evidence where your application already knows the relationship

At signup and login

Generate or retrieve the stable application person ID after the backend establishes the user's identity. Record the current session or anonymous identifier alongside it through your approved instrumentation. Include the environment and timestamp so the relationship can be interpreted later.

Do not trust a person ID supplied in an arbitrary browser request as proof of authentication. The server should derive the authenticated identity from its session. A submitted email address establishes what someone typed; verification establishes something more specific about control of that address at that time.

Instrument account creation and membership separately. If the user switches workspaces, the person ID can remain stable while the active account changes.

For the detailed SDK sequence, including logout and shared-device tests, use the identity merge implementation guide. This guide focuses on preserving the mappings across your stack.

When creating or linking a CRM record

Persist the CRM record ID returned by the integration, together with the application ID that initiated the operation. When possible, write a dedicated external application ID into the CRM record as well. Keep a reconciliation job that verifies the two sides agree.

For existing contacts, do not silently create an authoritative link from an email match. Check whether the match is unique, whether the record represents an individual, and whether conflicting application IDs already exist. Put ambiguous cases into a review queue with the evidence attached.

A CRM deduplication or migration can replace a source ID. Preserve the old-to-new record relationship and the reason it changed. Otherwise, your next import may resurrect the duplicate you just removed.

At checkout and billing creation

Connect the billing customer to the correct billable entity. For a team product, that is often the account, while the person who starts checkout is an actor on the transaction.

Stripe Checkout supports client_reference_id for reconciling a session with an internal customer, cart or similar record. Stripe Checkout Session creation

For your implementation, set that reference on the server after checking the user's authority over the relevant account. Persist the returned billing identifiers through the payment lifecycle. Do not infer account ownership from a checkout email or assume that creating a checkout session means payment succeeded.

A guest purchase needs its own order-to-customer policy. Keep the order traceable even when no application person exists yet.

Build a registry you can explain and repair

A raw value such as 42 is not a complete identity. It may be contact 42 in two different CRM portals, a user in staging, or a production workspace. Store the namespace as structured fields.

This is an illustrative record for an approved CRM-to-person mapping:

{
  "environment": "production",
  "source_system": "hubspot",
  "source_account": "portal_88",
  "identity_type": "contact_id",
  "external_id": "42",
  "person_id": "person_nadia",
  "evidence_type": "application_created_contact",
  "evidence_ref": "integration_operation_731",
  "rule_version": "identity_contract_v1",
  "valid_from": "2026-10-01T10:00:00Z",
  "valid_to": null,
  "recorded_at": "2026-10-01T10:00:02Z",
  "status": "approved"
}

The namespace identifies the source record. evidence_ref points to the operation or reviewed evidence that supports the link. valid_from and valid_to describe when the relationship applies. recorded_at says when your system learned it.

That last distinction matters when a late correction arrives. You may need both the answer known when a campaign ran and the best corrected answer today. Decide which interpretation a report uses. Rebuilding old dashboards with today's identity map can legitimately change historical user counts, but that change needs an explanation.

Use separate account and membership mappings. Do not put an account ID into person_id just to make a join succeed. Do not store full contact details or authentication secrets in the evidence reference.

Retain mapping changes as reviewable history within your retention policy. The current approved map should be a controlled output, not whichever row an analyst happened to select last.

Open full diagram

Reject ambiguity before it reaches a campaign

For a source identifier intended to represent one person, there should not be two currently approved person mappings within the same namespace.

This diagnostic query assumes identity_links contains person mappings and uses null valid_to for the current interval. It reports conflicts; it does not choose a winner or repair history.

SELECT
  environment,
  source_system,
  source_account,
  identity_type,
  external_id,
  COUNT(DISTINCT person_id) AS conflicting_people
FROM identity_links
WHERE status = 'approved'
  AND valid_to IS NULL
  AND person_id IS NOT NULL
GROUP BY
  environment,
  source_system,
  source_account,
  identity_type,
  external_id
HAVING COUNT(DISTINCT person_id) > 1;

Check required fields separately, including null or blank namespace fields, and enforce uniqueness of the current mapping in the published map. This query intentionally does not detect duplicate rows pointing to the same person, overlapping historical intervals, or a confidently wrong single mapping. Those need their own checks.

Do not fix conflicts using MIN(person_id), the newest timestamp or a random row. Those operations remove ambiguity from the output while leaving the underlying decision unexplained.

Also test transitive mistakes. If person A shares an email with B, and B shares a device with C, an unrestricted connected-component algorithm can merge all three. A valid graph needs rules about which edges establish identity and which merely describe a relationship.

Check normalisation before choosing the destination key

Segment Unify treats identifiers, including userId, anonymousId and groupId, as case insensitive. Application IDs such as Ab7 and ab7 therefore collide if passed through unchanged as distinct identities. Segment identity resolution overview

Preserve the original source ID. If your application permits case-distinct IDs, create a stable destination-compatible token with a uniqueness constraint and maintain its mapping back to the source. Test collisions under the destination's actual comparison rules. Simply lowercasing the raw ID destroys the distinction you need to preserve.

Apply the same discipline to numeric conversion, leading zeroes and concatenated namespaces. 0012 and 12 may or may not be the same source key. Define that from the source contract rather than spreadsheet behaviour.

Choose where the identity logic should live

Segment Unify

Unify provides a managed identity graph. Its configuration controls identifiers, blocked values, limits and priority when incoming events would connect profiles. Set these rules before connecting production data and test shared-address and shared-device cases. Segment identity onboarding

Distinguish the identity product from event collection. Sending an identify call through your pipeline does not establish that every destination now has the same graph. Segment says it does not sync the identity graph's output to destinations by default; computed traits and audiences use the unified profile through their own delivery behaviour. Segment Engage FAQs

Choose this route when you need managed profile operations and can configure the graph's constraints around your application's identity model. Validate destination behaviour independently.

RudderStack Profiles

RudderStack Profiles builds an identity graph from identifiers available in the warehouse or lake, assigns a canonical rudderId, and computes features on that graph. How RudderStack Profiles works

Evaluate it when warehouse records are central to the identity decision. Ask who maintains the stitching inputs, how you inspect the resulting relationships, and how rebuilds affect downstream keys. A generated canonical ID still needs an operating contract and a recovery process.

Mixpanel

Mixpanel identity management determines how activity belongs to users inside its analytics model. Check the project's ID Merge version before changing instrumentation; populated projects cannot simply switch between Original and Simplified APIs. Mixpanel identity management

In Simplified ID Merge, an event containing both $device_id and $user_id establishes their mapping. Its SDK guidance includes identifying the user, sending a subsequent event and resetting on logout. Mixpanel Simplified ID Merge

Use the product's supported mechanism for analytics, while retaining the source mappings needed for CRM and billing elsewhere. A correct funnel in Mixpanel does not prove that an outbound email integration selects the right contact.

Salesforce Data 360

Data 360 separates matching records from reconciling which field value appears on the unified profile. Its unified link objects retain connections to source records; unification does not alter those source records. Salesforce identity resolution walkthrough

Evaluate this when Data 360 already supports your operational use cases. Specify matching rules, field authority and activation separately. Do not expect a unified profile to perform a destructive merge of duplicate CRM contacts.

Your own warehouse mappings

A startup can begin with explicit application-generated mappings, reviewed exceptions and tested SQL models. This fits a narrow, known identity problem with an owner who can maintain it.

The cost is ongoing responsibility: ingestion, history, ambiguity handling, destination delivery and incident repair. If those requirements grow beyond the team's capacity, evaluate a managed product against the failures you actually need it to prevent.

Measure correctness and coverage separately

Suppose an illustrative audit contains 14 distinct, eligible source identifiers. Nine map unambiguously to three known people, two have conflicting person mappings, and three have no supporting evidence.

Your unambiguous coverage is 9 divided by 14, or 64.3%. Conflict and unresolved rates are 14.3% and 21.4%. The three people are an output of the mapping, not the denominator for coverage. These numbers describe completeness and ambiguity; they do not prove the nine accepted links are correct.

Review a sample of accepted links against their evidence, including the largest clusters and the newest rules. Maintain cases that must stay separate as well as cases that should join. Track findings by source and rule so a high overall match rate cannot hide one broken integration.

For growth teams, also monitor operational consequences: paid accounts entering prospect campaigns, customers receiving duplicate messages, and account activity attributed to the wrong workspace. Connect the identity map to a defined single customer view only after these contracts are clear.

Plan correction before the first bad merge

A correction has several parts: stop the faulty rule, preserve evidence of affected records, repair the mapping, recompute affected models and verify downstream state. Replaying the same bad evidence can reintroduce the problem.

Vendor recovery options differ. Segment now documents a public-beta Delete Profile Identifier API that removes an identifier while retaining traits, events and merge history. Its scope excludes downstream destinations, and archive replays can restore removed identifiers. That is not a universal unmerge operation or a complete deletion workflow. Segment identifier deletion API

For your own registry, support revoking an edge without silently discarding why it existed. For each destination, document whether repair means updating a key, removing an audience membership, rebuilding a model or following a vendor-assisted process.

Begin with a pilot covering one product surface, one CRM and billing. Prove both correct matches and deliberate non-matches before expanding.

If your team cannot trace a customer from product events through CRM and billing, bring those three source schemas and one failed journey to the review. Our data warehouse and CDP work can help establish the mapping contract; product analytics implementation covers the instrumentation and validation that feed it.