Compréhension des environnements et de l'architecture des interactions dans Campaign

Environnements

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.

Interactions entrantes et sortantes

Le module Interaction d'Adobe Campaign propose deux types d'interactions :

• interactions entrantes, initiées par un contact. En savoir plus
• interactions sortantes, initiées par un chargé de diffusion Campaign. En savoir plus

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.

Architecture répartie

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 :

• une ou plusieurs instances de pilotage dédiées au canal sortant et contenant la base marketing et l'environnement en édition
• une ou plusieurs instances d'exécution dédiées au canal entrant

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.

Synchronisation

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.

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 :

• Si vous utilisez la fonction de basculement (fall back) d'un environnement anonyme vers un environnement identifié, ces deux environnements doivent être sur la même instance d'exécution.
• La synchronisation entre plusieurs instances d'exécution ne s'effectue pas en temps réel. Les interactions d'un même contact doivent être envoyées vers une même instance. L'instance de pilotage doit être dédiée au canal sortant (pas de temps réel).
• La synchronisation de la base marketing n'est pas automatique. Les données marketing utilisées dans le cadre des règles d'éligibilité et des poids doivent être dupliquées sur les instances d'exécution. Ce processus n'est pas fourni en standard, vous devez le développer pendant la phase d'intégration.
• La synchronisation des propositions s'effectue exclusivement par connexion FDA.
• Si vous utilisez Interaction et Message Center sur une même instance, la synchronisation s'effectuera par protocole FDA dans les deux cas.

Configuration des packages

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.

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 :

1. 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;
     

   REMARQUE

   L'adresse IP de l'instance de pilotage doit être autorisée sur les instances d'exécution.

2. 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).

     REMARQUE

     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).

Options de maintenance

Voici la liste des options de maintenance disponibles sur l'instance de pilotage :

• 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.

Installation des packages

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.

• Si votre instance ne comporte pas ou peu de propositions, aucune modification manuelle de la table des propositions n'est nécessaire. La modification sera faite au moment de l'installation des packages.
• Si votre instance comporte un grand nombre de propositions, il est préférable de changer la structure de la table des propositions avant l'installation des packages de pilotage et d'exécution. Nous vous conseillons d'exécuter les requêtes à une période creuse.

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;