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 |
Setup guide
Follow our step-by-step Iterable setup guide to connect Iterable with your destination using Fivetran connectors.
Schema information
Connectors created before August 10, 2023
To zoom, open the ERD in a new window.Connectors 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:
EVENT
EVENT_EXTENSION
USER_HISTORY
USER_UNSUBSCRIBED_CHANNEL_HISTORY
USER_UNSUBSCRIBED_MESSAGE_TYPE_HISTORY
USER_DEVICE_HISTORY
LIST_USER_HISTORY
CAMPAIGN_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.
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.
NOTE: We cannot get a list of all the custom events in a particular project. So, during connector 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
In the setup form, you can set a limit on the historical data you want to sync during historical syncs and initial syncs. This limit applies only to the EVENT
table.