Skip to Content
CDPEvent Ingestion

Event Ingestion

Customer profiles need a way to appear in the CDP and become richer over time.

In ResultFly, that happens through events. Brand systems send business events with customer identifiers, timestamps, and properties. ResultFly uses those events to resolve or create the right profile, preserve what happened, and, where the CDP contract supports it, update profile facts or backend-defined derived attributes.

Event ingestion is how customer data enters the CDP from the brand’s systems.

An incoming event is a business fact about a customer, such as:

  • a purchase was completed
  • a loyalty tier changed
  • a bonus balance adjustment was made
  • a ticket was scanned
  • a cart was abandoned

Why ResultFly Uses Events

Events preserve the story behind customer changes.

Instead of only knowing that a balance equals a number, ResultFly can also know why that value changed and when it happened. This helps with segmentation, audit, support, and export.

What an Ingested Event Contains

Each incoming event includes a stable envelope:

  • a source system
  • an external event ID
  • an event type
  • the event time
  • one or more customer identifiers
  • event properties

ResultFly uses that envelope to:

  1. authenticate the sender
  2. resolve the customer profile
  3. deduplicate retries
  4. validate the event contract
  5. persist the event for downstream CDP features

Event Contracts

ResultFly does not treat event properties as an uncontrolled blob.

Every accepted event type has a governed contract, called an event definition.

ResultFly includes built-in definitions for common platform or business events by default. These are managed by the platform and give teams a ready starting point.

Teams can also create custom event definitions for their own business processes, such as loyalty actions, ticket scans, purchases, service requests, or app-specific behavior. A custom definition describes which payload fields ResultFly should accept and how those fields can be used later.

Custom event definitions are managed in workspace Settings, in Event Registry. The registry shows both built-in definitions and tenant custom definitions.

Each event definition can define properties with metadata such as:

  • property key: the payload field name, such as order_id
  • value type: the expected data type from the registry change policy
  • description: a human-readable explanation of what the property means
  • required: whether the event payload must include this property
  • filterable: whether the property can be used as a segment filter

The filterable flag is especially important. If a property is not marked as filterable, teams should not rely on it for audience rules. This keeps segmentation predictable and prevents accidental filters on fields that were only meant to be stored as event context.

Required properties are stricter because they change the validation contract for incoming events. Required properties can be added while the event definition is still in DRAFT; after that, add optional properties or create a new event/version according to the registry policy.

Custom event properties are not a user-configurable derived-attribute builder in this delivery. Derived attributes are still ResultFly-owned computed facts implemented by the backend. If a custom event property must affect a derived attribute, that requires an approved backend/CDP contract and backend implementation, not only checking a property option in the registry.

This keeps the CDP usable for marketers. If event structures drift without a contract, segments and exports quickly become unreliable.

Event Definition Statuses

Event definitions have lifecycle statuses.

  • DRAFT: editable setup state. Draft definitions are not used for production ingest or segment rules.
  • ACTIVE: usable for new ingest and segment rules. An active definition should not be moved back to DRAFT to add required or breaking properties.
  • DEPRECATED: kept for historical compatibility. It should not be used for new ingest, but it may still be available for compatible segment rules. A deprecated definition should not be moved back to ACTIVE.
  • DISABLED: unavailable for new ingest and new segment rules.

Built-in definitions are read-only in the registry. Custom definition status changes are recorded in registry audit.

Ingest Results

Successful events are stored as ingested customer events. When an event is attached to a profile, it can be inspected from the profile Event Timeline. Workspaces that expose an Ingest Events view can use it to check the stored event payload/properties directly. Sensitive identity or contact fields may be masked in UI views.

Problematic events do not disappear silently. Events that cannot be accepted, resolved, or canonicalized safely appear in Data Issues with the issue reason, status, source, event type, retry information, and payload/identity details that are safe to show in the UI.

Ingestion Is Not the Same as Runtime Variables

Incoming customer events are part of the CDP.

Campaign variables are part of runtime execution.

They can work together, but they solve different problems:

  • event ingestion explains what happened around a customer
  • campaign variables track values used by a specific campaign flow

Typical Sources

  • CRM
  • POS
  • loyalty backend
  • mobile backend
  • e-commerce stack
  • ticketing or service systems

For Developers

ResultFly exposes a server-to-server ingest API with API keys, idempotent retries, and structured payloads.

See:

Last updated on
Channels & ConsentSegments & Attributes