Campaign Build - Segmentation Best Practice
25 min read
Do you have a new digital marketing campaign which you want to realize? Together with your colleagues you have already worked out a campaign brief, describing your planned campaign in detail. You have conceptually defined the target audience, campaign flow, channels and content and now you are ready to put your campaign into action?
We are here to help you with best practices on how to turn your campaign definition into a running campaign in your SAP Marketing Cloud system.
In this article we are going to focus on the Segmentation within the campaign build process. You will learn about a versatile step-by-step segmentation approach, along with tips to build performant segmentation models and avoid common pitfalls.
Before we dive into the details, let us get an orientation where Segmentation is positioned when looking at the campaign operation process (image one).
Image one: Simplified campaign operation process
Segmentation is part of the Build phase within the campaign operation process. As with the other actions during campaign build, Segmentation requires a clear conceptual definition of the campaign to start with.
In case you want to learn more about the preceding Ideate and Define phases, please check out the following articles:
- Campaign Ideation with Design Thinking
- Business Scenarios - Learn How to Articulate Tangible Campaigns
Segmentation is the element in the campaign build process (see image two) which leads to the setup of the target group to be included in the campaign.
Image two: Campaign Build process
The Segmentation is performed on the available contact profiles you have gathered via Profiling in the Marketing system. In most cases, Profiling happens in an automated, ongoing way by integrating contact data from external systems via API calls. Let's assume Profiling is taking care of and we can get to the next step which is Segmentation. The result of this segmentation step is a target group which can be used in a campaign, together with the marketing content that you want to send.
We will not go into more detail on Profiling, Campaign Flow and Content in this article, but rather concentrate on Segmentation best practices. For this we also assume that you are already familiar with the general usage of the Segmentation app within SAP Marketing Cloud. A general introduction on how to use the app and all its features would go beyond the constraints of this article and there is already respective content available. In case you want to learn more about the functions and features of Segmentation we recommend the embedded Microlearning video, as well as the Segmentation section in the Application Help .
Video: Segmentation in SAP Marketing Cloud
Microlearning video: Segmentation in SAP Marketing Cloud
In the following, we are focusing on the main segmentation challenges we have seen at multiple customers. For this we first set the stage by looking at the conceptual definition of target groups.
Defining the Target Group
Based on our experience, marketers sometimes struggle with the precise definition of target groups. Obviously, these unclear definitions are a challenge when it comes to building campaigns in a marketing system. This is especially true for an operational setup in which marketers are responsible for specifying the campaign tactics and an agency or service center is performing the campaign build. To facilitate the clear definition of campaigns and target groups, we recommend the usage of campaign briefings. Please read our article "Learn how to articulate tangible campaigns" to find all the details on campaign briefings.
As part of working with campaign briefings, we recommend the differentiation between inclusive and exclusive attributes for defining target groups. It also makes sense to further differentiate between master data and interaction data in this step.
Let us look at an exemplary target group definition to make this approach more tangible:
A global fashion company wants to run a promotion campaign in North America. In this campaign, the company wants to address female consumers who recently purchased a product and opened marketing emails. The company is running a parallel campaign in New York for opening a new flagship store which they do not want to interfere with. Also, they want to make sure customers who recently raised a complaint or sent an inbound email are not being targeted by the campaign. As last criteria, the target group should not include any consumers younger than 18 years.
This exemplary target group has quite a few attributes and may not necessarily be a standard case. However, we want to explain how such a complex case can be consistently documented and later build in segmentation. As you can see in table one below, we are using four leading questions to qualify the target group.
|Contact Master Data (static, non-transactional)||Contact Interaction Data (behavioral, transactional)|
|Segment Group A: Inclusive Master Data Attributes||Segment Group B: Exclusive Master Data Attributes||Segment Group C: Inclusive Interaction Attributes||Segment Group D: Exclusive Interaction Attributes|
|Leading Question||Which master data attributes (e.g. country, loyalty membership) qualify contacts to be part of the target group?||Which master data attributes (e.g. country, loyalty membership) disqualify contacts from the target group?||Which specific interactions (e.g. product purchased, video viewed) qualifies contacts to be part of the target group?||Which specific interactions (e.g. product purchased, video viewed) disqualifies contacts to be part of the target group?|
Target Group Definition (Example)
Table one: Exemplary target group definition by data type (master data / interaction data) and inclusive / exclusive attributes
This clearly documented target group definition has multiple benefits:
- Let segmentation users know exactly which target group to build.
- Help to structure the segmentation build, resulting in more streamlined segmentation models.
- Serve as a communication method of target group definitions outside of the marketing tool.
- Allow to define target groups for which data points may not be available yet, serving as a basis for an implementation request.
Now that we have the target group definition, we will discuss in the next section how to build up the target group in SAP Marketing Cloud using Segmentation.
Multi-step segmentation approach
The Segmentation within SAP Marketing Cloud is a powerful tool and offers a lot of flexibility. On the one hand, this flexibility is great for building target groups which are very much tailored to your campaign requirements. On the other hand, the segmentation flexibility can also result in some typical challenges:
- Segmentation models which are not build in a structured way can easily become confusing, hard to understand and incorrect.
- Depending on the quality of the segmentation model, the resulting segmentation performance can greatly vary.
- Identifying and correcting errors in unstructured segmentation models is very difficult.
Let us address these challenges by introducing a structured multi-step segmentation approach, along with additional recommendations on how to best build up your segmentation.
We found that the previously shown method to define target groups (see table one above), helps to build up a comprehensive segmentation model. The four segment groups (A-D) by which the target group is described can be used to build up the segmentation flow in subsequent steps:
Start by building Segment Group A, including all the filters for inclusive master data attributes into the flow.
From the Segmentation Group A, exclude all the attributes defined in your Segmentation Group B, by using the "equal-to & exclude" operation.
|3a||Build parallel segmentation branch(es) with the inclusive interaction data (Segment Group C), starting from the root segment. Use one branch per interaction type if you need to further qualify them (e.g. different date range).|
|3b||In case of multiple branches with inclusive interaction data, combine them after you have segmented the individual interaction types. For combining inclusive interactions, you typically use an Intersect operation to represent a logical AND.|
|4a||Build parallel segmentation branch(es) with the exclusive interaction data (Segment Group D), starting from the root segment. Use one branch per interaction type if you need to further qualify them (e.g. different date range).|
|4b||In case of multiple branches with exclusive interaction data, combine them after you have segmented the individual interaction types. For combining exclusive attributes, you typically use a Merge operation to represent a logical OR.|
|5||Subtract the exclusive interaction data branch (Segment Group D) from the inclusive interaction data branch (Segment Group C).|
Intersect the segmentation branch with the master data attributes with the segmentation branch containing the interaction data (build in step 5).
Create your target group on the last segment.
You can examine the previously described steps in image three below.
Image three: Multi-step segmentation on master data and interaction data
In addition to a comprehensive segmentation flow, the separation between master data and interaction data helps to prevent common segmentation mistakes which can happen by mixing master data and interaction data in one branch.
Next to following the multi-step approach as described above, there are further recommendations which help you build your segmentation model. We group these tips into three chapters: Correctness, Usability and Performance. The next chapter provides you with tips on how to avoid common logical mistakes and build correct segmentations models.
Segmentation Correctness Tips
Filtering on Interactions
In general, segmenting on interaction data needs special attention. When you filter on an attribute (be it master data or interaction data), all the following segments will only show contacts which meet the previously defined criteria. This should be kept in mind especially when you filter on different interactions. As soon as you filter on an interaction type (for example "Sales Order"), all the following segments in the same branch only filter on these specific interactions.
Image four illustrates this behavior with two different ways to segment on Sales Orders and Email Opened interactions.
Image four: Filtering on interactions
- Flow A uses one segmentation branch per interaction type and then combines them. It therefore achieves the desired result to select consumers who have made a purchase in the last 6 months and opened an email in the last 4 months.
- Flow B in contrast is filtering on both interaction types sequentially in one branch and returns no contacts, even though it includes the same filters as Flow A. This makes sense if you think about the fact that an "Email Opened" is not the same as a "Sales Order".
This emphasizes our previously given recommendation to use separate segmentation branches per interaction type.
When segmenting on interactions, it is best practice to first select the interaction type and then further specify the interactions in the child segments based on additional interaction attributes like date, reason or channel.
The Difference Between "Equal to & Exclude" and "Not-equal to & Keep"
A common pitfall we have seen is the incorrect usage of the "Equal to & Exclude" and the "Not-equal to & Keep" operations. At first look, it might seem that the two operations mean the same thing. However, there are important logical differences between them. These can especially get tricky when filtering on attributes which have a 1:n or n:m relation to the contact. Table two explains the results of the two operations in more detail.
|Contact to Attribute Relation||
Equal to & Exclude
Not-equal to & Keep:
|Returns all contacts who do not have the specified attribute value||Returns all contacts who have an attribute value (not null) which is not matching the specified value|
Contacts with null values (no value for the attribute) are included
Contacts with null values (no value for the attribute) are not included
example: Interaction Type
Contacts which have the selected attribute value (e.g. have the specified interaction type) are excluded
Contacts which have any other attribute value (e.g. have a different interaction type) are included
Contacts may also have the specified attribute value, as long as they meet the criteria that they also have a different value
example: Target Group
|Contacts which have the selected attribute value (e.g. are member of the specified target group) are excluded||
Contacts which have any other attribute value (e.g. are members of a different target group) are included
Contacts may also have the specified attribute value, as long as they meet the criteria that they also have a different value
Table two: Logical difference between "equal to & exclude" and "not-equal to & keep"
Let us further clarify the logic for 1:n (or n:m) relations with an example. Assume you want to filter contacts on the interaction type "website visit". What are the outcomes of the two segmentation operations?
- "Equal to & Exclude": Selects all the contacts which did not perform a "website visit" interaction. (See segment A on image six below)
- "Not-equal to & Keep": Selects all the contacts which have at least one interaction which is different from a "website visit" (see segment B on image six below).
Image six: Visualizing the difference between "Equal To & Exclude" and "Not-equal to & Keep"
Keeping the above explanation in mind, please make sure you use the correct segmentation operation, depending on the individual use case.
Should you be able to model your segmentation with "Not-equal to & Keep", you should preferably do so, since the exclude operation in "Equal to & Exclude" tends to be more performance intensive.
Filtering on Campaign Members Instead of Target Group Members
A very common requirement in Segmentation is that you filter on recipients of a campaign. Just to name two use cases:
- You want to exclude contacts from a dynamic target group who already received communication from a related recurring campaign.
- You want to include recipients from a specific campaign into a follow-up campaign.
Let's look at an example for the first use case (exclusion) in more detail:
You are running a customer satisfaction survey campaign in Germany which consumers should receive every 90 days, given that they have provided permission. The campaign is scheduled with a weekly recurrence to include new contacts via a dynamic target group. You want to make sure that target group members do not receive a new survey email with every weekly execution, but only if they haven't received the email in the last 90 days (including the current month).
Our proposed segmentation sequence for this use case is shown in image eight below.
Image eight: Filtering on campaign members and actions
In general, segmenting contacts based on campaign interactions can be flexibly achieved by combining the following interaction attributes in one segmentation branch:
- "Campaign ID" and/or "Content ID" (if you want to specify interactions on individual content items)
- "Interaction Type" (e.g. outbound email, click-through)
- "Interaction Date"
This approach to segment campaign members based on campaign interactions can be used more granular than only filtering on the membership in a target group. Therefore our general recommendation is to filter contacts based on campaign interactions, rather than on the target group attribute.
Segmentation Usability Tips
Keep Segmentation Intelligible by Naming Segments
Especially when multiple business users are using the same target groups or filters (live target groups) for their campaigns, it is important that the underlying segmentation model is easy to comprehend. This should include all the segments included in the segmentation model. A simple, but effective way to make your segmentation more comprehensible is the usage of named segments.
Per default, when you created a segment, it will be named according to the segmentation attribute and the values used as filter. This can be sufficient when you filter only on a few attribute values. But quite often, a segment can be based on many attribute values or, in the case of interaction attributes, include a time dependency. In these cases, we recommend the usage of segment names which have been defined by the user. Image seven shows a common example where the segment name which was automatically created based on the filter criteria is not self-explaining.
Image seven: Using segment names to improve readability
In this example, the consumer base is filtered to all consumers which live in Europe. This filter on countries obviously includes a fairly long list of attribute values, which cannot be fully displayed in the segment name. However, by simply renaming the segment to "European countries", the purpose of the segment is easily understandable.
Guideline when to rename a segment
Put yourself in the shoes of another person looking at your segmentation model. Is it easy to understand the meaning of the segment just by looking at the automated name? If this is not the case, you should consider renaming the segment with your own description which should be precise and easy to understand.
Segmentation Performance Tips
In general, the performance of your segmentation models is influenced by a number of factors. Some of these factors are in control of the segmentation user, others are more depending on the underlying data model and are therefore rather in control of the marketing operation team.
The following table three lists the most important performance influence factors.
|Performance Influence Factor||Recommendation||In Control of|
|Segmentation Sequence||The sequence of your segmentation steps can have an impact on segmentation performance. This is a factor which can be influenced by the business user building the segmentation model. For a detailed recommendation, please see the section "Segmentation Sequence" below.||Segmentation users|
|Segmentation Operations||The Segmentation application is translating the UI-based segmentation into SQL statements to query the data. It is important to know that certain operators are more performance intensive than others. Please see the section "Avoiding Costly Segmentation Operations" below for more details.||Segmentation users|
|Segmentation Complexity||Complexity of a segmentation or building block is defined as the amount of ancestor segments for a particular segment and the depth of the segmentation model. You should try to avoid building highly complex segmentation models in order to avoid performance and reliability issues. To safeguard the stability and reliability of Segmentation, SAP has introduces Segmentation Complexity Restrictions.||Segmentation users|
|Data Volume||In general, the higher the data volume (e.g. number of contacts and interactions) you have in your system, the more system performance is required to calculate segmentation results. We strongly recommend that you only keep data (contacts and interaction history) in your marketing system which is required for your marketing activities. This can be achieved by implementing a data retention and deletion policy, as described in our article Implementing Your Data Retention Policy for SAP Marketing Cloud.||
Marketing operation team
|Parallel Occurring Jobs, Processes and Workloads||Keep in mind that there may be other jobs or processes (for example data imports, score calculations or campaign executions) running in parallel to your segmentation activities. You should check with your marketing operation team that your segmentation activities are aligned with these processes to avoid a high load on the system. In this context, you should also check that the scheduled execution of campaigns and other performance intensive system processes are not impacting each other.||Marketing operation team|
Custom Views are a very flexible tool to customize or extend the standard business objects (e.g. Contact or Interaction) you use within Segmentation. However, depending on the number, complexity and performance of these custom views, they can have a high impact on the performance of your segmentation model. In addition to the extension of the standard business objects, Custom Business Objects provide another flexible way to extend your segmentation model.
Our recommendation is to always check whether your segmentation requirement can be achieved with standard attributes before bringing in additional, potentially performance-intensive, custom views and custom business objects. For more details on how to build performant SAP HANA views for Segmentation, you can read our article Best Practice on SAP HANA Modeling for Segmentation.
|Person responsible for data model extensibility|
We recommend to use filter attributes in a sequence from "strong selectivity" to "weak selectivity". This means that you should reduce the volume of your segments early in the segmentation flow. You should also keep in mind that complex attributes (for example Scores and attributes based on custom views) typically require more computation time than "simple" attributes. In most cases, an improved calculation speed can be achieved by placing these performance intensive attributes towards the end of your segmentation flow (with less contacts). Image five shows a simple example on how to apply these two recommendations in a performant filter sequence.
Image five: Filter sequence
You can see in the example that branch "A" has a more selective attribute early in the flow and the more performance intensive attribute at the end. In many cases, an optimized segmentation sequence offers great potential to achieve a significantly faster segmentation calculation time.
It might not always be possible to strictly stick to the filter sequence recommendations mentioned in this section. Nevertheless, especially if you filter on large data volumes with performance intensive attributes, you should try to optimize your filter sequence as good as possible.
Avoiding Costly Segmentation Operations
Contains Pattern and Contained in File
The comparison operators (like "Equal to", "Greater than" or "Contains pattern") which are used when building segments come with different cost in computation. Please be aware that especially the operators "Contains pattern", "Does not contain pattern" and "Contained in file" tend to be performance intensive. This is because they are using regular expressions on data base level to not only select exact value matches, but also values which contain the defined pattern in a text string (e.g. domain within an email-address). In addition, these operators need to convert the data to same case before doing the comparison. You can find more details on case sensitivity on the following help page.
We generally recommend to use the "equal to" operator instead of "contains pattern" if this can be achieved. In case the operation "contains pattern" is still required, you should try to use it towards the end of your segmentation flow, following the recommendation given in the previous section.
Reduce Randomly per Reference Object
Another costly segmentation operation is the usage of "reduce randomly per reference object". A common use case for this operation is the deduplication of email addresses as described in SAP Note 2448963. In case you have multiple contacts which share the same email address, you should check whether this is intended behavior or poor data quality. Typically shared e-mail addresses are common in a B2B context (corporate email addresses), but not in a B2C context. In case the shared email addresses occur due to poor data quality, we recommend you to investigate with your marketing operation team (or implementation partner) why this happens and how the contacts can be corrected.
Same as with the other performance intensive operations, should you not be able to avoid the usage of "reduce randomly per reference object", you should try to only apply it on already reduced data volume towards the end of your segmentation model.
Closing this chapter on segmentation performance, we want to provide you with some tips on how to analyze the performance of your segmentation models.
The easiest way to see the calculation time for a specific segment is to do a mouseover on the segment name, until a box with additional segment information appears. This information box contains the calculation time of the segment. We use the similar example as in the section on Segmentation Sequence, now showing the individual segment calculation times in image six.
Image six: Analyzing calculation time of segments via mouseover
When analyzing the runtimes of the segments, it is best practice to recalculate the segments individually, starting from top to bottom. This approach allows you to try out different segmentation sequences, optimizing the overall runtime of your segmentation model.
A more advanced way to analyze the runtimes within your segmentation model is to use the "Segmentation Diagnostics". Image seven shows how to get to the segmentation diagnostics within the Segmentation app.
Image seven: How to turn on Segmentation Diagnostics
The segmentation diagnostics allow you to trace the runtime of your segmentation model in detail, including runtimes for the individual segments as displayed in image eight.
Image eight: Exemplary segmentation diagnostic including SQL runtime per segment
The segmentation diagnostics can also be exported to a CSV file, which allows you to further analyze the data in external tools like Excel.
In this article you were introduced to best practices in building correct, comprehensible and performant segmentation models to determine target groups for your campaigns. You have learned about a multi-step segmentation approach based on a templatized target group definition, as well as further tips on how to improve segmentation usage.
To summarize, Segmentation in SAP Marketing Cloud is a powerful and flexible tool to create very specific target groups. The great flexibility can also come with challenges on how to optimally build your segmentation model. We hope that our article gave you good tips in mastering Segmentation with confidence.
In case you need further support, please refer to our dedicated 'Campaign Build Guidance' service. You will find more details in the fact sheet that is linked in the services section of this article.