Channels & Consent
Customer profiles and customer channels are related, but they are not the same thing.
A profile answers “who is this person?”
A channel answers “where can this person be reached, and what do we know about consent or reachability right now?”
Supported Channel Types
ResultFly stores communication endpoints in a dedicated channel model.
The first CDP delivery supports:
EMAILSMSPUSHTELEGRAM
Each channel belongs to a profile and carries its own state.
What Channel State Includes
A channel can track details such as:
- endpoint value
- whether the endpoint is active
- whether it appears reachable
- verification timestamps where relevant
- current consent status
- change history
This is important because communication readiness changes over time. A profile may stay the same person while their email consent, push token, or phone reachability changes many times.
Why Consent Lives with the Channel
Consent is channel-specific.
For example:
- a customer may allow email but deny SMS
- a push token may rotate without changing the person
- an old endpoint may remain in history even after the active endpoint changes
Keeping consent on the channel model makes it possible to:
- segment by current consent status
- preserve historical changes
- keep exports aligned with the latest reachable endpoints
Profile Contacts vs Channel Records
ResultFly may still display top-level email or phone values on a profile because they are convenient for support and filtering.
But the canonical channel model is what matters for:
- channel presence
- consent
- reachability
- delivery-readiness decisions
Typical Questions the Channel Layer Answers
- Does this profile currently have an active email endpoint?
- Is SMS consent granted or revoked?
- Which push endpoint is current?
- Can this segment be exported with only reachable email contacts?
Practical Rule
Use profile fields to understand who the customer is. Use identifiers to understand how ResultFly recognized the customer. Use channels to decide whether and where communication is allowed.
For example, profile.email may help a user recognize the profile, and identity(type = EMAIL) may help ResultFly match incoming data. But an email audience should use the EMAIL channel state, consent status, and reachability. The same idea applies to SMS, push, and Telegram.
When channel data is missing or consent is unknown, ResultFly should not treat the customer as safely reachable by default. Unknown or incomplete channel state is a normal data-quality signal, not something to hide inside a profile field.
How This Affects Segments and Export
Segments and exports should use channel-aware conditions when communication eligibility matters:
- use channel presence to check that an endpoint exists
- use channel consent status to check whether communication is allowed
- use channel reachability to avoid exporting endpoints that are not currently usable
- use consent history when the question is about how consent changed over time
This keeps customer selection explainable: the segment says not only who belongs to the audience, but also why that audience is safe to contact through a specific channel.