Customer Profiles

A customer profile is the central CDP record ResultFly uses to represent one person.

It is not meant to be a full copy of the brand’s CRM. Instead, it is the ResultFly view of the customer: the set of customer-level facts that can be reused by CDP features such as profile inspection, segmentation, and audience export.

A profile answers “who is this person?” The CDP event timeline answers “what happened with this person over time?” These two parts work together: the profile keeps the current customer-level view, while events preserve the history behind that view.

What a Profile Contains

A profile can store business-relevant customer fields. Current profile views commonly include:

• profile ID
• first, middle, and last name
• gender
• birth date
• city
• loyalty status
• bonus balance
• expiring bonus amount and expiry date
• first seen, last seen, created, and updated timestamps

ResultFly can also show convenient top-level contact values such as email or phone on the profile page. These values are useful for display and simple search, but they are not the full communication model.

For communication readiness, use the channel model. Email and phone can be identifiers, display fields, or communication channels, but those are separate concerns:

• identifiers help ResultFly match incoming data to the right profile
• display fields help users recognize a profile in the interface
• communication channels carry consent, reachability, and channel state

Identifiers

Identifiers are the values ResultFly uses to recognize that incoming data belongs to the same customer profile.

A single person can appear in different systems under different keys. For example, the loyalty system may know a customer by loyalty ID, the website may know an email address, the app may send a device key, and a POS system may send an external customer ID. Identifiers connect those signals to one profile when the matching rules allow it.

Current CDP identity resolution uses these canonical identifier types:

• EXTERNAL: a stable customer or user ID from an upstream system
• EMAIL: an email value used for matching
• PHONE: a phone value used for matching
• DEVICE_KEY: a device-bound value used for matching

On the profile page, the Identifiers section helps explain why events and customer facts are attached to this profile. It can show which identifiers are linked to the profile and when they were seen.

An identifier is not the same thing as a communication channel. For example, an email identifier may help ResultFly recognize a person, but email consent and reachability still come from communication channels.

It is also normal for one profile to show several identifiers of the same type. For example, a profile may have two phone identifiers if different systems sent different phone values, formatting changed over time, or the customer used more than one phone. The same applies to DEVICE_KEY: one customer may use several devices, reinstall an app, clear browser storage, or appear through another device-bound context. This is not a bug by itself. It means the CDP has more than one explicit signal attached to the same profile; communication eligibility still depends on the channel and consent records.

Why Profiles Matter

Profiles give teams one customer-level view across many incoming systems.

That helps with:

• seeing a customer’s current status before using that customer in an audience
• building audiences from profile facts and behavior together
• inspecting customer data without reading raw event payloads from several systems
• exporting audiences based on the latest customer view

Profile Page

The profile page is the main place to inspect one customer in the CDP.

It includes a core profile card with customer fields such as name, city, loyalty status, balances, display email, display phone, and timestamps.

It also exposes profile-level sections for:

• Identifiers: external IDs, email identifiers, phone identifiers, and device keys linked to the profile
• Communication Channels: channel records used for consent, reachability, and delivery readiness
• Consent History: how consent changed over time
• Derived Attributes: backend-computed customer facts currently returned for the profile
• Event Timeline: successful ingested events attached to this profile, with event payload details
• Profile History / Activity Log: profile and audit history returned by the CDP backend

These sections are intentionally separate. For example, display email on the core profile card is not the same thing as an email identifier or an email communication channel.

Profiles Can Exist Before a Campaign Visit

ResultFly does not require the customer to open a campaign first.

A profile may appear because:

• a backend system sent a CDP event for that person
• an ingested event contained identifiers that resolved to a new or existing profile
• later events added more identifiers or updated profile-level facts

This makes it possible to prepare customer-level facts such as balances or loyalty status before the customer ever opens a ResultFly experience.

Profile vs Campaign Variables

Profiles belong to the CDP. They describe the customer and connect to identifiers, communication channels, event history, derived attributes, segments, and exports.

Campaign variables belong to campaign runtime execution. They describe state that a campaign flow needs while it runs for a participant.

Examples:

• “Loyalty status is Gold” belongs on the profile.
• “The customer has an email channel with consent granted” belongs in communication channels.
• “The customer completed a purchase yesterday” belongs in CDP event history.
• “The customer has 2 attempts left in this campaign” belongs in campaign variables.
• “The customer has completed step 3 of this campaign flow” belongs in campaign variables.

This separation matters even when a runtime variable uses a broad scope such as state.user_global.*. It is still runtime state, not the canonical customer profile.

Use the profile or another CDP entity when a value must be reused for customer understanding, segmentation, audience export, or cross-campaign business decisions.

Use campaign variables when a value controls campaign mechanics, counters, limits, branching, or progress inside a specific ResultFly experience.

If a campaign interaction creates a durable customer fact, model it as a CDP event through the governed ingest path. Where the CDP contract and backend implementation support it, that event can update profile facts or backend-defined derived attributes. Do not use a runtime variable as a substitute for canonical customer data.