Autres types de réponse
Dans Interact, vous pouvez utiliser la méthode postEvent dans l'API Interact API pour déclencher un événement qui journalise une action "accepter" ou "refuser" pour une offre. Vous pouvez également étendre le système pour permettre à l'appel postEvent d'enregistrer des réponses supplémentaires, telles que Explorer, Considérer, Valider, ou Réaliser. Tous ces types de réponse doivent exister dans la table UA_UsrResponseType dans les tables système Campaign. L'utilisation de paramètres d'événements spécifiques à la méthode postEvent vous permet d'enregistrer des types de réponse supplémentaires et de définir si une acceptation doit être inclue dans l'apprentissage.
Pour journaliser des types de réponse supplémentaires, vous devez ajouter les paramètres d'événement suivants :
*
UACIRESPONSETYPECODE — chaîne représentant un code de type de réponse. La valeur doit être une entrée valide de la table UA_UsrResponseType.
Pour que l'entrée dans UA_UsrResponseType soit valide, vous devez définir toutes les colonnes de la table, y compris CountsAsResponse. Les valeurs valides de CountsAsResponse sont 0, 1, ou 2. 0 indique l'absence de réponse, 1 indique une réponse, et 2 indique un refus. Ces réponses sont utilisées pour la génération de rapports.
*
UACILOGTOLEARNING — Nombre ayant la valeur 1 ou 0. 1 indique que Interact doit consigner l'événement comme une acceptation pour l'apprentissage. 0 indique que Interact ne doit pas consigner l'événement pour l'apprentissage. Ce paramètre vous permet de créer plusieurs méthodes postEvent qui consignent différents types de réponse sans influence sur l'apprentissage. Si vous ne définissez pas UACILOGTOLEARNING, Interact considère que la valeur par défaut est 0.
Il peut être utile de créer plusieurs événements avec l'action Journaliser l'acceptation de l'offre : soit un événement par type de réponse à journaliser, soit un événement unique avec l'action Journaliser l'acceptation de l'offre utilisée pour chaque appel postEvent journalisant des types de réponse différents.
Par exemple, créez un événement avec l'action Journaliser l'acceptation de l'offre pour chaque type de réponse. Vous définissez les réponses personnalisées suivantes dans la table UA_UsrResponseType [sous le format Nom (code)] : Exploree (EXP), Considérer (CON), et Valider (CMT). Vous créez ensuite trois événements et les nommez LogAccept_Explore, LogAccept_Consider et LogAccept_Commit. Tous les trois événements sont exactement les mêmes (ils utilisent l'action Journaliser l'acceptation de l'offre), mais leurs noms sont différents afin que la personne travaillant avec l'API puisse les distinguer entre eux.
Vous avez également la possibilité de créer un événement unique avec l'action Journaliser l'acceptation de l'offre utilisée pour tous les types de réponses personnalisées. Par exemple, appelez-le LogCustomResponse.
Lorsque vous travaillez avec l'API, il n'y a aucune différence fonctionnelle entre les événements, mais les conventions de dénomination peuvent rendre le code plus clair. Par ailleurs, si vous donnez un nom distinct à chaque réponse personnalisée, le rapport Récapitulatif d'activité des événements du canal affiche les informations de façon plus précise.
Commencez par définir toutes les paires valeur-nom.
//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);
Ce premier exemple montre l'utilisation des événements individuels.
//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);
Ce deuxième exemple illustre l'utilisation d'un seul événement.
//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);
Les deux exemples exécutent exactement les mêmes actions, mais une version peut être plus facile à lire que l'autre.