Gigya’s integration with Responsys combines Gigya's rich, permission-based social and other profile info with Responsys relationship-based marketing.
The integration synchronizes user data between Gigya and Responsys on a recurring basis (daily) or ad-hoc, including:
- Creating and updating users in Responsys based on information from Gigya.
- Updating user data in Gigya based on information from Responsys.
- Extracting segments using filter criteria.
The integration uses IdentitySync, Gigya's ETL platform. Each direction of data transfer (from Gigya into Responsys, or from Responsys into Gigya) requires extracting data from the source platform, saving it as a file in a middle platform (such as SFTP, S3 or Azure Blob), and extracting the file from there into the target platform. This means that on Gigya's side, you should set up an outbound job that reads Gigya data and saves it to SFTP, and an inbound job that extracts a file from SFTP and writes the data to Gigya. In addition, you should set up the parallel data extract and file import jobs on Responsys.
In this guide, we will refer to SFTP as the example, but it could mean Amazon S3 or Azure Blob for your implementation.
The following diagram shows the information flow. The flows with dotted lines mean that this is configured outside of Gigya.
Additional points to consider:
- On the ESP, you should create a custom "Gigya UID" field, and sync Gigya's UID to that field. Gigya's UID should be used as the identifier to support the use case of a user changing their email address. When the UID is used rather than the email, that user will remain identified by the system after the change.
- Whether you are using a simple Gigya data field for describing the user's subscription status, or Communication Preferences, you should update the relevant subscription status (opt in or out) on the target platform.
Gigya supports transmitting files in compressed format.
By default files are not compressed, but you can configure gzip or LZO compression.