There are two environments for each targeting dimension used when managing offers:
A design environment in which the offer manager takes care of creating and categorizing offers, editing them, and starting the approval process so that they can be used. The rules for each category, the offer spaces on which offers can be presented, and the pre-defined filters used to define an offer’s eligibility are also defined in this environment.
Categories can also be published manually in the online environment.
The process for approving offers is detailed in this section.
A live environment in which approved offers from the design environment, as well as the various offer spaces, filters, categories and rules configured in the design environment can all be found. During a call to the Offer engine, the engine will always use offers from the live environment.
An offer is only deployed on the offer spaces selected during the approval process. Therefore, an offer can be live but unusable on an offer space that is also live.
The Adobe Campaign Interaction module proposes two types of interactions:
These two types of interactions can be carried out either in unitary mode (offer is calculated for a single contact), or in batch mode (offer is calculated for a set of contacts). Generally, inbound interactions are carried out in unitary mode and outbound interactions are carried out in batch mode. Nevertheless, there may be certain exceptions, for transactional messages for example, whereby the outbound interaction is carried out in unitary mode.
As soon as an offer can or must be presented (according to the configurations carried out), the Offer engine plays the intermediary role: it automatically calculates the best possible offer for a contact among those available by combining data received about the contact and the different rules that can be applied as specified in the application.
To be able to support scalability and provide 24/7 service on the inbound channel, the Interaction module is implemented in a distributed architecture. This type of architecture is already used with Message Center and is made up of several instances:
Control instances are dedicated to the inbound channel and contain the online version of the catalog. Every execution instance is independent and dedicated to one contact segment (for example, one execution instance per country). Calls to the Offer engine must be directly performed on the execution (one specific URL per execution instance). As synchronization between instances is not automatic, interactions from the same contact must be sent through the same instance.
Offer synchronization is carried out via packages. On execution instances, all catalog objects are prefixed by the external account name. This means several control instances (development and production instances for example) can be supported on one same execution instance.
Use short and explicit internal names.
Offers are automatically deployed then published on execution and control instances.
Offers deleted in the design environment are disabled on all online instances. Obsolete propositions and offers are automatically deleted on all instances after the purge period (specified in each instance’s deployment assistant) and sliding period (specified in the incoming propositions’ typology rules).
A workflow is created for each environment and external account for proposition synchronization. Synchronization frequency can be adjusted for each environment and external account.
You must be aware of the following synchronization mechanisms:
Any schema extensions directly linked to Interaction (offers, propositions, recipients, etc.) must be deployed on the execution instances.
The Interaction package is installed on all instances (control and execution). Two additional packages are available: one package for the control instances, and the other for each execution instance.
When installing the package, the long type fields of the nms:proposition table such as the proposition ID, become int64 type fields. This type of data is detailed in Campaign Classic v7 documentation.
The data retention duration is configured on each instance (via the Data purge window in the deployment wizard). On execution instances, this period must correspond to the historical depth necessary for typology rules (sliding period) and eligibility rules to be calculated.
On the control instances:
Create one external account per execution instance:
Complete the label and add a short and explicit internal name.
Select the Execution instance.
Check the Enabled option.
Complete the connection parameters for the execution instance.
Every execution instance must be linked to an ID. This ID is assigned when you click on the Initialize connection button.
Check the type of application used: Message Center, Interaction, or both.
Enter the FDA account used. An operator must be created on the execution instances and must have the following read and write rights on the database of the instance in question:
grant SELECT ON nmspropositionrcp, nmsoffer, nmsofferspace, xtkoption, xtkfolder TO user; grant DELETE, INSERT, UPDATE ON nmspropositionrcp TO user;
The IP address of the control instance must be authorized on the execution instances.
Configure the environment:
Add the list of execution instances.
For each one, specify the synchronization period and filter criteria (for example, by country).
If you encounter an error, you can consult the synchronization workflows and offer notifications. These can be found in the technical workflows of the application.
If, for optimization reasons, only part of the marketing database is duplicated on the execution instances, you can specify a restricted schema linked to the environment to allow the users to only use data that is available on the execution instances. You can create an offer using data that is not available on execution instances. To do this, you must deactivate the rule on the other channels by limiting this rule on the outbound channel (Taken into account if field).
Here is a list of maintenance options available on the control instance:
These options must only be used for specific maintenance cases.
NmsInteraction_LastOfferEnvSynch_<offerEnvId>_<executionInstanceId>: last date that an environment was synced on a given instance.
NmsInteraction_LastPropositionSynch_<propositionSchema>_<executionInstanceIdSource>_<executionInstanceIdTarget>: last date that propositions from a given schema were synced from one instance to another.
NmsInteraction_MapWorkflowId: an option containing the list of all synchronization workflows generated.
The following option is available on execution instances:
NmsExecutionInstanceId: option containing the instance ID.
If your instance did not previously have the Interaction package, no migration is necessary. By default, the proposition table will be in 64 bits after the packages have been installed.
Depending on the volume of existing propositions in your instance, this operation may take a while.
If you have carried out specific configurations in the proposition table, adapt the queries accordingly.
There are two methods:
Work table (recommended)
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 nmspropositionrcp ALTER COLUMN ipropositionid TYPE bigint, ALTER COLUMN iinteractionid TYPE bigint;