Event Ingestion
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:
- authenticate the sender
- resolve the customer profile
- deduplicate retries
- validate the event contract
- 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 that defines:
- which properties are allowed
- which properties are required
- property data types
- which properties can be used in segments
- which properties can feed derived attributes
This keeps the CDP usable for marketers. If event structures drift without a contract, segments and exports quickly become unreliable.
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: