Hi @smileyrox,

Thanks for sharing this question with us.

It sounds like you’re referring to updating a profile property using a button or a link. This solution is still possible with a couple of changes.

{% update_property_link 'profile_property' 'property_value' 'redirect_link' %}

What you can do is change the profile_property field for each button to create 3 separate properties. For example, using ‘category_1’ for the first button, using ‘category_2’ for the second button. So say for ‘category_1’ the section on your website is about cars, the link would look like the following for the first button:

{% update_property_link 'category_1' 'cars' 'LINK_TO_THE_CARS_SECTION_OF_THE_WEBSITE' %}

Then, say the category were ‘boats’ for the second button, it would look like the following:

{% update_property_link 'category_2' 'boats' 'LINK_TO_THE_BOATS_SECTION_OF_THE_WEBSITE' %}

When people click on these buttons, this would create separate properties (instead of overriding the previously existing value for a property) which you could then segment off of using “properties about someone” in the segment builder.

I hope that’s helpful. 

Hi @smileyrox!

This is a great question. I’ve had wonderful personalization and revenue growth come from building flows for my clients, using segments created with the workflow you’re describing. I’m glad to see you’re doing this also. 

Above, @Dov gave you a helpful way to simplify the logic of what you’ve built. If the product categories are obviously distinct from each other, using a Text data type custom property is a reliable way to build those links or buttons to automatically add/update a custom profile property on someone’s profile based on a click in an email. This is a straightforward type of logic to use for building and updating custom profile properties. 

You could do this like the examples below, with the Text data type.

• Property 1 name = indoor_interest
  • Property 1 values = Yes, No
• Property 2 name = outdoor_interest
  • Property 2 values = Yes, No

If you go down this route, I recommend you split the product interest links into 3 separate emails. You can feature 1-3 products of one category with product photography and some text, then prompt people to click the link or button to let you know they want to see more products like that. Then repeat as needed for the other categories…

Here’s a super helpful doc explaining the different data types available for custom profile properties. 

If you’re up for something a little more sophisticated, this is the logic I personally use for this workflow:

When I do things like collecting a “product_interest” (let’s say that’s the property name) I try to make sure the property is a List data type, so it can hold multiple values.

I choose to work with the more complicated logic and setup process of a List data type because having one “product_interest” property can help me streamline the many different custom profile properties that exist in a client’s Klaviyo account. That benefit is worth having more work up front in my experience.

So instead, it might look like this example with a List data type:

• Property name = product_interest
  • values = Womens, Mens, Home, Childrens

This is the solution I would recommend. At the end of the setup, you can ask Klaviyo support to help you delete the first draft Text data type custom profile properties you already built since you would replace with these List data type ones. That way you don’t get confused later, trying to remember which matches up with what.

When you’re setting up a List data type property, it helps to create it in your account using a CSV file with the values of the property formatted in a JSON array. That makes sure the Klaviyo backend correctly recognizes the data type of your property.

If you have product interest data that you’ve already collected with these emails, I would export those segments first, with the first draft properties included as columns in the CSV export. Then you can rearrange the data, formatting it as a List type, and import it back into your master list. No duplicate profiles will be created; you’re just updating the data on the profiles that already exist. Here’s a help doc for that process, with a guide for how to format your CSV before importing it.

Follow-up marketing ideas:

I’ve done this before when customers order a swatch. We add a swatch_interest property to their profile, and use that to build a type of welcome series that sends articles to guide them with color selection and recommended products depending on their home. 

I’ve also used a workflow like this to send people campaigns specific to a location and events in that location.

The sky is the limit! You’re on the right track, and this will get easier as you get more practice working with custom profile properties. They’re actually one of my favorite features of Klaviyo.

I’m happy to help more if you have further questions.

Cheers,

Gabrielle

Hi @Dov and @ebusiness pros 

Thank you so much for the help. Really grateful. I’ll take some time to work through the comments and play around on the tool to find the best solution for me.

Appreciate it and wishing you both a lovely day ahead.

Warm regards,

Rox

Hi @ebusiness pros , this is a truly interesting workaround, to have a List data type. However, I can’t quite figure out the step of formatting the values as a JSON array. Moreover, could I ask how do you format the structure link used?

{% update_property_link 'profile_property' 'property_value' 'redirect_link' %}
 

How do you format the value so it doesn’t get erased when selecting another option?

Hi @Alfredo Flowium! I’m sorry for the delayed response.

When you format the property values as a JSON array, they’ll look like this example: p“womens”,”mens”,”home”]

I recommend you use property values formatted in all lowercase, with no special characters, so nothing breaks on the backend. When you show these values to profiles on the front end, you can modify it (example: form placeholder text or an email text link) to show something like “Women’s” instead. 

Here’s the Klaviyo help doc with more info on the List data type. 

When formatting the link, you need to specify the property value in that same JSON array format even if it’s just one value being updated at a time, so the backend of Klaviyo accurately recognizes it as a List data type. So it would look like this example: 

{% update_property_link 'product_interest' 'p“womens”]' 'redirect_link' %}
 

That List data type of the custom property and property values is what ensures it can hold multiple values simultaneously. So nothing will be erased that already exists on the profile, in most cases. 

Unfortunately there is one exception to this: IF you do a bulk upload via CSV that populates multiple profiles with a List data type custom property, that set of property values for will be considered the “initial value” and any changes made after that point by a customer clicking links, selecting options on a preference page, etc. will REPLACE those values even though it’s a List data type.

Any List data type property you create will only APPEND values outside of that scenario. This is why I’ve started using Text data type properties more often, even though I generally prefer the logic functionality of a List data type from a data management perspective… That exception compromises the long-term data integrity when I need to do a bulk upload of profile properties.