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

A profile is the customer record in ResultFly.

Identifiers are the external keys and contact values that help ResultFly recognize that record when new data arrives from different systems.

For example, the same profile may be recognized by a loyalty ID from one system, an email from a website flow, a phone number from a form, or a device key from an app. Identity resolution decides whether those incoming identifiers should point to an existing profile or create a new one.

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

Conflicts, Quarantine, and Merge Review

Identity resolution is not always a straight line. Real customer data often contains partial, old, duplicated, or conflicting signals.

For example:

• an email identifier may already belong to one profile while a phone identifier points to another
• a trusted external customer ID may point to one profile while a contact value points somewhere else
• a customer may use several devices, so DEVICE_KEY values may change or multiply over time

These cases are natural for a CDP. They do not automatically mean that the data is broken or that the UI is wrong.

ResultFly does not use blind auto-merge for similar-looking profiles. When identifiers conflict, the platform follows explicit identity rules:

• if the signals point safely to one canonical profile, ResultFly can continue with that profile
• if there is an authoritative winner, such as a trusted EXTERNAL identifier, ResultFly can keep using that profile while leaving the conflicting signal for review
• if there is no safe winner, the incoming item can be quarantined as an identity conflict instead of changing profiles automatically
• DEVICE_KEY disagreement alone is treated as a weak signal and should not force a hard profile conflict by itself

Quarantine and merge review are safety mechanisms. They keep risky data out of automatic profile mutation until the conflict can be inspected or resolved according to the CDP policy.

This is important for business quality:

• it prevents incorrect profile merges
• it protects customer trust by reducing the risk of sending the wrong message to the wrong person
• it keeps analytics, segments, and downstream decisions from being distorted by mixed customer data
• it preserves confidence in the CDP as the shared customer-data layer

In practice, it is better to pause a suspicious match and check it than to merge profiles too aggressively and damage data quality.

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

For integration payload shape, ingest authentication, and current identity fields accepted by the API, use the developer and API references.

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