Translation table data sources
The following diagrams show different scenarios that you can consider when determining how to populate the translation table. A translation table is required to coordinate the transfer of data between IBM Digital Analytics and Unica Campaign.
A translation table contains one column for the IBM Digital Analytics registrationID and another column for the Unica Campaign audience identifier (such as CustomerID or AccountID). This mechanism matches IDs from one data source to another.
A typical integration can have access to both online (SaaS) and on-premise data sources:
- Web data is available in a web datamart, which contains information from web channel interfaces.
- Data can be exported from the SaaS IBM Digital Analytics solutions, using IBM Digital Analytics Export (registrationid) and Livemail (for other web-related data).
- Customer data sources, such as databases or flat files (on-premise).
The following illustration shows how data sources feed into a translation table. The translation table associates records across the products, using the IBM Digital Analytics registrationID and the Unica Campaign audience ID (CustomerID in this example).
The following examples show different scenarios that you can consider when determining how to populate the translation table. These scenarios provide examples of how to use data matching to identify records that correspond to the same entities across multiple databases.
Scenario 1: Same key in Web data and Unica Campaign
In Scenario 1, the Web data and customer data both contain the same key, RegistrationID. You can match on the RegistrationID to identify corresponding records.
Scenario 2: Different keys in Web data and Unica Campaign, one binding unique key
In Scenario 2, the Web data uses RegistrationID as its key, and the customer data uses an audience identifier (CustomerID). The email address is used to bind the keys.
Scenario 3: Different keys in Web data and Unica Campaign, multiple binding unique keys
- Scenario 3a: Multiple binding unique keys in one table
- Scenario 3b: Multiple binding unique keys in multiple tables
- Scenario 3c: Multiple binding unique keys in multiple databases (not depicted)
The following example shows Scenario 3a, Multiple binding unique keys in one table. In this scenario, the Web data uses RegistrationID as its key, and the customer data uses an audience identifier (CustomerID). The email address plus additional unique identifying data fields (Customerdata1, Customerdata2) are used to bind the keys.
The following example shows Scenario 3b, Multiple binding unique keys in multiple tables. In this scenario, the Web data uses RegistrationID as its key, and a view is used to present data from multiple dimension tables. The combined view uses the audience identifier (CustomerID) as its key. The email address and several unique identifying data fields are used to bind the keys. As with all the examples, the translation table then uses the RegistrationID and CustomerID to identify individual records.
Segment data is captured using API calls
The following illustration shows how a translation table maps selections between Unica Campaign and Digital Analytics. The IBM Digital Analytics segment data and related information are captured using API calls, for use in Unica Campaign flowcharts.
