Hello,
I'm trying to find a way to manage the segments within partitions in a central way.
Let's assume I have 4 different partitions:
All of these partitions need to have 3 different Marketable segments:
All of these segments need to have common and specific criteria to have the correct members inside them.
I'd like to achieve a single and central way to manage the common criteria. For example, as of now, I have replicated for each segment for each partition these following conditions - so 12 times:
Since I cannot use Smartlist and segments inside Segment filters, how can I manage those criteria in a single point, and avoid replicating these for each segment for each partition?
Having a single management point will help avoid manual errors and give us a vision of the "common" filters.
Thanks,
Gianluca
Solved! Go to Solution.
Unfortunately, there’s no such thing as common filters in this context.
Segmentations deliberately don’t allow nested logic because they’re resource-intensive enough as it is and constantly checking nested dependencies would be a nightmare!
Thanks, @SanfordWhiteman ,
this makes total sense, also because I can feel the problems having recursivity between segmentation.
What about using a dedicated partition for an "exclusion segment"?
Let me say that we have 2 types of NOT-Marketable problems:
1. Total un-deliverability (for GDPR opt-out, or other marketing reasons)
2. Partial un-deliverability (ex: if is on an engagement program, we mustn't send any newsletter).
The solutions could be, respectively:
1: I can use the block listed field to totally block any send to the person whatever could be his position on the partition.
2: Move people to temporary exclusion partitions (not shared to any workspace) for not sending them any active newsletter. So they can still receive operational emails or particular email programs.
So I can use my centralized logic to move people between partitions. So, instead of having filter criteria for exclusion into the segments, I know that those segments will work directly within the partitions, and I will have criteria for only targeting people.
Unfortunately, there’s no such thing as common filters in this context.
Segmentations deliberately don’t allow nested logic because they’re resource-intensive enough as it is and constantly checking nested dependencies would be a nightmare!
Thanks, @SanfordWhiteman ,
this makes total sense, also because I can feel the problems having recursivity between segmentation.
What about using a dedicated partition for an "exclusion segment"?
Let me say that we have 2 types of NOT-Marketable problems:
1. Total un-deliverability (for GDPR opt-out, or other marketing reasons)
2. Partial un-deliverability (ex: if is on an engagement program, we mustn't send any newsletter).
The solutions could be, respectively:
1: I can use the block listed field to totally block any send to the person whatever could be his position on the partition.
2: Move people to temporary exclusion partitions (not shared to any workspace) for not sending them any active newsletter. So they can still receive operational emails or particular email programs.
So I can use my centralized logic to move people between partitions. So, instead of having filter criteria for exclusion into the segments, I know that those segments will work directly within the partitions, and I will have criteria for only targeting people.
I like your creativity here, seems like the only-slash-best way. Just test to make sure nothing unexpected happens when someone is in a Smart Campaign in WS 1 and you shift its partition.