Hey Andy Varshneya. I don't think Kristen has access to this group at the moment. But, let me shed my 2 cents after what we discussed last night:
Ironically, I ran in to this issue this morning. I had 1 smart list that referenced another smart list in order to pull a lead list... It took 20 min to return the total leads. So, yes, smart lists DO slow down your ability to pull data. Depending how you call them from your day-to-day routine would determine whether it will slow down your instance. Generally I see that complicated or nested smart lists are used to send an email, or run an ad-hoc report -- therefore, those reports or campaigns will take longer to run... if you use them in normal lead routing or other enrichment flow steps, then yes, your instance will likely be slower.
Segmentation are different. Segmentations actually store data values as lead data -- essentially they ARE a static list. Therefore you shouldn't see any performance impact for that dataset.
I've pinged Kristen to ask her about how she manages her static lists that replace her smart lists; whether they are batched daily, triggered off data value changes, and how granular she gets in the 'add to' and 'remove from' smart campaigns that manage the lists. I've begun building a few myself, but will let everyone know her response when I get it. If anyone else has a method to share, I'd be more than open to hearing about it.
Good seeing everyone last night - can't wait for the panel session in December!
Got it, thanks for that insight. My question was revolving more around the forgotten smart lists that may have been created at some point in the past for a one-off but aren't being used actively. Sounds like they won't impact instance performance unless actually run or referenced?
You've also brought up an interesting use case with emails. Would the more efficient way to process that would be to create a trigger or batch campaign with those same rules, and then use "Add to List" in the flow, and reference that static list via a trigger or filter in the email send?
Yah, precisely. I really like the idea of using these static lists, but I've had some issues with triggers before; You either need a trigger for standard processes, and a secondary batch to make sure you get them all. So, for this, I just went with basic daily-recurring campaign batches at midnight to populate the list:
Two of those campaigns add to the list (for audit tracking) and one removes them if they become different or bad criteria.
So far so good... just not sure how bad it is to have a bunch of these updating campaigns run every day... I do it at off-hours just to be safe, but will update if I find out more.
I finished building the static list and it just updated in less than 2 minutes. Mission accomplished.