Additional response types
In Interact, you can use the postEvent method in the 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 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.
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 - A number with the value 1 or 0. 1 indicates Interact should log the event as an accept for learning. 0 indicates Interact should not log the event for learning. This parameter enables you to create several postEvent methods logging different response types without influencing learning. If you do not define UACILogToLearning, Interact assumes the default value of 0.
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.
Copyright IBM Corporation 2014. All Rights Reserved.