Hi @Lach,
Thanks for sharing this with us.
The way you’ve set up the conditional splits using SKU’s is perfectly fine. However, I’m wondering why you’re deciding to trigger this off a list, for a browse abandonment flow? I’d recommend using Viewed Product as your metric to trigger the flow that will give you the flexibility to include data relating to the Viewed Product event in your flow. With that said, this is a solid start. I’m interested to hear how others are approaching this as well :)
@Lach looks good to me from what you said on your goals for this flow. It looks like the number of conditions double after each “no” in your conditional statements. What are the other conditions in there?
Agreed with @Dov though, if it’s browse abandon flow then doing it off a viewed product event would be best.
Thanks @Dov and @Manny Singh, I appreciate the feedback.
You’re right about the list trigger - I’ve made sure that’s corrected.
@Lach looks good to me from what you said on your goals for this flow. It looks like the number of conditions double after each “no” in your conditional statements. What are the other conditions in there?
Ah, that’s sort of funny how that worked out! The conditions just specify a certain product - so it’s:
Ordered product once where SKU = x
OR
Ordered product once where SKU = Y
OR
Ordered product once where SKU = Z
OR
etc….
For returning customers, I want to tailor the email they receive to the type of product they’ve bought. It doesn’t have to be product specific, but our products do fall into specific categories. E.g: It doesn’t make sense to suggest an adult-level game to someone who’s only been buying kids games so far.
Thanks again for the help! I definitely didn’t want to be building terrible inefficiencies into my work at this early stage.