InsightIQ Blog

3.0 Reusability in Unica 7.5 – How to leverage Contact History

View more Blog Posts

May 4 2009

When many of our clients  think of contact history, they think of reporting. Contact history is a table often joined to when creating marketing reports. Contact history provides the mailed-base for historical campaigns, and as such, it feeds reports that measure lift, response rates and other metrics. In this issue, I will talk about the reusability of contact history in Unica version 7.5. Below, we will explore how contact history may be deployed in order to actually extend your investment in Unica's Affinium Campaign.

"How do you marry Unica's campaign metadata with other customer information once you have implemented Unica's Affinium Campaign?"

I'll bet you want to extend the use of your corporate reporting mart after implementing Affinium Campaign. We recently helped a client successfully do just that. Here is the problem statement: how do you marry Unica campaign metadata with other customer information once you have implemented Unica's Affinium Campaign?

Go ahead, try to answer this before reading on.

Did you suggest using Unica's built-in Cognos reporting tool in order to replace the corporate reporting mart? Many of our clients reach this same conclusion when selecting Unica. But what if there is an approach that could leverage your existing reporting mart? Would you want to explore that further? Imagine being able to save the time and cost associated with developing and migrating your reporting dashboards into Unica.

"We recently helped a client successfully extend their corporate reporting mart after implementing Affinium Campaign."

In the steps below I outline how we helped our client extend their corporate reporting mart after implementing Unica. Unica's contact history table can be deployed to facilitate direct response attribution in a corporate reporting mart by:

  1. Creating a unique key. Although Unica's proprietary contact history table generates a unique compound key, it is a best practice to enable a row number-like key on the contact history table (you will see further discussion about this below). To add a unique key column to Unica's contact history, just create a trigger on the contact history table that generates a sequential key for each new row. If you have already created a contact history table in Unica (call it table A) just create a copy of that table (call it table B), add the trigger to table B, copy over the data from table A to table B, and then rename table B to table A. No changes to or re-mapping of the existing Affinium Campaign table catalog(s) is necessary.
  2. Adding of a source of awareness code (SOAC). In order to perform direct response attribution, some code will be required in order to identify the source of the record. Unica's treatment code can be used as a SOAC. Just map the treatment code into contact history for each row. The SOAC will enable the mapping back of each row to the campaign, the offer, the treatment, and even the flowchart that was used to generate that row. Consequently, when performing direct response attribution on transactions in the customer data mart the SOAC enables direct response attribution.
  3. Creating ETL from Unica. By creating an ETL (extract, transform, and load) process from Unica to the corporate reporting mart, you can successfully move contact history (and other metadata) from Unica, into the reporting mart. How about the unique row id that we created in step #1 above? The unique row id comes in to play when marrying up Unica's contact history with your legacy contact history table in the reporting mart. And the unique row id serves as a "Unica contact history key" once the Unica contact history is wedded with the partner's legacy contact history.

So what does this mean for you? If you followed along this far, then you are probably aware that we have provided a vehicle for leveraging Unica's contact history and then extending that contact history directly into the corporate reporting mart. Once the Unica data has been extracted into the corporate reporting mart, all such reports using the legacy contact history table will still work - with the added benefit that they now include contacts from Unica. How about that? Try it out and let me know how it goes. Send me a note and we can discuss some of the challenges you're attempting to address. 

This article is the third in a series. Follow the links below to read the first and second articles in the Reusability in Unica V7.5 blog by Greg Denlea.

1.0 Reusability in Unica 7.5 - Yes you can reuse this environment!

 

This article is filed under:

View more Blog Posts

Leave Your Comment Comments

Jun 11 2009

Gil Kochavi said:

this is our best practice in CM implementation for 5 years now. in the first place we instal CM in the DWH scheme. the performance are much better and the business insights as well. mapping the CH to the marketing analytical environment enables us to understand responders and to manage on going improvement.
Gil Kochavi
Synergy Israel

Jun 15 2009

Greg Denlea said:

Hi Gil,
Thank you for your response. Your comment "we instal CM in the DWH scheme" is of interest to me. I am surprised that your clients allow you to deploy Unica's web application schema inside the data warehouse (schema). Dbas typically do not allow the installation of web applications into the corporate data warehouse. The separation of databases with different purposes is a generally accepted best practice.

Nevertheless it sounds like you have been helping your clients reap the rewards from integrating Affinium Campaign and their legacy data warehouse. Do you use the treatment id from Unica for response attribution?

I also want to know if you create a run id for your contact history loads. We provide our clients with a run id component for their contact hsitory loads. Unica's Affinium Campaign V7.5 enables the developer to remove a (multiple, or all) flowchart run from contact history. But what if you wanted to remove a particular load from contact history outside of the Affinium Campaign application? That is where the concept of adding a run id to contact history comes in. We increment a column (via a custom macro) each time a flowchart is run and that unique id is appended into contact history into a field called the run id. DBAs can use the run id in order to identify each batch generated by a particular flowchart's load into contact history.

Talk to you soon Gil!

Aug 1 2009

Martin Djovic said:

Hi Greg

Have you done work which pushes the limits on the number of target cells that an AC7.2 campaign (microsegments)?

Wondering if you can point me to any documentation that talks about best practices for :

-What is the max # of target cells that AC has handled successfully?
-Typical non-segmentation tasks can we pre-cook in database and offload from AC
-How to handle TARGET CELL--> OFFER assignment when dealing with large number of target cells (1000s of cells)
etc

It is v.difficult in general to see white papers, good readings on best practices, but please recommend any that you may have come across.

Martin

Aug 19 2009

Greg Denlea said:

Hi Martin,
Thank you for your questions. You posed some very good questions which I will attempt to respond to below. Unica V7.5 has both strengths and weaknesses with respect to offer management.

Unica is very good at ensuring the uniqueness of offer codes. For instance if you detach and then re-attach a process box to a segment process box Unica provides a faculty for re-generating cells. In this way Unica guarantees uniqueness each time you re-generate cells.

Unica V75 has not documented any limitations to the number of cells you may generate in a single flowchart. Towards your question “What is the max # of target cells that AC has handled successfully?” there should be no limitations. However when you create a flowchart which contains thousands of cells the Unica Campaign application may exhibit issues. For instance a flowchart with thousands of cells may take longer to open in the edit mode (In another discussion we could speak to some of the tuning opportunities available).

In response to your question, “How to handle TARGET CELL--> OFFER assignment when dealing with large number of target cells (1000s of cells)?”, the actual work of assigning offers to thousands of cells (or in your terminology “micro-segments”) in a single contact process is a tedious and painstaking effort. The interface (configuration window of a contact process) may encounter issues. The “All Cells” option is only an option if you are assigning the same offer to multiple cells. But I think the essence of your question pertains to assigning a multitude of unique offers to a multitude of cells. One of the weaknesses I have experienced with Unica, when there are hundreds of cells in a single contact process, is the ability to consistently select the desired cell using the interface. I have had issues whereby the interface selects the cell above or below the one that you have pointed at with your cursor.

You also asked about best practices when managing offer assignment for thousands of cells in a single flowchart. One of the solutions that you may try is to assign the offers to the cells using the Target Cell Spreadsheet (TCS). In response to your question “[What] Typical non-segmentation tasks can we pre-cook in database and offload from AC?”, offer-to-cell assignment could occur in a database application and then the results could be pasted into the TCS. You may still experience the same difficulties with the interface described above but this might enable you to get the initial assignment done outside of the Unica application. However if you still need to assign parameters to the offers then you will still need to return to the configuration window of the contact process box.

One final suggestion to help alleviate some of the issues with parameter assignment is to fill in the default parameters of the offers. You will want to have the default values filled in prior to assigning the offers to the cells since once the offers are assigned any updates to the defaults will not automatically update offer parameters for offers already assigned to cells. Obviously the defaults may not be the actual parameters assigned to all of the cells but at least so some of the parameter assignments will be completed in the contact process.

Please let me know if I have adequately addressed your questions and feel free to follow up with me (greg_denlea@csgsystems.com).

Leave a Comment

  • Your email won't be published on our site.

All Fields Required