Adobe Campaign comes with a pre-defined data model. This section gives some details on the built-in tables of the Adobe Campaign data model and their interaction.
To access the description of each table, go to Admin > Configuration > Data schemas, select a resource from the list and click the Documentation tab.
The physical and logical structure of the data carried in the application is described in XML. It obeys a grammar specific to Adobe Campaign, called a schema. For more on Adobe Campaign schemas, read out this section.
Adobe Campaign relies on a relational database containing tables that are linked together.
The following diagram shows the joins between the main business tables of the Adobe Campaign data model with the main fields for each.
The pre-defined Adobe Campaign data model includes the main tables listed below.
This table matches the nms:recipient schema.
It is the default table used for the recipients of deliveries. As a result, it contains the information required for deliveries via the various channels:
The iFolderId field is the foreign key that links the recipient to its execution folder. For more on this, see XtkFolder.
The sCountryCode field is the 3166-1 Alpha 2 ISO code (2 characters) of the country associated with the recipient. This field is actually a foreign key on the country reference table (NmsCountry), which contains the country labels and other country code data. If the country is not populated, the value ‘XX’ is stored (and is used in place of a zero ID record).
For more on the Recipient table, see this section.
This table matches the nms:group schema.
It enables you to create statical groups of recipients. There is a many-to-many relation between recipients and groups. For example, one recipient can belong to several groups and one group can contain several recipients. Groups can be created manually, via an import or via delivery targeting. Groups are often used as delivery targets. There is a unique index on the field representing the internal name of the sName group. The group is linked to a folder (The key is iFolderId. For more on this, see XtkFolder).
The NmsRcpGrpRel relationship table only contains the two fields corresponding to the identifiers of the iRecipientId and iGroupId linked tables.
This table matches the nms:service schema.
In Adobe Campaign, you can create and manage subscriptions to information services (topics). The NmsService table stores the definition of the information services (topics) that you offer your recipients to subscribe to (a newsletter for example).
Services are entities which are similar to groups (static recipient groupings), except that they circulate more information and enable easy management of subscriptions and unsubscriptions via forms.
There is a unique index on the field representing the internal name of the sName service. The service is linked to a folder (The key is iFolderId. For more on this, see XtkFolder). Finally, the iType field specifies the delivery channel of this service (0 for email, 1 for SMS, 2 for telephone, 3 for direct mail and 4 for fax).
This table matches the nms:subscription schema.
It enables you to manage recipient subscriptions to information services.
This table matches the nms:subHisto schema.
If the subscriptions are managed using web forms or the interface of the application, all susbcriptions and unsubscriptions are historized in the NmsSubHisto table. The iAction field specifies the action (0 for unsubscription and 1 for subscription) performed on the date stored in the tsDate field.
This table matches the nms:delivery schema.
Each record in this table represents a delivery action or a delivery template. It contains all the necessary parameters for performing deliveries (the target, the content, etc.). Delivery (broadcast) logs (NmsBroadLog) and associated tracking URLs (NmsTrackingUrl) are created during the analysis phase (see below for further details on both of these tables).
There is a unique index on the field representing the internal name of the sInternalName delivery or scenario. The delivery is linked to an execution folder (The foreign key is iFolderProcessId. For more on this, see XtkFolder).
It contains all the folders in the tree visible in the Navigation tab of the console.
The folders are typed: the value of the sModel field specifies the type of data that can be contained in the folder. This field also enables the client console to display the data correctly with the corresponding forms. The possible values for this field are defined in the navTree.
The tree is managed by the iParentId and iChildCount fields. The sFullName field gives the full path of the folder in the tree. Finally, there is a unique index on the field representing the internal name of the sName folder.
This set of tables is linked to the Delivery module, which allows to monitor deliveries and eventual issues encountered when messages are sent. For more on this, see Monitoring deliveries. For more on tracking, see Tracking messages.
NmsBroadLogMsg: This table matches the nms:broadLogMsg schema. It is an extension of the delivery log table.
This set of tables is linked to the Marketing campaigns module, which allows to define, optimize, execute and analyze communications and marketing campaigns. For more on this, see About marketing campaigns.
This set of tables is linked to the Campaign Optimization module, which allows to control, filter and monitor the sending of deliveries. For more on this, see About campaign typologies.
This set of tables is linked to the Response Manager module, which allows to measure the success and profitability of marketing campaigns or offer propositions for all communication channels. For more on this, see About response manager.
This table coincides with the nms:remaHypothesis schema. It contains the definition of the measurement hypothesis.
This table contains significant information stored in XML, including:
Execution context (information stored in XML)
The execution context populates the tables and fields to be taken into account for measurement calculation, namely:
Hypothesis perimeter (information stored in XML)
The hypothesis perimeter consists in the filtering of the hypothesis based on the table of the querying schema.
Hypothesis overload script (information stored in XML)
The hypothesis overload script is a JavaScript code which enables you to overload the content of the hypothesis during execution.
Measurement indicators
The following indicators are updated automatically during the hypothesis execution:
This table matches the nms:remaMatchRcp schema.
It contains a record representing an individual’s reaction to a given hypothesis. These records were created during hypothesis execution.
This set of tables is linked to the Simulation module, which allows to test the distribution of offers belonging to a category or an environment before sending your proposition to recipients. For more on this, see About offers simulation.
This set of tables is linked to the Interaction module, which allows to respond in real time during an interaction with a given contact by making them a single or several adapted offers. For more on this, see Interaction and offer management.
The following set of tables is linked to the Transactional messaging (Message Center) module, which allows to manage individual and unique communications sent to a user and generated from events triggered from information systems. For more on this, see About transactional messaging.
This table matches the nms:rtEvent schema. It contains a definition of real time events.
This table matches the nms:batchEvent schema. It contains the definition of events by batch.
This set of tables is linked to the Mobile App Channel, which allows to send personalized notifications to iOS and Android terminals via apps. For more on this, see About mobile app channel.
This set of tables is linked to the Managing social networks module, which allows to interact with customers and prospects via Facebook and Twitter. For more on this, see About social marketing.