Segmentation Setup - Cloud Best Practice

[jan_kaemmerle]

Hello Colleagues,

currently my customer is working with SAP Marketing On-Premise 1809. There we did setup our own custom segmentation.
This includes

• Z-Views/Data Sources
• Z-Segmentation Object
• Z-Attribute Groups
• Z-Segmentation Profiles

Now we are switching to SAP Marketing Cloud 1902.
On the one hand side this is a great opportunity to go back to standard, so using standard Segmentation Profiles/Objects. On the other hand the customer is used to his own attribute groups, so structure of the segmentation, logics, etc.

What I'm currently struggeling with is to what depth we should use custom functionality vs standard.
And in addition, if we use standard, in which detail we can/should adopt it. Especially in regards to upcoming releases (customizing-comparison).
Below a few examples what we try to achieve:
- Enable/disable attributes
- Renaming attributes
- Changing the assignment of attributes to attribute groups
- Use additional custom attribute groups
- Use additional custom data sources
- etc.
- Problem is that we can not predict what requirement will come in future that we have to cover… 🙂

So should I now create right away a custom segmentation object? Or try using the standard segmentation object and adopt it? In what detail can I adopt it? What happens in case of a new release, are my changes overwritten or do I have to do with each upgrade a customizing comparison? Etc.

Hope it's more or less clear where my problems are laying.

Best regards & thanks,
Jan

[sebastian_schipplick]

Hi Jan,

let me provide some general answers for your questions - feel free to ask for more details if needed.

A)

A customizing comparison is not required anymore for segmentation customizing / configuration since release 1708/1709 (also for on-premise). In 1705/1708/1709 we fundamentally changed the metadata handling of segmentation and target group, so that we have separate layers for the different configuration "owners":

• SAP-owned configuration (earlier "delivery customizing")
• extension-configuration (e.g. via custom fields, custom business objects)
• custom-owned configuration (any manual changes done via app "Segmentation Configuration")
• system-local extension/generation (e.g. scores added via "Simple Score" app)

In general all configuration done on a higher layer is overruling configuration from lower layers on table-row level, i.e. a changed configuration in "custom" layer is blocking all changes to this row in "extension" or "SAP" layer. Two examples:

• if you set an attribute from SAP-delivery to visible via configuration-app, any change to this attribute (e.g. changed position, changed attribute-group) within the SAP-delivery will not become visible for you / SAP-changes will be hidden.
• if you create your own attribute group, and assign an attribute to this attribute group, this attribute will also be blocked for further changes in SAP-delivery. The attribute group itself is only available in layer "custom" and hence will not be affected by any other changes anyways.

Such kind of changes are "upgrade-safe" without any manual intervention, which is also the general guideline for all changes: upgrades must not change/invalidate any custom settings / custom configuration / custom data.

Edit: Just one technical detail to add: for SAP-delivered segmentation objects we ensure that attribute visibility is not changed in later releases (and we ensure attribute groups are not changed for visible attributes as well)

B)

We recommend to use the standard segmentation objects in the cloud, unless you need different segmentation-object-keys (e.g. multiple keys). The standard segmentation objects are supported in the complete marketing cloud application - custom segmentation objects have some restrictions, like e.g. no "Add Custom Field" / "Add Custom Business Object" for custom business objects. Creating custom attribute groups for standard segmentation objects is possible and should not do any harm.

We recommend to use the standard segmentation profiles in the cloud, unless you need to differentiate the segmentation population and/or segmentation attributes between different user groups.

For data sources there are extension-data-sources automatically generated when you add custom fields to your segmentation object. This extension-data-source should then be used _instead_ of the standard base data source of the segmentation object (the extension-data-source contains all standard and custom fields). Further custom views can be added if something beyond custom fields is needed (for every custom business object you get one view and datasource generated automatically). General recommendation is still to keep as many attributes as possible in the one central (star join) data source. So if you have several custom views (generated or for custom BOs) with heavily used attributes, it may be necessary and sensible to create one consolidated custom view which replaces the extension-data-source and all your custom-business-object-views.

Thanks & regards,
Sebastian

[vervinckt_joyca]

Hi Jan!

I struggled with the same questions the first time I went from onprem to a cloud project.

Thanks Sebastian for your excellent explanation and the technical details behind it, I knew upgrades weren't affecting the changes I made to the standard objects, but I didn't know why 😛

I usually do create custom Segmentation Profiles, but based on standard Segmentation Objects. As often, we need a profile per Marketing Area so with a filter. (so as Sebastian said if you need to differentiate the population).

PS: the Z-(HANA)-views are the most difficult ones, as you can't model in your actual HANA database directly, you need to model in a separate instance (without your actual data)... But there's a nice blog from Maik Offerle about this: https://blogs.sap.com/2018/12/17/how-to-model-custom-sap-hana-views-for-sap-marketing-cloud-in-your-... / https://www.sap.com/cxworks/article/453913143/How_to_Model_Custom_SAP_HANA_Views_for_SAP_Marketing_C...

Kr,

Joyca