Scalability, segmentations and instance-wide business logic

[Victor_Herrero]

Hi, 

I know the title of the post sounds almost like a dissertation (and maybe it should be 🙂 ). 

To give a bit of context, the company I work for is multinational, we work with more than 20 markets. Our content is dynamic and we use a main "Country" segmentation to control this. 

Several times I have come across filters in our emails that only include a subset of countries for that specific email, or also in business logic campaigns (unqualify automatically if this and that is true).

What this results in, of course, is in outdated logic and a lot of different lists of countries in filters that need to be maintained, to the point where it is almost impossible to remember which country should get what or what rules should apply to what country, or more than that, simply remember which smart campaigns need updating after every request to change the business logic. 

There should be a way to handle this in a more scalable / clean way. I was thinking of using segmentations to have some sort of "central" control panel where things can be turned on and off, but I can also see it can get out of hand easily, if each segmentation only has one purpose. 

For instance, let's say i want to activate / deactivate welcome emails for a subset of countries (each country has different, changing needs) - I would need a segmentation like "Welcome emails switch" with segments "active" and "inactive", where I include all countries for which they should be active and vice versa. 

Let's also say, there is a specific logic rule like "Unqualify if no Driver's license" with segments "active" and "inactive". 

I also have an MQL segmentation, which contains the MQL threshold for each country

I could keep doing this for every single email really and every single logic rule, so way more than the 20 segmentations included. On top of that, for every release of a new Market, I would need to go into all of these segmentations, add the new country in the right state (active / inactive) and re approve. 

So should segmentations even be used like this? (use them exclusively for content personalization or also for logic)

Should they have only one purpose or multiple? (to try to get around the 20 segmentation limit - which i know can be increased... )

[Carrie_Chandle1]

Hey @Victor_Herrero 🙂

You said it well here:

---

I could keep doing this for every single email really and every single logic rule, so way more than the 20 segmentations included. On top of that, for every release of a new Market, I would need to go into all of these segmentations, add the new country in the right state (active / inactive) and re approve. 

---

By approaching your email criteria as individual segmentations, you'll quickly run out of your 20 segmentation allotment, and it will be difficult to manage. Think of segmentations as multi-use; they're a great way to make sure you're using the same criteria across assets and smart lists, and a way to insert dynamic content across assets. 

If you have use cases to include/remove individuals in email campaigns based on their country, take a look at any campaigns that may be similar (i.e. you have three email campaigns that will all have the same country include/exclude lists) to help centralize these efforts. In addition to that, you may want to build in a documentation process to make sure the team knows which campaigns need to be managed on an ongoing basis and when they were last updated.

Take a look at these related resources, too:

https://nation.marketo.com/t5/Product-Blogs/Marketo-Segmentation-Marketo-Success-Guide-Sneak-Peak/ba...

https://nation.marketo.com/t5/Product-Discussions/Segmentation-List-Building-Best-Practices/td-p/144...

[Phillip_Wild]

Hi Victor, 

...I feel you! We are an international company who operate in five major markets, but we sell all over the world. Different opt in rules (CASL vs GDPR vs CAN-SPAM), different languages...however, luckily we seem to have things more centralised in terms of business logic (no different MQLs or anything like that).

You mention that you would like something like a "welcome email switch", where you make the change in one place. But aren't your welcome emails already sent out of one place? If you have architecture that has duplicated spots where things are happening, that can make it more complex to update.

If you have one smart campaign which says "send welcome email", then your switch to turn it on and off is the filter on that smart campaign. If country is x, let through, if y, don't. We do a similar thing, and then use email script tokens to personalise all aspects of the email (language, footer details etc). You could use dynamic content via segmentations too though.

Similarly, if you have a field called "qualified", then you could have a nightly batch campaign that says "if driver's licence is not populated, qualified is true, and person is from one of these x countries, then mark qualified as false". Keep that list of countries updated, and there's your switch.

I doubt it's as simple as this in your instance, but if you can break your flows down into more modular components, then you might find it easier to have the simple "switches" that you describe. Hope this helps!

[Victor_Herrero]

Hi @Phillip_Wild , 

Modularity is the key point here. I try my best to make every new thing modular and refactor everything I see has repetition as much a I can, but it's a hard case to argue to spend time changing something that already works instead of working on new things that bring new value. 

Although... do they really work? Because I keep seeing cases where something set up years ago by someone else is now outdated or has stopped working and nobody knows or realizes. 

The keys here would be: build it modular and document as @Carrie_Chandle1 suggests, perhaps even build alerts to know when something stops working (this can be quite tricky, but we are also trying). We just have a lot of debt in that respect I guess. Maybe because the team was always small, maybe because of rushing or simply not knowing better. 

Do you have any tips for keep centralized and up-to-date documentation? I think the pain points with it is finding a system (confluence? Excel?), and a structure (Diagrams? Tables? Lists? just text?) that will be clear and easy for everyone and at the same time not a pain to update, otherwise there is the risk of skipping the documentation step, something even I do when I'm stressed or in a rush. 

With the welcome email example, I guess you were spot-on: if we have a campaign that says "send welcome email". We have several, sadly. Because we have two types of customers (you could almost consider them different businesses), and also because there are several different welcome emails so be sent depending on country and entry point. 
Our welcome emails are an example of something that clearly needs refactoring, there should only be one campaign sending welcome emails (or 1 per type of client) where the right filters / choice steps / segmentation will determine which email you get. 

The reason I wanted to use segmentations for logic rather than just personalization (we only really personalize based on language anyway, for now...) is precisely modularity. Whether or not to use a segmentation or just the field in particular perhaps depends on how much the segmentation can be re used. As much as possible, my aim would be to just go to one place to make the changes, but maybe i need to present clear situations to explain what I mean. 

[Phillip_Wild]

No tips on keeping centralised documentation really beyond the obvious - make it accessible to everyone, put it in a central place, etc etc.

I've become much better at this, but not everyone reads the documentation...you can only do so much.

We are in a lucky position is that all comms are centralised and come from a team that is in the same office. So miscommunications in terms of process are minimised a bit, but that's not really due to anything I've done 🙂

Happy to look at any other examples that you have, however it does sound like you know what you are doing so unsure how much additional value I could add.