Iterable is a growth marketing and customer engagement platform. It enables brands to create, execute and optimize campaigns across email, push, SMS, in-app and more with unparalleled data flexibility.
Featureslink
| Feature Name | Supported | Notes |
|---|---|---|
| Capture deletes | check | LIST, MESSAGE_TYPE, and CHANNEL tables |
| Custom data | ||
| Data blocking | check | Column level |
| Column hashing | check | |
| Re-sync | check | Connector level |
| History | check | |
| API configurable | check | API configuration |
| Priority-first sync | check | EVENT |
| Fivetran data models | check | Get the models: source / transform |
| Private networking |
Setup guidelink
Follow our step-by-step Iterable setup guide to connect Iterable with your destination using Fivetran connectors.
Schema informationlink
This schema applies to all Iterable connectors.
To zoom, open the ERD in a new window.
Schema noteslink
The EVENT table contains information of following events:
- Custom Event
- Email Send
- Email Open
- Email Click
- Email UnSubscribe
- Email Subscribe
- Email Bounce
- Email Complaint
- Hosted Unsubscribe Click
- InApp Open
- InApp Click
- Inbox Message Impression
- Inbox Session
- Push Send
- Push Bounce
- Push Open
- Purchase
- SMS Click
- SMS Send
- SMS Bounce
- SMS Received
- Web Push Send
The LIST_USER_HISTORY table is the only way to join the LIST and USER_HISTORY tables.
Excluding the table from the sync may lead to data discrepancy.
Sync strategylink
We capture events from Iterable using webhooks and the Events API, then write them to the destination.
We use the event data returned by the webhooks for data integrity. The event data from webhooks contains more fields than the data returned by the API. We retain this data for 30 days to be re-synced if needed.
The EVENT table is the main table that contains all the fields we receive from the Events API.
The EVENT_EXTENSION table serves as an extension to the EVENT table. We store any additional fields we receive from the webhooks in the EVENT_EXTENSION table.
We append the newly synced data to the end of a table. We add updates to the table as new rows and don’t update existing rows. The following tables are append-only:
EVENTEVENT_EXTENSIONUSER_HISTORYUSER_UNSUBSCRIBED_CHANNEL_HISTORYUSER_UNSUBSCRIBED_MESSAGE_TYPE_HISTORYUSER_DEVICE_HISTORYLIST_USER_HISTORYCAMPAIGN_METRICS
During syncs, we override the event data returned by the Events API with the event data from the webhooks before writing the data into the destination tables.
When you trigger a re-sync, we first fetch all the historical data from the Events API and then fetch event data from the webhooks for the past 30 days. We then override the event data returned by the Events API of the past 30 days with the event data from the webhooks before writing the data into the destination tables.
NOTE: You may observe a few missing fields in the destination tables because the event data from webhooks contain more fields than the Events API data.
We sync the remaining tables in the schema using non-incremental endpoints, so we re-import them during every sync.