Skip to Content
CDPChannels & Consent

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:

  • EMAIL
  • SMS
  • PUSH
  • TELEGRAM

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.

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?
Identity ResolutionEvent Ingestion