Campaign Build - Segmentation Best Practice

[JohannesPfalzgr]

Disclaimer

This article has previously been published on the SAP CX Works platform, which is no longer accessible. The content is still relevant for SAP Marketing Cloud users, so the article is now republished as a blog on SAP Community.

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.

Introduction

Before we dive into the details, let us get an orientation where Segmentation is positioned when looking at the campaign operation process (illustration-1).

Illustration-1: 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.

Segmentation is the element in the campaign build process (see illustration-2) which leads to the setup of the target group to be included in the campaign.

Illustration-2: 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 Segmentation section in the Application Help.

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.

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.

	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)	Country: United States OR Canada AND Gender: female	City: New York OR Age: Below 18 years	Has made a purchase within the last 6 months AND Has opened a marketing email in the last 4 months	Has raised a complaint within the last 3 months OR Send an inbound mail within the last 2 weeks

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 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:

• Step 1: Start by building Segment Group A, including all the filters for inclusive master data attributes into the flow.
• Step 2: From the Segmentation Group A, exclude all the attributes defined in your Segmentation Group B, by using the "equal-to & exclude" operation.
• Step 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).
• Step 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.
• Step 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).
• Step 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.
• Step 5: Subtract the exclusive interaction data branch (Segment Group D) from the inclusive interaction data branch (Segment Group C).
• Step 6: Intersect the segmentation branch with the master data attributes with the segmentation branch containing the interaction data (build in step 5).
• Step 7: Create your target group on the last segment.

You can examine the previously described steps in illustration-3 below.

Illustration-3: 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.

Illustration-4 shows this behavior with two different ways to segment on Sales Orders and Email Opened interactions.

Illustration-4: 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. 

✔️ Best practice
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. The following table 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.
1:1 Relation Example: Country	Contacts with null values (no value for the attribute) are included.	Contacts with null values (no value for the attribute) are not included.
1:n Relation 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.
n:m Relation 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.

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?

1. "Equal to & Exclude": Selects all the contacts which did not perform a "website visit" interaction. (See segment A on illustration-6 below)
2. "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 illustration-5 below).

Illustration-5: 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.

✔️ Best practice
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:

1. You want to exclude contacts from a dynamic target group who already received communication from a related recurring campaign.
2. 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 illustration-6 below.

Illustration-6: 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. Illustration-7 shows a common example where the segment name which was automatically created based on the filter criteria is not self-explaining.

Illustration-7: 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 list displays the most important performance influence factors.

Segmentation Sequence

• In control of: Segmentation users
• Recommendation: 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 Operations

• In control of: Segmentation users
• Recommendation: 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 Complexity

• In control of: Segmentation users
• Recommendation: 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.

Data Volume

• In control of: Marketing operations team
• Recommendation: 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.

Parallel occurring jobs, processes and workloads

• In control of: Marketing Operations Team
• Recommendation: 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.

Segmentation Extensibility

• In control of: Person responsible of data model extensibility
• Recommendation: 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.

Segmentation Sequence

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). Illustration-8 shows a simple example on how to apply these two recommendations in a performant filter sequence.

Illustration-8: 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.

✔️ Recommendation
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. 

Segmentation Diagnostics

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 illustration-9.

Illustration-9: 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". Illustration-10 shows how to get to the segmentation diagnostics within the Segmentation app.

Illustration-10: 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 illustration-11.

Illustration-11: Exemplary segmentation diagnostics 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. 

Conclusion

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 the article gave you good tips in mastering Segmentation with confidence.