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
Who received Campaign C in the last D days?
Who received offer F and clicked on the
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
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
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
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
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 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.
df_EffectiveStart = CURRENT_DATE()
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 touchfor more information.