Pour chaque dimension de ciblage utilisée dans le cadre de la gestion des offres existe un duo d'environnements :
Un environnement en édition, dans lequel le chargé d'offre s'occupe de créer et catégoriser les offres, de les modifier, de lancer le processus de validation afin qu'elles puissent être utilisées. Dans cet environnement sont également définis les règles propres à chaque catégorie, les emplacements sur lesquels les offres peuvent être présentées et les filtres prédéfinis utilisables pour définir l'éligibilité d'une offre.
Les catégories peuvent également être publiées manuellement dans l'environnement en ligne.
La validation des offres est détaillée dans cette section.
Un environnement en ligne, dans lequel se trouvent les offres validées de l'environnement en édition, ainsi que les différents emplacements, filtres, catégories et règles paramétrés dans l'environnement en édition. Lors d'un appel au moteur d'offres, ce dernier utilisera toujours les offres de l'environnement en ligne.
Une offre n'est déployée que sur les emplacements sélectionnés lors de la validation. Ainsi, une offre peut être en ligne mais non utilisable sur un emplacement lui aussi en ligne.
Le module Interaction d'Adobe Campaign propose deux types d'interactions :
Ces deux types d'interactions peuvent être réalisés soit en mode unitaire (l'offre est calculée pour un seul contact), soit en mode batch (l'offre est calculée pour un ensemble de contacts). Généralement, les interactions entrantes sont réalisées en mode unitaire et les interactions sortantes en mode batch. Néanmoins, des exceptions peuvent exister, par exemple pour des messages transactionnels, où l'interaction sortante est réalisée en mode unitaire.
Dès lors qu'une offre peut ou doit être présentée (en fonction des paramétrages réalisés), le moteur d'offre joue le rôle d'intermédiaire : il calcule automatiquement la meilleure offre possible pour un contact parmi celles disponibles, en combinant les données recueillies sur le contact et les différentes règles applicables définies dans l'application.
Pour être en mesure d'assurer l'évolutivité et d'offrir un service 24h/24, 7j/7 sur le canal entrant, le module Interaction est implémenté dans une architecture distribuée. Ce type d'architecture est déjà utilisé avec Message Center et est constitué de plusieurs instances :
Les instances de pilotage sont dédiées au canal entrant et contiennent la version en ligne du catalogue. Chaque instance d'exécution est indépendante et consacrée à un segment de contact (par exemple, une instance d'exécution par pays). Les appels au moteur d'offre doivent être effectués directement sur l'instance d'exécution (une URL spécifique par instance d'exécution). Étant donné que la synchronisation entre les instances n'est pas automatique, les interactions d'un même contact doivent être envoyées à travers la même instance.
La synchronisation des offres s'effectue par packages. Sur les instances d'exécution, tous les objets du catalogue ont comme préfixe le nom du compte externe. Cela permet la prise en charge de plusieurs instances de pilotage (instances de développement et de production par exemple) sur une même instance d'exécution.
Utilisez des noms internes courts et explicites.
Les offres sont automatiquement déployées puis publiées sur les instances d'exécution et l'instance de pilotage.
Les offres supprimées dans l'environnement en édition sont désactivées sur toutes les instances en ligne. Les propositions et les offres obsolètes sont automatiquement supprimées de toutes les instances lorsque la période de purge (définie dans l'assistant de déploiement sur chaque instance) et la période glissante (définie dans les règles de typologie des propositions entrantes) sont dépassées.
Un workflow est créé pour chaque compte externe et environnement pour la synchronisation des propositions. La fréquence de synchronisation peut être ajustée pour chaque environnement et compte externe.
Vous devez prendre en compte les mécanismes de synchronisation suivants :
Les éventuelles extensions de schémas directement liées à Interaction (offres, propositions, destinataires, etc.) doivent être déployées sur les instances d'exécution.
Le package Interaction est installé sur toutes les instances (de pilotage et d'exécution). Deux packages supplémentaires sont disponibles : l'un pour les instances de pilotage et l'autre pour chaque instance d'exécution.
Lors de l'installation du package, les champs de type long de la table nms:proposition tels que l'identifiant de la proposition, deviennent des champs de type int64. Ce type de données est détaillé dans la documentation de Campaign Classic v7.
La durée de conservation des données est configurée sur chaque instance (via la fenêtre Purge des données dans l'assistant de déploiement). Sur les instances d'exécution, cette période doit correspondre à la profondeur historique nécessaire au calcul des règles de typologie (période glissante) et d'éligibilité.
Sur les instances de pilotage :
Créez un compte externe par instance d'exécution :
Renseignez le libellé et un nom interne court et explicite.
Sélectionnez le type Instance d'exécution.
Cochez l'option Activé.
Renseignez les paramètres de connexion à l'instance d'exécution.
Chaque instance d'exécution doit être associée à un identifiant. Cet identifiant est attribué lorsque vous cliquez sur le bouton Initialiser la connexion.
Cochez le type d'application utilisée : Message Center, Interaction, ou les deux.
Renseignez le compte FDA utilisé. Un opérateur doit être créé sur les instances d'exécution et doit posséder les droits de lecture et de modification suivants au niveau de la base de données de l'instance en question :
grant SELECT ON nmspropositionrcp, nmsoffer, nmsofferspace, xtkoption, xtkfolder TO user;
grant DELETE, INSERT, UPDATE ON nmspropositionrcp TO user;
L'adresse IP de l'instance de pilotage doit être autorisée sur les instances d'exécution.
Configurez l'environnement :
Ajoutez la liste des instances d'exécutions.
Définissez pour chacune la fréquence de synchronisation et les critères de filtrage (par exemple par pays).
En cas d'erreur, vous pouvez consulter les workflows de synchronisation et de notification des offres, disponibles dans les workflows techniques de l'application.
Si, pour des raisons d'optimisation, seulement une partie de la base marketing est dupliquée sur les instances d'exécution, il est possible de définir un schéma restreint associé à l'environnement afin de permettre aux utilisateurs de n'utiliser que les données disponibles sur les instances d'exécution. Il est possible de créer une offre utilisant des données non disponibles sur les instances d'exécution. Pour cela, vous devez désactiver la règle sur les autres canaux en limitant cette règle au canal sortant (champ Pris en compte si).
Voici la liste des options de maintenance disponibles sur l'instance de pilotage :
Ces options ne doivent être utilisées que dans des cas de maintenance spécifiques.
NmsInteraction_LastOfferEnvSynch_<offerEnvId>_<executionInstanceId>
: date de dernière synchronisation d'un environnement sur une instance donnée.NmsInteraction_LastPropositionSynch_<propositionSchema>_<executionInstanceIdSource>_<executionInstanceIdTarget>
: date de dernière synchronisation des propositions d'un schéma donné d'une instance vers une autre.NmsInteraction_MapWorkflowId
: option contenant la liste de tous les workflows de synchronisation générés.L'option suivante est disponible sur les instances d'exécution :
NmsExecutionInstanceId : option contenant l'identifiant de l'instance.
Si votre instance ne possédait pas le package Interaction auparavant, aucune migration n'est nécessaire. Par défaut, la table des propositions sera en 64 bits une fois les packages installés.
Selon le volume de propositions existantes dans votre instance, cette opération peut être très longue.
Si vous avez effectué des paramétrages spécifiques dans la table des propositions, adaptez les requêtes en conséquence.
Deux méthodes sont disponibles :
Table de travail (recommandée)
CREATE TABLE NmsPropositionRcp_tmp AS SELECT * FROM nmspropositionrcp WHERE 0=1;
ALTER TABLE nmspropositionrcp_tmp
ALTER COLUMN ipropositionid TYPE bigint,
ALTER COLUMN iinteractionid TYPE bigint;
INSERT INTO nmspropositionrcp_tmp SELECT * FROM nmspropositionrcp;
DROP TABLE nmspropositionrcp;
CREATE INDEX proposition_id ON NmsPropositionRcp (ipropositionid);
CREATE INDEX nmspropositionrcp_deliveryid ON NmsPropositionRcp (ideliveryid);
CREATE INDEX nmspropositionrcp_lastmodified ON NmsPropositionRcp (tslastmodified);
CREATE INDEX nmspropositionrcp_offerid ON NmsPropositionRcp (iofferid);
CREATE INDEX nmspropositionrcp_offerspaceid ON NmsPropositionRcp (iofferspaceid);
CREATE INDEX nmspropositionrcp_recipientidid ON NmsPropositionRcp (irecipientid);
ALTER TABLE nmspropositionrcp_tmp RENAME TO nmspropositionrcp;
Alter Table
ALTER TABLE nmspropositionrcp
ALTER COLUMN ipropositionid TYPE bigint,
ALTER COLUMN iinteractionid TYPE bigint;