Customer.io
Fidero delivers your events and user profiles to Customer.io from the server, resolved to one person across anonymous and signed-in activity, so lifecycle and win-back flows trigger on complete behaviour.
| Channel | Server |
| Consent category | analytics |
| Deduplication | No event ID – Customer.io keys on your user ID, or the anonymous ID before sign-in, so events and traits land on one person. |
| Identifiers | The user ID and anonymous ID, and profile traits – email, phone and name – sent to Customer.io as-is, unhashed. |
What it delivers
- Server-side events. Product and conversion events are delivered from the server with their standard Fidero names, so your Customer.io flows trigger on the same events across the funnel
- User profiles. Traits – email, phone, name and your custom attributes – are written to the person's Customer.io profile
- Event properties intact. Every property on the event is passed through, so your segments and campaigns can trigger on the full detail
What you provide
| Item | Detail |
|---|---|
| Workspace write key | Your Customer.io Data Pipelines write key. |
| Region | Your Customer.io data region, if not the default US. |
That's everything. Mapping, formatting, hashing and deduplication are already built in – you switch the destination on by requesting it, and the flow is on the Destinations overview.
What's automatic
- Identity resolution. Events and profiles resolve to one person – your user ID, or the anonymous ID before sign-in – unifying activity across states
- Trait mapping. Standard traits are written as Customer.io attributes, and a
createdAttrait is converted to the Unix timestamp Customer.io expects - Erasure forwarding. When a visitor is deleted, Fidero sends Customer.io a deletion event so your erasure workflow can remove them
Enrichment, consent enforcement, delivery monitoring and managed adapter updates apply to every third-party destination – what every destination receives covers the standard treatment.