Additional response types

In Unica Interact, you can use the postEvent method in the Unica Interact API to trigger an event which logs an "accept" or "reject" action for an offer. You can also augment the system to allow the postEvent call to record additional response types, such as Explore, Consider, Commit, or Fulfill.

All of these response types must exist in the UA_UsrResponseType table in the Unica Campaign system tables. Using specific event parameters to the postEvent method, you can record additional response types and define whether an accept should be included in learning.Also its suggested not to post multiple responses (Accept/Reject) for single contact , as it may result in incorrect learning scores.

To log additional response types, you must add the following event parameters:

• UACIResponseTypeCode - a string representing a response type code. The value must be a valid entry in the UA_UsrResponseType table.

  To be a valid entry in the UA_UsrResponseType you must define all of the columns in the table, including CountsAsResponse. Valid values for CountsAsResponse are 0, 1, or 2. 0 indicates no response, 1 indicates a response, and 2 indicates a reject. These responses are used for reporting.

• UACILogToLearning -

  The parameter ‘UACILogToLearning’ is deprecated in version 11.0. Instead, the actual values defined in ‘ UA_ContactStatus’ and ‘UA_UsrResponseType’ tables from Campaign database along with the values defined in the ‘Affinium|interact|services|contactHist|contactStatusCodes’ and ‘Affinium|interact|services|responseHist|responseTypeCodes ‘ parameters would be considered by the Interact system.

  ’

  If you pass ‘UACILogToLearning= 1’ in a postevent call, then the configured action associated to the response type/contact status will be ignored and this event is always treated as a true response/contact.

You may want to create several events with the Log Offer Acceptance action, one for every response type you want to log, or a single event with the Log Offer Acceptance action you use for every postEvent call you use to log separate response types.

For example, create an event with the Log Offer Acceptance action for each type of response. You define the following custom responses in the UA_UsrResponseType table [as Name (code)]: Explore (EXP), Consider (CON), and Commit (CMT). You then create three events and name them LogAccept_Explore, LogAccept_Consider, and LogAccept_Commit. All three events are exactly the same (have the Log Offer Acceptance action), but the names are different so that the person working with the API can distinguish between them.

Or, you could create a single event with the Log Offer Acceptance action that you use for all custom response types. For example, name it LogCustomResponse.

When working with the API, there is no functional difference between the events, but the naming conventions may make the code clearer. Also, if you give each custom response a separate name, the Channel Event Activity Summary report displays more accurate information.

First, set up all the name-value pairs

//Define name value pairs for the UACIResponseTypeCode 
// Response type Explore 
NameValuePair responseTypeEXP = new NameValuePairImpl();
responseTypeEXP.setName("UACIResponseTypeCode");
responseTypeEXP.setValueAsString("EXP");
responseTypeEXP.setValueDataType(NameValuePair.DATA_TYPE_STRING);
 
// Response type Consider
NameValuePair responseTypeCON = new NameValuePairImpl(); 
responseTypeCON.setName("UACIResponseTypeCode");
responseTypeCON.setValueAsString("CON");
responseTypeCON.setValueDataType(NameValuePair.DATA_TYPE_STRING);
 
// Response type Commit
NameValuePair responseTypeCMT = new NameValuePairImpl(); 
responseTypeCMT.setName("UACIResponseTypeCode");
responseTypeCMT.setValueAsString("CMT");
responseTypeCMT.setValueDataType(NameValuePair.DATA_TYPE_STRING);
 
//Define name value pairs for UACILOGTOLEARNING 
//Does not log to learning 
NameValuePair noLogToLearning = new NameValuePairImpl();
noLogToLearning.setName("UACILOGTOLEARNING");
noLogToLearning.setValueAsString("0");
noLogToLearning.setValueDataType(NameValuePair.DATA_TYPE_NUMERIC);
 
//Logs to learning
NameValuePair LogToLearning = new NameValuePairImpl(); 
LogToLearning.setName("UACILogToLearning");
LogToLearning.setValueAsString("1");
LogToLearning.setValueDataType(NameValuePair.DATA_TYPE_NUMERIC);

This first example shows using the individual events.

//EXAMPLE 1: This set of postEvent calls use the individually named events 
//PostEvent with an Explore response 
NameValuePair[] postEventParameters = { responseTypeEXP, noLogToLearning }; 
response = api.postEvent(sessionId, LogAccept_Explore, postEventParameters);
 
//PostEvent with a Consider response
NameValuePair[] postEventParameters = { responseTypeCON, noLogToLearning }; 
response = api.postEvent(sessionId, LogAccept_Consider, postEventParameters);
 
//PostEvent with a Commit response
NameValuePair[] postEventParameters = { responseTypeCOM, LogToLearning }; 
response = api.postEvent(sessionId, LogAccept_Commit, postEventParameters);

This second example shows using just one event.

//EXAMPLE 2: This set of postEvent calls use the single event 
//PostEvent with an Explore response 
NameValuePair[] postEventParameters = { responseTypeEXP, noLogToLearning }; 
response = api.postEvent(sessionId, LogCustomResponse, postEventParameters);
 
//PostEvent with a Consider response
NameValuePair[] postEventParameters = { responseTypeCON, noLogToLearning }; 
response = api.postEvent(sessionId, LogCustomResponse, postEventParameters);
 
//PostEvent with a Commit response
NameValuePair[] postEventParameters = { responseTypeCOM, LogToLearning }; 
response = api.postEvent(sessionId, LogCustomResponse, postEventParameters);

Both examples perform exactly the same actions, however, one version may be easier to read than the other.