- SAP Managed Tags:
This document describes in a detailed step-by-step approach the preparation and creation of an email campaign with follow-up actions and the execution of all these actions.
It explains
The document distinguishes between the following types of campaigns
The information in this document is based on release 1805 but most described features are available since 1709.
The document consists of 4 chapters:
The first step for an email campaign is the creation of the target group. Usually the target group is created out of a segmentation model. Such a target group has always a relation to a segmentation model irrespective if the target group is marked as dynamic or static. In the target group UI you can create pure static target groups without relation to segmentation model.
It is important to know if the target group has a relation to a segmentation model because it influences in the campaign UI which email content is allowed for use.
The segmentation model has a relation to a segmentation profile which is defined in the segmentation configuration. Every segmentation profile use exactly one segmentation object.
The target group stores also the information about the segmentation object.
This segmentation object has two important aspects for the email campaign and its execution:
The key definition is important because the campaign execution processes contacts, meaning it uses attributes of the contact like email address or language in order to create and send the email.
The key definition of the segmentation object must be mapped to key definition of the target group in the corresponding target group configuration.
Campaign can process target groups and segmentation objects with the following key definitions:
In the email editor one can define if the email shall be personalized by using attributes defined in the segmentation object. The data sources behind this segmentation object are used in generated SQL statements for the retrieval of the personalization values during campaign execution. The definition of the data sources (e.g. the modelling of the assigned database views) influences the performance for the retrieval of the personalization values and hence the performance of the execution of the email campaign.
From the perspective of campaign execution based on dynamic target groups that themselves are based on segmentation models, the concepts of retention period and dependent target groups are important, as well as how these concepts are related to each other.
The retention period defines the time interval after the last rebuild of a target group during which no fresh rebuild will take place. In other words, the retention period defines how long the members of a dynamic target group will remain stable between successive rebuilds. You can set any retention period between 0 minutes and 999 days in the TG configuration application.
Dependent target groups show some kind of logical connection between their members. Such dependency is one of the following:
During the rebuild of a target group, all its dependent target groups as well as their potentially dependent target groups are collected and rebuilt together. This is especially important for randomized segments and control groups to ensure that the target groups have disjoint set of members, i.e. do not overlap in their members.
The retention period is especially important when you execute one or multiple campaigns that are based on such target groups that have other dependent target groups. You may also have multiple campaigns executing in parallel where each campaign is based on one of these dependent target groups, for example when executing three campaigns based on three randomized target groups of the same segmentation model split group segment.
Since during each campaign execution, the underlying target group will first be rebuilt (in case it is dynamic), it is very important that parallel or overlapping campaign executions based on the same set of dependent target groups do not inadvertently destroy the other campaigns dependent target group (by TG rebuild through dependency) as this would lead to unexpected and potentially unwanted campaign results.
Therefore, it is strongly recommended to make use of the retention period to keep dynamic target groups free from too often a rebuild and keep their members stable. If you make use of randomized target groups this is especially important. The duration (interval length) of the retention period depends on your campaign runtimes, and execution schedule.
For example, you have scheduled 3 campaigns to be executed one hour apart from each other once every week, and each campaign execution takes around 100 minutes, you will have for 40 minutes 2 campaigns executing in parallel. If these campaigns are based on 3 randomized, dependent target groups then you want to keep their members stable for at least 3 hours until the last campaign has started. So you would set the retention period no shorter than 3 hours in this case.
You can also make use of the retention period to have the TG rebuild step executed prior to campaign execution, and not during campaign execution itself. This way, you may improve campaign execution runtime and shift database resource usage to an earlier point in time. You can achieve this by scheduling application jobs that trigger a target group rebuild at regular intervals or fixed points in time. Of course, you need to synchronize the application jobs with your campaign execution schedule and choose a retention period long enough to cover campaign execution if dependent target groups are involved.
Example if no retention period is defined:
Adaptation from release 1902 onwards
With release 1902 the executed campaign CPG1 locks the used target group TG1 until it has finished the retrieval of the values of the used personsalization attributes.
Same for campaign CPG2 which locks the target group TG2.
Campaign CPG3 is started while campaign CPG1 is still running. Campaign CPG3 wants to rebuild target group TG3. The rebuild logic detects two dependent target groups TG1 and TG2.
Because TG1 is still locked by the execution of campaign CPG1, the rebuild of target group TG3 is on hold and waits until the lock of target group TG1 is removed.
After campaign CPG1 has finished the retrieval of personalization values, the lock of target group TG1 is removed and the rebuild of target group TG3 starts.
This adaptation prevents that the member list of target group TG1 is changed while campaign CPG1 retrieves the necessary data from this member list.
You can also check the SAP note 2075429 in case you detect issues with segmentation.
Next chapter Email content and usage of personalization attributes
It explains
- the relation of the target group and the email content dependent on the used segmentation object
- the email personalization with usage of different sources for personalization values and how you can influence the retrieval of the personalization values
- the start, pause and stop of a campaign and when follow-up triggers and actions will no longer be processed
- how interactions for follow-up triggers are collected and when follow-up actions are scheduled for execution, depending on advanced and delayed scheduling options
The document distinguishes between the following types of campaigns
- target group based campaigns, executed only once
- target group based campaigns, executed periodically, also known as recurring campaigns
The information in this document is based on release 1805 but most described features are available since 1709.
The document consists of 4 chapters:
- Segmentation and Target Group
- Email content and usage of personalization attributes
- Campaign definition
- Campaign execution
1. Segmentation and Target Group
The first step for an email campaign is the creation of the target group. Usually the target group is created out of a segmentation model. Such a target group has always a relation to a segmentation model irrespective if the target group is marked as dynamic or static. In the target group UI you can create pure static target groups without relation to segmentation model.
It is important to know if the target group has a relation to a segmentation model because it influences in the campaign UI which email content is allowed for use.
The segmentation model has a relation to a segmentation profile which is defined in the segmentation configuration. Every segmentation profile use exactly one segmentation object.
The target group stores also the information about the segmentation object.
This segmentation object has two important aspects for the email campaign and its execution:
Definition of the keys
The key definition is important because the campaign execution processes contacts, meaning it uses attributes of the contact like email address or language in order to create and send the email.
The key definition of the segmentation object must be mapped to key definition of the target group in the corresponding target group configuration.
Campaign can process target groups and segmentation objects with the following key definitions:
- one key: key of interaction contact
The business object in the key definition must be CUAN_INTERACTION_CONTACT.
The target group contains interaction contacts as members.
- multiple keys: key of interaction contact plus additional key, e.g. key of product registered for the contact
The first business object in the key definition must be CUAN_INTERACTION_CONTACT.
The next business object in the key definition can be another business object.
The target group contains interaction contacts and its related object (e.g. product) as members.
- one key: key of interaction
The business object in the key definition must be CUAN_INTERACTION.
The target group contains interactions as members.
Definition of data sources
In the email editor one can define if the email shall be personalized by using attributes defined in the segmentation object. The data sources behind this segmentation object are used in generated SQL statements for the retrieval of the personalization values during campaign execution. The definition of the data sources (e.g. the modelling of the assigned database views) influences the performance for the retrieval of the personalization values and hence the performance of the execution of the email campaign.
Retention Period and Dependent Target Groups
From the perspective of campaign execution based on dynamic target groups that themselves are based on segmentation models, the concepts of retention period and dependent target groups are important, as well as how these concepts are related to each other.
The retention period defines the time interval after the last rebuild of a target group during which no fresh rebuild will take place. In other words, the retention period defines how long the members of a dynamic target group will remain stable between successive rebuilds. You can set any retention period between 0 minutes and 999 days in the TG configuration application.
Dependent target groups show some kind of logical connection between their members. Such dependency is one of the following:
- non-segmentation based target groups that are created using set operations on parent target groups
- target groups that function as control groups for other target groups
- segmentation-based target groups of the same segmentation model that are connected in their segment tree path by one or more randomized segments. This may be a randomized split group or any other randomized segment that both target groups share in their common paths towards the base segment.
During the rebuild of a target group, all its dependent target groups as well as their potentially dependent target groups are collected and rebuilt together. This is especially important for randomized segments and control groups to ensure that the target groups have disjoint set of members, i.e. do not overlap in their members.
The retention period is especially important when you execute one or multiple campaigns that are based on such target groups that have other dependent target groups. You may also have multiple campaigns executing in parallel where each campaign is based on one of these dependent target groups, for example when executing three campaigns based on three randomized target groups of the same segmentation model split group segment.
Since during each campaign execution, the underlying target group will first be rebuilt (in case it is dynamic), it is very important that parallel or overlapping campaign executions based on the same set of dependent target groups do not inadvertently destroy the other campaigns dependent target group (by TG rebuild through dependency) as this would lead to unexpected and potentially unwanted campaign results.
Therefore, it is strongly recommended to make use of the retention period to keep dynamic target groups free from too often a rebuild and keep their members stable. If you make use of randomized target groups this is especially important. The duration (interval length) of the retention period depends on your campaign runtimes, and execution schedule.
For example, you have scheduled 3 campaigns to be executed one hour apart from each other once every week, and each campaign execution takes around 100 minutes, you will have for 40 minutes 2 campaigns executing in parallel. If these campaigns are based on 3 randomized, dependent target groups then you want to keep their members stable for at least 3 hours until the last campaign has started. So you would set the retention period no shorter than 3 hours in this case.
You can also make use of the retention period to have the TG rebuild step executed prior to campaign execution, and not during campaign execution itself. This way, you may improve campaign execution runtime and shift database resource usage to an earlier point in time. You can achieve this by scheduling application jobs that trigger a target group rebuild at regular intervals or fixed points in time. Of course, you need to synchronize the application jobs with your campaign execution schedule and choose a retention period long enough to cover campaign execution if dependent target groups are involved.
Example if no retention period is defined:
You have defined 3 dependent target groups TG1, TG2 and TG3 which are used in 3 campaigns CPG1, CPG2 and CPG3.
Campaign CP1 and CPG2 start at the same time at 10:00. For both campaigns a rebuild of the target groups will be done (because no retention period is defined). Both rebuilds are running in parallel but only one does the rebuild, the other one waits until the first one is finished and does no rebuild.
The rebuild of target group TG1 forces a rebuild of dependent target groups TG2 and TG3 too.
After rebuild is done the execution of campaign CPG1 and CPG2 starts sending the emails EM1 and EM2.
Campaign CPG2 ends at 10:07 because the size of target group TG2 is smaller than TG1.
At 10:12 Campaign CPG3 starts. It starts with the rebuild of target group TG3 because no retention period is defined.
The rebuild of target group TG3 forces a rebuild of dependent target groups TG1 and TG2.
While target group TG1 is rebuilt the execution of campaign CPG1 cannot access the members of this target group.
Adaptation from release 1902 onwards
With release 1902 the executed campaign CPG1 locks the used target group TG1 until it has finished the retrieval of the values of the used personsalization attributes.
Same for campaign CPG2 which locks the target group TG2.
Campaign CPG3 is started while campaign CPG1 is still running. Campaign CPG3 wants to rebuild target group TG3. The rebuild logic detects two dependent target groups TG1 and TG2.
Because TG1 is still locked by the execution of campaign CPG1, the rebuild of target group TG3 is on hold and waits until the lock of target group TG1 is removed.
After campaign CPG1 has finished the retrieval of personalization values, the lock of target group TG1 is removed and the rebuild of target group TG3 starts.
This adaptation prevents that the member list of target group TG1 is changed while campaign CPG1 retrieves the necessary data from this member list.
You can also check the SAP note 2075429 in case you detect issues with segmentation.
Next chapter Email content and usage of personalization attributes
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
