BU structure for MultiCloud setup with Einstein (Marketing, Commerce, Sales/Service)

Question

Challenge

Are there any Best Practices or Solution Kits that give a guideline for BU setup for global Marketing Cloud setups, where Sales/Service Cloud and Commerce Cloud are involved? The specific challenge I'm facing is that the desired operative structure where marketers should work in (country/region based) doesn't match the Commerce Cloud sites (continent based).

Furthermore, the Commerce Cloud sites have the Collect Code in place, that is used for cart/browse abandonment and product recommendations and therefore has to be connected to a specific Business Unit in Marketing Cloud.

Setup Summary

Involved Salesforce Clouds

• Sales/Service Cloud (one instance used globally)
• Marketing Cloud (one instance used globally, structured in multiple BUs (parent BU, another BU layer (business structure), [if approach 2 is used another layer for commerce sites], country/region BUs)
• Commerce Cloud (one site per continent)

Further Setup Information

Einstein browse/cart abandonment and product recommendations from B2C Commerce. Einstein Campaigns/Journeys should be managed on the second BU layer, so not within the country BUs.

Possible Solutions

So I'm wondering which approach is the best mainly regarding scalability and performance:

1. Consolidate Einstein Implementations in one BU higher up the hierarchy (for all Commerce Cloud sites)
   A. done in parent BU
   B. done in the layer below parent and above country-BUs
2. Add another BU layer that matches the Commerce Cloud sites and implement cart/browse abandonment and collect code tracking on that added layer.
3. ?

Hierarchy diagram of Solution 1

Hierarchy diagram of Solution 2

Open Questions

BU Structure

Regarding BU structure nothing specific is mentioned either, just that different business units should be considered if you have different inventory for the same products (speaks for approach 2).

The Marketing Cloud documentation regarding Business Units doesn't give any guidelines that take the cross cloud scenario into account and just mentions that it is an organizational structure meant to fit the "business needs":

Organize the hierarchical structure of business units to match your business needs. Business units can mirror workflow processes, demographic and behavioral data about your subscribers, or your organization's operational structure.

(Source: Business Units in Marketing Cloud)

Performance

Are there any performance benchmarks/considerations available? Is performance an issue here and therefore approach 2 the better option?

The Cross Cloud Solution Kit doesn’t give much information on the performance, except that delta files should be used for more than one million SKUs.

Data pool for recommendations

Considering the accuracy of recommendations there are two main factors that come to my mind:

• Data pool for recommendations is a lot bigger with approach 1
• Smaller data pools with approach 2 could also be beneficial if there is different behaviour in different markets

Answer 1

After a lot of research, engaging with Salesforce, Salesforce MVPs, etc. and still no standard best practices applicable to that Multicloud Setup, I had a very productive workshop together with some very knowledgable and experienced Salesforce Architects for Marketing and B2C Commerce Cloud.

Workshop conclusions

During this workshop we discussed that as already anticipated, there is no solution that fits all, but basically these are the most crucial considerations:

1. Consider which access restrictions need to be in place, as data access can only be done on BU basis
2. For which parts/divisions of the business do you need separate branding (SAP including CloudPages URLs, Image-URLs, Click-Tracking-URLs)

3. Cross-Cloud perspective/restrictions:

   • One Einstein data pool per BU

     • If data pools should be grouped in the same way for SFCC and SFMC Einstein recommendations (which are different and not related Einstein products), the BU structure needs to match SFCC sites (approach 2), but technically it doesn't have to.
     • If you know your customers in different markets/regions behaviour varies significantly, it is a good idea to split their data pools (however, group similar markets, separate core markets and group smaller markets to have enough data for meaningful recommendations)
   • Consider Stock availability (make sure that warehouses and SFCC sites / BUs match so you don't recommend products that aren't available in that region)

Further considerations

• Standard reporting is based on BU level, so if you need reporting to be broken down further, you either need to use custom reporting or split the BUs
• Try to keep things simple and reduce the number of BUs if possible, given the mentioned restrictions

Some Pros / Cons of regions/teams sharing a BU

|       Category      |                             Multi-Regions/Teams per BU                                   |                               Single Region/Team per BU                                   |
|                     |                    +                    |                        -                       |                     +                     |                       -                       |
|:-------------------:|:---------------------------------------:|:----------------------------------------------:|:-----------------------------------------:|:---------------------------------------------:|
| Data & Integrations | Simplified                              | Country data quality may not be consistent     | Data model can differ per BU              | Increased number of integrations to maintain  |
| Content             | Easier to share & re-use                | -                                              | Dedicated content possible                | Increased effort to share content between BUs |
| Einstein            | Data pool is enriched by larger dataset | Individual region recommendations not possible | Regions have separate data pools          |                                               |
| Branding            | Consistent branding across regions      | Shared URL branding for SAP                    | Each region can have independent branding | -                                             |
| Governance          | Easiser maintenance                     | Increased risk of user error                   | -                                         | Increased effort to maintain across BUs       |
| Security            | Simplified                              | Country level security not possible            | More granular permission management       | Increased maintenance                         |
| Reporting           | Report across all regions/teams in BU   | No region/team filters in standard reports     | Individual reports per region/team        | No standard report across all regions/teams   |

We weren't given any detailed performance benchmarks, but it is rather a business process and structure than a performance decision.

So in fact for my use case it will be a hybrid approach, where two region BUs are consolidated, to match the sites for organizational unit 1, but if certain regions need to be split for data access reasons, the solution would be approach 2.