Contact and Response

Maintaining good quality Contact and Response history (CH/RH) is essential to a successful marketing automation program whether or not you chose to use the inbuilt functionality within Unica Campaign. Making the assumption that you have, this article will cover some key considerations your organisation will need to make as well as some best practice ideas we’ve picked up along the way. Without CH, it will be impossible to ask questions such as:

• Who received Campaign C in the last D days?
• Who received offer F and clicked on the associated Link?
• Who did not receive Campaign C on channel L because of some failure?
• Who have I already contacted for this Campaign (Hint <ContactHistory>.campaigncode = <Campaign Generated Fields>.campaigncode)

Audiences

The first decision you will need to make during implementation of your Unica environment will be which “audiences” you wish to capture contact information for. Usually this will be for your customer. In some organisations though you may contact your customers via their Card or Account numbers. In these cases, I think it’s always best to still map your history data at a customer level. You can add Card, Account numbers etc as additional attributes. This then gives the benefit of storing and tracking your contacts in one place with no concerns over bringing together information from multiple places to see if you contacted a customer or not. You can then use data mapping and “catalogs” to map the history table multiple times at these additional key identification levels to allow you to ask questions such as “Find me all card numbers that were contacted in campaign X”

This is important as your campaign selections for these environments may need to ask inclusion or exclusion questions across customers, cards, accounts etc and then bring the results together to identify a final contact universe.

Custom Attributes

Next up is how many additional custom attributes you wish to capture in your CH and RH. There is no hard and fast rule, but the advice would be to add as little as you can get away with and if more than 10 then you may be facing issues. CH is susceptible to performance concerns when containing lots of data, whether reading from, or writing to, via a MailList process. Ask yourself, do you really need all those 40 attributes?

Try to stick to those that are required in selection or that you must keep for legal or audit reasons – and even then, you could use the “log to other destination” functionality within the MailList and use a separate storage table.

Attributes can be captured in multiple places as well to model your business. Try to pick the highest level possible to minimise the amount of data stored. Campaign > Cell > Offer > Contact > Response. For your contact and response status, consider having high- and low-level codes. Occasionally, you may want to know that a mailbox was full, other times just that the contact was “Undelivered”. You can load both status codes into your CH/RH via the Track or Response processes. If just the low-level codes are used, you may find that your selection logic is having to ask “Did you respond with Code A OR Code B OR Code C etc.)

Access via Views

Accessing your CH and RH can also be interesting. The natural structure of the data in the Unica Campaign System tables is not the most intuitive, taking you through treatments, packages, campaigns, offer history etc. Creation of a set of views over these tables can really help your users. Most questions you ever ask of CH and RH are normally around what happened (status) and when (Contact/Response dates), identified via different dimensions – Campaign/Offer/Cell by Name/Code. Some considerations to make when generating the views:

• Contact history can end up being stored in Contact History or Detailed Contact History depending on your usage of (parameterised) offer attribute value assignment so you will need to UNION these together in your view
• Offer attributes are stored at an OfferID level, not by name. As a result, any view that references these attributes must translate the ID into something meaningful for your users.
• Your views will need regenerating if a key custom attribute is added via the user interface

Automation of Response

Response flowcharts can be built to load customer and channel response into your CH and RH. Usually you will be building these flowcharts per contact or response channel if you have access to matching keys such as a treatment code. In these cases, you can read any action table provided by the channel, scheduled at a frequency of update that matches that of the update of action table and run from within a Session.

Channel responses would include transactions such as Mailbox full, i.e. delivery status and these would be processed via the track process to update, as a minimum, actual contact status date and the status itself. Responses (clicks, opens, purchase etc) are picked up via the Response process. Don’t forget to update your tables UA_ContactStatus and UA_UsrResponseType with any bespoke contact and response status codes to ensure these transactions are not rejected with the “counts_as*” field set if you want the response to be included in the standard reports.

Offers

Offers can be confusing so think of them as messages to your customer that may or may not elicit a response. The offer itself in Unica Campaign is a way to capture (potentially at runtime), characteristics of the message that can then be passed onto the channel or stored in the CH for asking questions of later, for example, which offers were sent on channel SMS for a Retention type message.

Offers are Campaign independent, meaning you can set them up once and use multiple times. If you are scheduling your campaigns to run repeatedly over a period of time, then it is a good idea to set the start and end dates of the offer dynamically at runtime. Create derived fields and assign them in Parameters tab of the MailList process.

For example:

df_EffectiveStart = CURRENT_DATE() and

df_ExpirationDate = CURRENT_DATE()+7.

Housekeeping and GDPR

As mentioned above, retaining large amounts of Contact History will eventually affect the performance of your system. Before that happens, consider how much data you need to retain and where you could place older data and at what level of detail, in longer term storage. You do not need to archive all old data either, selecting contacts with no response for deletion much sooner for example.

However, this is one of the areas of Unica Campaign that could be impacted by GDPR as your contact history may contain personal data. For this reason, as well as performance concern, it is good practice to only retain data for only as long as you can justify retaining it.

For Housekeeping, consider the use of Extract processes to select candidate data and Snapshot to append it to the candidate archive table(s). Deletion of data from the CH tables is more interesting as there are no native processes to do this. Instead you can utilise the raw SQL capability of the Select process to delete data over a certain age. Depending on the requirements and complexity of your organisation, you may instead wish to build a controlled archival process using an external application.

We have just touched on a few aspects of Contact and Response History processing with Unica Campaign. The importance and system impact of this area means it is no coincidence that it forms a significant part of the implementation and support services at Purple Square. If you wish to learn more about Unica Campaign, Marketing automation or making your contact and response history work harder for your organisation please get in touch for more information.