Iterable
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.
Features
| Feature Name | Supported | Notes |
|---|---|---|
| Capture deletes | check | CHANNEL, LIST, MESSAGE_TYPE, and TEMPLATES_HISTORY tables |
| History mode | ||
| Custom data | ||
| Data blocking | check | |
| Column hashing | check | |
| Re-sync | check | |
| API configurable | check | API configuration |
| Priority-first sync | check | EVENT |
| Fivetran data models | check | |
| Private networking | ||
| Authorization via API | check |
Supported deployment models
We support the SaaS Deployment model for the connector.
Setup guide
Follow our step-by-step Iterable setup guide to connect Iterable with your destination using Fivetran connectors.
Schema information
Connections created before August 10, 2023
To zoom, open the ERD in a new window.Connections created after August 10, 2023
To zoom, open the ERD in a new window.Schema notes
The EVENT table contains information of the following events:
- Custom Event
- Email Send
- Email Send Skip
- Email Open
- Email Click
- Email UnSubscribe
- Email Subscribe
- Email Bounce
- Email Complaint
- Hosted Unsubscribe Click
- InApp Send
- InApp Open
- InApp Click
- InApp Close
- InApp Delete
- InApp Delivery
- InApp Send Skip
- Inbox Message Impression
- Inbox Session
- Push Send
- Push Send Skip
- Push Bounce
- Push Open
- Push Uninstall
- Purchase
- SMS Click
- SMS Send
- SMS Send Skip
- SMS Bounce
- SMS Received
- Web Push Click
- Web Push Send
- Web Push Send Skip
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. However, syncing the LIST_USER_HISTORY table may sometimes increase your MAR usage. In such cases, we recommend that you use our Iterable dbt package instead of syncing the LIST_USER_HISTORY table. The Iterable dbt package contains a model to recreate the LIST_USER_HISTORY table on your destination.
Sync strategy
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.
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.
Sync events
You can select the events you want to sync in the EVENT table through the setup form. Make sure you have selected the EVENT table in the schema tab. For Custom Event, if you select Sync Selected Custom Event, then you can choose the custom events you want to sync. The schema settings also affects the selection of events.
In the Schema tab, go to Schema settings and select one of the following settings:
- Allow all - It enables syncing all the new custom events by default. All custom events created before you changed this setting keep their existing sync settings.
- Allow columns - It enables syncing only those events that are manually selected from the list. It does not allow syncing all the new events. All columns created before you changed this setting keep their existing sync settings.
- Block all - It enables syncing only those events that are manually selected from the list. It does not allow syncing all the new events. All events created before you changed this setting keep their existing sync settings.
We cannot get a list of all the custom events in a particular project. So, during conection creation, the custom events observed within the last 1 minute appear in the Custom Event drop-down menu. We collect different custom events throughout the sync and send notifications in the dashboard each time we observe a new event.
Limit historical data sync
You can configure the Historical sync time frame when setting up your connection to speed up both the initial sync and subsequent re-syncs. Historical sync time frame limits the amount of data synced for the EVENT table.
We apply the selected start date only to this table, as it contains data that you are less likely to reference much later.
You can modify the Historical sync time frame at any time. If you change it to an earlier date, we perform a full historical sync, syncing data back to that new date. If you set it to a later date, we do not delete any existing data. Instead, we apply the new time frame only to subsequent re-syncs.