Hi @michaeljja, 

Thanks for sharing your question with us! 

Yes that is definitely one way to accomplish this goal! However, I would love to hear one of Champion’s input, as I know @retention has a lot of experience and strategies to implement for a/b testing! 

Do you mind sharing why you’re adding these form submission to two separate lists? If you are adding different hidden profile properties for each form, you could add these submission to the same list to reduce the workload.

Additionally, would these a/b test subscribers already be subscribers in your main list? If not, it is worth mentioning that uploading new users to a list will trigger them going through any flow connected to this list if they haven’t gone through it before. You could add flow filters to find their properties to to exclude this from happening.

Hope this helps!

-Taylor 

Thanks for the mention, @Taylor Tarpley!
 

So there’s a few way to do this, the method I recommend (Method 1) is very close to what you already have done.  If your goal is to not have to manually add them to the main List, then I would recommend any of the following approaches:

Method 1 - Two Flows, One List

Instead of submitting it to Newsletter 1 and Newsletter 2, I would just submit it to the Main List, and add Flow Filters in your Main Flow to exclude anyone that have those custom properties.  This way, they won’t get what I assume is your Main Flow.  

Then, I would create a new List Triggered Flow, but with a Flow Filter where the custom properties have to be set.  In this Flow, I would use your conditional Split Path to go from Offer 1 vs Offer 2.  

The benefit of this setup:

1. Emails all go the same place (and you can track it when you do your List Growth Reports)
2. Your Offer based Flows are separate from your Main List so you can see those analytics separately (quickly).

Drawbacks:

1. If the two Flows have a lot of common messages.  Example, they are both Welcome Flows, where the first message is the Offer, but there are 7 other emails that are exactly the same after the offer message.  You have to keep maintaining both Flows every time there’s a change in one of the common message. It can be done by using well labelled Templates or Universal Content blocks, but it might be accidentally forgotten.
2. Your analytics for the common messages are split between two Flows.  So if Email #2 is the same in both Flow, you don’t see those analytics combined (even though they are identical) in aggregation reports.

Method 2 - Two Flows, One List, interleaved with Message Filtering

If the only difference between the Offer Flows and the Main Flow is the first (or a small subset) of messages, another way to do this is to have both Flows (Offer and Main) trigger off the same List and use Message Filter Rules to determine which message (Offer) they get between the two Flows.  This means that technically everyone who enter the List goes down both Flows, but the Message Filters determines who gets which message. 

The benefit of this setup:

1. You still get analytics between the “Offer Flow” vs the “Main Flow”
2. Messages that are the same between two Flows are not duplicated, so you can see their analytics in one place.  Also, this means you don’t have to make changes in one Flow, and remember to do the same in the duplicated version of it in the other.  

Drawbacks:

1. It can be confusing who gets which messages without looking at the message filters each time.  People not as familiar with Message Filters always ask why messages are being skipped. :)
2. You still have two Flows that seemingly is triggered off the same List - though this is good for Analytics, this can be confusing at first glance.

If this is too confusing to maintain, you can also just do the third option below.

Method 3 - One Big Flow, One List with Trigger/Conditional Paths

Just have one Flow, and have conditional paths based on which Custom Property (or no custom properties set) in the same Flow.  This keeps everything in one Flow, it’s a lot easier reference and understand what’s going on (if you have other team members, or people looking at Flows) - e.g. “Welcome Flow”= that’s where everyone goes.

The benefit of this setup:

1. One big Flow keeps everything in one place from a design and organization standpoint and communication/collaboration. 
2. All your stats are in one big soup. (This can also be a drawback, see below)

Drawbacks:

1. All your Flow analytics is aggregated in one place that combined your normal, offer 1 and offer 2. You have to open the Flow and really see what is performing at different places in the Flow.  This is fine if you have a small set of Flows, but if you have a lot of Flows in your account, this gets tedious to simply know what’s going on at a glance without digging into each Flow.
2. If you have common messages, they can all be pointed back to it (if you bring paths back to a main trunk, for example).  
3. One caveat, I’ve seen really big and scary Flows that scrolls on forever and has so many conditional paths it looks like a giant map and can be hard to see what’s going on or what it all means.  You then feel “afraid” to make any changes because you might break something and it slows down momentum.  

I might come back and edit this a bit, but I hope this gives you some things to consider!

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

Thanks a lot Taylor!
Yep I’ve currently set it up so if they’re in one of the flows they’ll be excluded from entering the other.

The main reason I’m doing this is so they can enter different flows, one receiving a free guide and the other receiving a monetary discount. Though I think adding a hidden profile property would make more sense now you mention it!

Thanks a lot @retention ! 

Really helpful guide especially with the pros and cons of each message!

As it was just changing a few messages within the welcome flow, I decided to:
 

• Send everyone to the Newsletter list (for list growth analytics and save time)
• Add a hidden submit field in the AB test of the signup forms stating what newsletter offer they received
• Added a conditional split based on this new profile property

One last question - considering it’s based on the signup flows, I’m unable to share the generic kmail subscribe list to get them into the conditional split, because there aren’t any hidden fields being submitted right?

 

Much easier than managing two separate flows.
Thanks again!

@michaeljja - Glad that helped,  I’m not quite sure I understand your follow-up question:

I’m unable to share the generic kmail subscribe list 

If I understand what you’re saying - for those that don’t have the custom property you want them to go into one of the offers splits?  You should be able to make an “OR” statement in your Split so if you want them to OfferA (or OfferB) - they can be grouped into that.  Or rather, if you have a conditional split that checks for OfferA, then OfferB, then the last path can be the default/generic Offer.

Can you expand on what you mean by “generic kmail subscribe list?” 

Ah that makes sense and answers my poorly phrased question 

Thanks!