With version 10.0 of IBM Campaign, we saw the introduction of native integration with Watson Campaign Automation. Users are now able to configure and execute process boxes including Email, SMS and App Push instead of configuring their flowcharts to call batch or shell scripts on the file system, a much-maligned method.
This previous approach – known as the ‘IBM Campaign version-independent Integration with IBM Engage’ – was prone to error, due to the specific usage and order of additional parameters required by some of the scripts (e.g. contactUpload or trackingDownload). Missing out a parameter or entering the wrong database or contact list ID could result in a failed upload or download, or worse, such as a conflict of data (e.g. a mismatch of opt-ins and opt-outs).
There was also limited error reporting – if a script was called from the flowchart, that script ran on the analytic server and was unable to report back to the user through the Campaign interface any error codes or messages should the process fail. That would often mean that a system administrator would have to manually retrieve log files from the server.
Whilst many customers utilised the functionality of stored triggers in IBM Campaign, it was still down to the user to manually input ID’s, filenames and campaign codes. This also meant that users were having to navigate between the Campaign interface and WCA in a web browser in order to ensure they had the correct ID’s relating to the correct database, contact list or query. This could result in a lot of Alt-Tab’ing between windows or applications.
A workaround to hardcoding ID’s or filenames within the stored trigger was to utilise user variables. This way a user only had to create a few user variables in the flowchart with pre-defined names (e.g. SP_DatabaseID). These values would then be passed through to the trigger(s) meaning many global stored triggers could be defined initially by a Campaign administrator and then used by all Campaign users. But this initial building of triggers could be time consuming and, depending on the users’ needs, many variations may have been necessary (e.g. multiple contactUpload triggers but differing slightly in the number of parameters, such as if campaign code was required or not).
This version-independent integration with WCA had challenges elsewhere, also. An administrator would have to manually create the database tables for data download, configuration of the integration was managed by editing .properties files, and mapping of Campaign fields to WCA database fields was handled by custom XML mapping files.
From version 10.0 of IBM Campaign, users are now able to upload contacts directly to a WCA database via one of three flowchart process boxes – Email, SMS or Push. From the same process box, a user can attach a template, define personalisation such as Subject line and From address, and execute a send immediately from the same process by simply selecting a checkbox.
In all three process boxes, a dropdown menu displays the existing databases that a user can choose to upload to. In the Email process, for example, a user can assign the email template from another dropdown menu, and even append static values for personalisation, depending on how the template had been configured. All of this is now possible without the need for pre-defined stored triggers or the use of user variables, both of which could be subject to typos or other user errors.
The initial installation and configuration of this native integration is simpler, too. All tokens are stored as datasource logins against a single Platform user, and the authentication between IBM Campaign and WCA are managed by a single shared WCA user account.
When it comes to tracking events, the version-independent integration process was to execute a download script which was expected to be scheduled, most likely via a scheduled flowchart run. In version 10.0 and later, it is expected that tracking events will be downloaded from Universal Behaviour Exchange (UBX), where UBX subscribes to WCA events such as Email Send, SMS Interaction, Application Notification Opened etc. The download schedule of these events is managed in the Campaign configuration, where it can be set to run once a day at a given time, or every X number of minutes.
The native integration still isn’t perfect of course. Databases need to be created in WCA first and templates also need to be built in WCA with matching personalisation field names to Campaign. Uploads and sends are also being performed by a single WCA user account rather than the Campaign user. But overall, to help streamline your user’s workday when using WCA for your emails, SMS’s or app push notifications, there’s no better way to bring in efficiencies than to upgrade to IBM Campaign 10.0 or later.
A great line, from a great movie! But also, a line that was terrifying in its implication. It was th...
A/B Testing, also known as Split Testing, is a method of comparing two variants of the same communic...