*NOTE: this question was originally asked using the term "seed list". I use that to mean a group of contacts to enroll (or seed) into a marketing campaign. I am essentially talking about a smart list with advanced filters!
I'm working on increasing the nuance of our marketo programs, and want to make sure I build out seed lists in a scalable way.
Today we send marketing newsletters and content announcement emails to our entire marketable database. We are moving in the direction of using targeted seed lists (smart lists with advanced filters) to subsegment who we send offers to, but it's looking like some seed lists will get reused across multiple programs - either an identical seed list used a few times, or nearly identical versions with small variations. I'm looking for suggestions on where to store these seed lists.
I don't love the idea of nearly identical, or identical, seed lists in every program. If we want to change filters, we'd need to change them in a variety of places. If we make changes over time for one-off campaigns targeting similar personas, it would be hard to remember which program had the most current set of filters. I'm thinking of building a library of these seed lists in the database section, but that also has limitations: if our database seed lists have more filters than what a program needs, we'd end up rebuilding the smart list as a local asset within the program anyway.
Wondering what others have done in this domain. Thanks!
I feel you're changing the standard connotation of a "seed list" (though admittedly there's no official definition) and that's going to create confusion when other people look at your question.
Typically a "seed list" isn't about narrowing marketable leads but rather ensuring that internal employees (or perhaps outside reviewers) get a copy of every email to ensure branding, design, etc. That list of people is a "seed" as in: membership in that (Static or Smart) List is central to every other Smart List.
So it sounds like you're talking about a set of global Smart Lists, but then I also wonder how your notion differs from that of Segmentations, which are a lot like shared Smart Lists, though with well-known nuances about unsupported filters.
As Sanford clearly mentioned that seed list is basically a list, which includes internal employees or group of people to test and quality check the emails. And usually this list remains constant.
If you are looking for smart lists then in that case you may have to create multiple lists based on the type of campaigns you launch for example - we have smart list of contacts to be removed from all the campaigns and use this list everywhere and it is not required to be updated for every campaign.
I like that.
Here are a few ways we do this:
Thank you for your acknowledgement 🙂 and also sharing the insights.
Ok I have updated the discussion prompt title and added a note to clarify that when I use the term seed list, I mean a smart list of contacts who I am enrolling in a marketing program.
The reason I'm not thinking about segmentations is because these smart lists are not mutually exclusive. Some campaigns will enroll contacts with a specific use case need AND job title. Other campaigns will enroll contacts with the same use case, but excluding certain job levels. And some campaigns will repeat identical smart list filters, while others will make small adjustments.
Perhaps it's worth building a segmentation with specific use cases (since those are the ones with the complex logic filters), and then local smart lists can further refine the audience.
Keep in mind that you are limited to 20 segmentations in your instance. So your segmentations should be used for mutually-exclusive segment criteria that will be used in many programs. So for example: you might want to create a job title segmentation to create segments for the job titles that you typically target. Then you can use that segmentation filter in other smart lists to easily identify a person who is a member of a particular job title segment.
To add to the suggestions already made, creating these global smart lists is an excellent way to centrally manage different lists with complex logic. To your original question Amanda Giacobassi: global lists should be stored in the database, not in a program in Marketing Activities.
For every new program that you need to create you would reference the global smart list by using the Member of Smart List filter in the smart list of the program that you are building. This provides the advantage of allowing your program creators to build upon the global smart list to further refine the audience so you don't end up with lots of very similar permutations in the global lists. This can also be accomplished using Segmentations as Sandford mentioned above if you are working with mutually-exclusive segment criteria.
The way I handle this kind of setup is by creating Global smart lists within the "Marketing Database" section. Do not over complicate this by thinking what if you need to remove/add filter per campaign.
What I would suggest if to create two types of smart lists:
Once you have these set of smart lists, use these as the base line for your list builds and adjust the filters while creating smart campaigns to send out emails etc.
Pro Tip: If you have some pre-defined campaign types with defined audience, create program templates and have the smart campaign setup in advance. This way you can just clone the program and might need to do a little adjustment before the go live.
Definitely agree to put them in the Database. Even better if you can build them into Segmentations if that makes sense. You can lock down which roles can edit Segmentations, which helps prevent any unauthorized changes.
Either way, I recommend keeping a Changelog of changes to anything global in your instance (operational programs, global smart lists, segmentations, etc.) and noting when you make the change and why.