Flow filters vs Conditional Splits

I agree with @ebusiness pros - a lot of this is down to your organizational preferences and to some degree your reporting needs. I’ve mentioned this before in other threads, but if you zoom out, you basically have two broad approaches:

1. Breadth - Lots of Flows (many sharing the same Triggers), generally smaller or lightweight by utilizing Flow Filters to properly silo each cohort of audiences into their respective Flows.
2. Depth - Fewer Flows, each one generally being monolithic, and using conditional branching within each Flow to separate the cohort of audiences.  

Obviously, you can mix and match a bit, and in some areas (like Abandoned Checkout/Cart) you may prefer one approach vs the other.

Here’s a few pros/cons of each, where in some cases the pro in one is the con of the other.  

Breadth Structure:

• Pro: Flow aggregated reports and data are easy to see at a glance at the top level.  No need to open each Flow to see the analytics.
• Pro:  Flows are focused on a specific cohort of users so its easy to contextualize the entire Flow.  Once you’re in one Flow, it can be easier to follow or know what’s going on.
• Pro: Since each Flow is more manageable on its own, the delegation of certain Flows to particular team members or with external/internal colleagues might be more efficient.  This sort of depends on how you Filter the Flows. (e.g. Jane optimize only the High Cart Value Flows, John optimizes the Low Cart value Flows, etc).  Also, it’s easier to jump into a specific Flow, understand what its doing, and start making improvements to it faster.
• Pro: A/B Testing Flows is easier, it doesn’t mess up anything downstream (or upstream).  You can also just quickly duplicate Flows (and turn off Flows).
• Pro: In essence, Flows are just more modular and more focused by nature - this makes each piece more nimble to try different things - there aren’t any dependencies or some monolithic structure to understand before you try different things in the Flow. 
• Con: More Flows can make things at the top level view seem overwhelming
• Con: Managing Flow Filter Rules (and mutex) can be cumbersome.  If not properly QA’d, you might accidentally have people going into multiple Flows at the same time (esp. if you don’t have Smart sending enabled as your first line of defense).
• Con: The flip side of the data fragmented to each Flow is that if you wanted an aggregation of a group of Flows (e.g. All Abandoned Checkout) - requires you to do some downstream aggregation (PivotTables, Scripts, etc).  
• Con: It’s hard to see the big picture - you may need a separate visualization to map out what’s going on in the account.

Depth Structure:

• Pro: Flow aggregated reports pretty much centered around the major metrics (events) triggers or Segments in your account.  They line up well, so you can sort of follow “the one Flow” for each Trigger.  Example: a single Flow is the “one welcome series” for all new subscribers, the giant Post Purchase Flow is for all peopel who “Placed Order” etc.  
• Pro: Less Flows, less headaches. For some brands, there just isn’t a need for super complex Flows.  Keeping the number of Flows down makes this more manageable and easier to grasp.
• Pro: Easier to see the big picture. Everything is laid out in a way that it’s visually easy to follow each of the branches, the analytics also show you the percentages at each junction. 
• Pro: Less likely that people will overlap.  You still have to do some Flow Filters to make sure someone isn’t in more Flows (at the same time) as they should be, but because there are just less Flows overall, it’s easier to map these out. 
• Con: If a Flow becomes massive, I sometimes call these “Pachinko Machines” - they can start to get messy and confusing.  Although you can zoom out (or get a bigger screen), each time you open a Flow, it feels like you have to re-learn or re-process everything before you can get started.  
• Con: Aggregated reports lose a lot of granular fidelity.  Sure, the Abandoned Checkout Flow made X revenue, but for which cohort/path of the Flow?  You almost have to open each Flow to inspect the Analytics.  Although this is a good practice to always look at the detailed view of the Flow, sometimes you just want to see it at the top level (Flow page) or in the aggregated reports (Revenue for Each Flow) to make sure everything is fine.
• Con: Coordination and collaboration between team members can be complicated.  Since everyone is working off the same Flow, you have to be careful what you do doesn’t affect other parts of the Flow. This can either make the Flow brittle (easy to break or make errors) or introduce a lot of dependency checking and coordination that slows things down.  Because each Flow is massive and complicated, it can also become bottlenecked by someone (or agency) for even minor changes or updates. 
• Con: A/B Testing or Random Sampling can get super messy.  You start getting these huge pathways and trees of message sequences because each one has to stay in the context of the A/B Test.  For example, if the A/B Test was that one group gets OfferA, and another group gets OfferB, you’ll have to keep these two groups separate, or keep branching them out further down the Flow.  Many times a seemingly simple A/B test will have this cascading tedious work of downstream messages to rework.

So this turned out to be quite the post, hopefully you get some perspective on which is best for you - in the end, it can totally be a mixture of both so there’s not a clear winner.  Hope this helps!

Joseph Hsieh // retentioncommerce.com // twitter: @retenion