@stephan - It looks like you did everything right. The “Contains” means that the string you enter occurs anywhere in the coupon code - so if your string is “WELCOME” then WELCOMEXXXX should work, as does XXXWELCOME or XXXWELCOMEYYY.

To test conditional splits, these are the two options I do if I’m not super confident the conditions are behaving as intended.

Add Split, Combine Both Paths

Add the Split, and both Yes or No path goes to the same place.  You can then look at the analytics to see how many “Yes” or “No” you have.  That way, until you’re confident that the Split, the user gets the same thing.  Once you’re confident it’s working, disconnect the combined path and add the appropriate messages and actions.

Here’s how you can connect both path of a Conditional Split to the same Path:
 

Add Split to End of Flow

In a similar fashion, you can add the conditional split at the end of the Flow where either Yes or No doesn’t do anything.  After some time passes, I can look at the analytics of the Split and verify that it worked as intended.

Hope this helps!

Awesome, thanks a lot for the prompt and comprehensive help!!

Hi there,
I’d like bring this topic up again as it seems that the solution doesn’t work as hoped.
Without any deep digging or testing based on the stats along the flow it looks highly unlikely that this functions…

What came to my attention is that when you set up the filter and fill out “contains” all so far existing coupon codes are being suggested, as well as the one I entered before (“WELCOME”) which is only the prefix of all coupons that are meant. So it seems its not necessary a “contains” but rather a specific definition.

Any ideas from anyone?!

Thanks
Stephan

Hi there @stephan,

The "contains" parameter in this case is not able to do a text matching for the prefix. It would have to be an exact match for the entire code. This will work in a scenario where a static code such as "WELCOME10" is used. But this will not work to find "VWXYZ" within the full value of "VWYXYZ-ABCDE". When using the custom report building, you would be limited by the same thing as above. This is due to how the data comes through to Klaviyo from Shopify. The options listed in my previous response would be the best way to identify those customers. You can export your orders to CSV then filter out those that used the discount or search for the discount code in Shopify, then export that to CSV. Once you have a CSV of those that used the discount you can create a new list in Klaviyo. Then you can start reporting from there.
Unfortunately, there is not a way to identify these customers directly through Klaviyo. They will first need to be identified outside of Klaviyo. If you were to add a tag to their profiles this would sync to Klaviyo, although using the CSV method above would be the most precise option.

Therefore, it’s not currently possible to build a segment in Klaviyo to see who's placed an order using a specific coupon when the codes are dynamically generated and unique per user. I have escalated this to our Product Development team so we can try to offer this through a future update. In Shopify, however, you should be able to pull this data - here are two options we've found that work:

1. Export your Orders CSV, and sort your CSV using your spreadsheet program of choice to see which orders had a particular discount code applied to them. In this case, you'd sort and look at all orders where the discount code started with the same prefix.

2. Sort orders that use a certain discount code directly in Shopify by searching using the discount code in your orders section. You can export these orders or "save the search" so it shows up as a tab in your orders section. In the Orders Admin in Shopify, you can search using any discount code prefix and see all orders placed using a code with that prefix.
 

Hope this made sense,

Alex

Hi @alex.hong ,

Thank you for the explanation. Unfortunately the manual process of identifying profiles that made use of their personalized coupon they got as a reward for signing up to the list is not really feasible in this context. But if you manage to include that option in the future I think this would be helpful!
Until then it might be of help to include this detail into the documentation or at least use a different term for setting up the filter than “contains” as this misleads to a false solution I was given in the first place…

Thanks and have a good day
Stephan

Hi there @stephan,

My pleasure. Apologies that the work around wasn’t something that was feasible for you in regard to your own setup. Our team is aware of this and will be looking to provide product feature updates as they come out! 

I have also let our team handling docs know about your feedback regarding the wording and explanation for the “contains” filter and hope that future updates will allow for more transparency and easier understanding of how these filters work in relation to coupons as well.

Thank you for your feedback and for being a member of our community!
Alex

Adding to this! I’m trying to create segments to analyse which customers have used their welcome discounts (prefix WEL) but they’re also not working for this reason. Frustrating! Any news on this being resolved soon?

Also tagging onto this as it’s disrupting our Mention Me referral nurture flow (as I can’t filter flows based on if people have used their unique referral code containing ‘RFE’ without manually selecting every code which begins with this). This seems to be a pretty big issue in terms of the flow email limitations, so also highlighting the desire to have this functionality made available in a future product release!