Track Responders

Campaign Development Lifecycle Track Responders

Campaign History

Every campaign should keep a history of contact for a customer – whether it is a marketing, service/informational or legal message. For most campaign management software logging a customer contact is very simple. Generally within the Mail List Process box there will be an option to save to history. Often there will be two choices, a built-in history table or a user-specified table. If using Unica Campaign click on the Log TAB and then tick the “Log to Contact History Tables” check box (see image below). This will store a record for every customer that you have selected, including those in the control groups (if applicable). When working at ANZ I found it easier to create my own History and Response tables because Unica Campaign wasn’t set-up correctly for my needs. Most organisations will do better using the built-in campaign history and response functionality. The built-in tables are naturally mapped throughout the remainder of their product suite and life will be easier if you migrate from your old promotion history tables. In the Unica suite they are nicely integrated into reporting functionality, where you will find numerous reports that run directly off the built-in history and response tables.

Unica Campaign Mail List Process Configuration

Response History / Response Reporting

The response history tables are where you store information about customers that have responded to your offer. In a nutshell, at this stage you will be checking all customers logged in your history table (including control groups) for a specific campaign and seeing if they have matched the response criteria for that campaign (within a set time frame). These customers are captured and logged into a Response History table. Your campaign management software vendor will provide specific detail about how to set-up this functionality so I won’t go into too much detail here. Below are a few tips that might help though.

Quick Tip

  1. Check your history and response values for duplicates (There is no quicker way to have a completely incorrect report than double/triple/quadruple counting because your tables have been set-up with the wrong joins.)
  2. Make sure the same accounts/responses aren’t being attributed to multiple people. This can be likely with fuzzy matching for responders. If you are having to match files on name, address, etc then sense check the matched records visually before you distribute the report. I have seen instances where some accounts where attributed to completely different people because the match rules were too loose.
  3. Have you written the correct number of records to history? This is so obvious and should be part of a Quality Assurance check, but if you haven’t written the correct records to your history table you may never be able to report on that campaign – subsequent executions will remove the opportunity to back-populate the data. This can happen when an analyst unchecks the “Log to History” option while testing some changes.

Phase 9. Reporting