Skip to Content
CDPIdentity Resolution

Identity Resolution

Identity resolution is how ResultFly decides that data from different systems belongs to the same customer profile.

This matters because one person may appear in several places:

  • a loyalty system
  • a mobile app
  • a website
  • a POS system
  • an email-based flow
  • a phone-based flow

The Core Idea

ResultFly separates the profile from the identifiers attached to that profile.

The profile is the person record. Identifiers are the keys ResultFly uses to recognize that person across systems.

In the first CDP delivery, ResultFly works with four canonical identifier types:

  • EXTERNAL
  • EMAIL
  • PHONE
  • DEVICE_KEY

Deterministic Matching

ResultFly uses deterministic matching, not a fuzzy score.

In practice, this means the platform follows a fixed precedence order when several identifiers are available. That keeps behavior explainable, auditable, and consistent between ingest, profile reads, segmentation, and export.

For business users, the important outcome is simple:

  • the same incoming customer should resolve to the same profile every time
  • duplicates are reduced by using explicit identifiers rather than guesswork
  • merge decisions stay traceable

Why This Is Separate from Channels

Email and phone may appear in two different roles:

  1. as identifiers that help match a person
  2. as communication endpoints used for consent and reachability

These are related, but they are not the same concern.

ResultFly treats matching separately from communication state so that:

  • profile merges stay deterministic
  • consent history stays intact
  • channel reachability does not accidentally become a merge rule

Pre-Provisioning and Future Linking

ResultFly can create or resolve a profile before the customer opens a campaign. Later, when another identifier becomes available, that identifier can link to the same profile according to the matching rules.

This is useful when:

  • a loyalty ID arrives before email is known
  • a purchase event arrives before app login happens
  • a mobile device is recognized before a CRM identifier is attached

For Developers

The developer-facing contract covers:

  • accepted identifier types
  • normalization rules
  • deterministic precedence
  • duplicate and conflict behavior
  • API authentication for ingest

See Developers → CDP Integration and API Reference → Event Ingestion.

Customer ProfilesChannels & Consent