Hey @notboredgames! No worries at all, I can definitely help you with this. 

Overall, yes, I’d suggest you keep your one main list and create segments based on the content preferences of your subscribers. You’re totally right in that you’d need to create a custom property based on how you want to segment your list. In your example it could be $preferences_page (or whatever your custom property lexicon is) with values for newsletter, comic, and crowdfunding. In the preferences page editor, you can change the frontend value to something that makes sense for your subscribers and gives more context on the content and what they can expect.

From there, you then go back and create a segment based on Properties about someone for each value in your preferences. Keep in mind though you won’t be able to do this until at least one profile has the property assigned. A quick tip is to add yourself as a profile to your list, send yourself a campaign, and assign yourself all the preferences. Just don’t forget to include the {%manage_preferences%} tag in your campaigns!

Check out this article on Consent pages for more info. Hope this helps :)

Hi @notboredgames!

Love the intention to give people more control over which emails they’re getting from you. There are a couple technical recommendations I’ll add to the great info you already got from @kaila.lawrence 

1. Simplify the properties you’re using. Assume there will be some percentage of your list that has multiple interests, and will want to be “subscribed” to multiple content segments (like Newsletter, Crowdfunding Projects, and Our Comic)
   
   1b. Best way to set this up for the most foolproof logic in the long run is to use a Text data type property. So have one property for each interest or content stream, and use a simple “yes” / “no” value. Most of the time, you won’t actually use that “no” value, but setting it up this way helps you identify those who have the “yes” value on their profile, and separately identify those where the interest value “is not set.” You’ll find that’s a more accurate way of grouping people than using the Boolean T/F logic for a custom property.
   
   1c. Here’s a great help doc outlining the difference between the data types for custom properties
   1d. Example of how I’d configure this: Property name = content_preference_crowdfunding_projects   Property values = yes, no
    
2. When you set up your preferences page, make sure you set up the global (account-wide) version so your dynamic {%manage_preferences%} tag is a functional link in the footer of your campaign AND flow emails.
   
   2b. If you set this up in the settings for a specific list, then ONLY that list will have a functional link. This means even segments based off your “master” list will not meet the conditions for that link to pull up the correct preferences page. I learned this the hard way. Don’t want you to have to build the page twice!
   2c. Here’s the precise section of the help doc Kaila gave you with instructions for how to configure this global/ default preference page

There’s more technical context behind why the Text data type is the best to use for the custom properties you’ll create for this content preference, but I didn’t want to overwhelm you here. Happy to share if you’re interested!

Also, nerd alert lol Since it seems like you have an existing interest in building a robust subscriber profile… If you’re not already familiar with Brennan Dunn, I highly encourage you to check out this 18 min YouTube video when you get a chance. 

His perspective on audience segmentation, treating your email list like a database, and using custom fields (in Klaviyo language = custom profile properties) will be invaluable as you build more sophistication into your Klaviyo account. It’ll also help you get a solid understanding of how Klaviyo works best - when you have one “master” email list and leverage segments to create specific groups of people rather than using multiple lists to achieve that grouping. 

You’ve got this!

Gabrielle

Klaviyo Champion & Marketing Lead at ebusiness pros

Thanks so much @ebusinesspros for the assist! Some great knowledge dropped there  

It’s my pleasure @kaila.lawrence - segmenting and customer preferences is one of my personal favorite parts of Klaviyo. :D

Thanks everyone for the help. I’m now going to try an implement everything you said and let you know if it works.

Hey @ebusiness pros 

Thank you so much for your post. 

What you stated is very interesting. Could you please elaborate on exactly what you mean by “having one property for each interest” and the “yes”/ “no” value. If you could provide an example I would sincerely appreciate it. 
a
The way I was going to set it up was to have one profile property = content_preferences

And three property values (using the “multi checkbox block”) = music, membership, announcements, 

If I have understood correctly, you are saying to set up three individual profile properties = 

1. content_preferences_music
2. content_preferences_membership
3. content_preferences_announcements

Using the Radio buttons and/or multi checkbox? 

And create two values for each property = 

1. yes
2. no

Thank you for your help and assistance. 

Hi @Eva Kourtes! You’re quite welcome, and I’m glad you found my recommendations helpful. 

Here’s the tricky part with your originally intended plan: 

“The way I was going to set it up was to have one profile property = content_preferences

And three property values (using the “multi checkbox block”) = music, membership, announcements”

IF you used one property, with multiple values like this, AND you wanted to give people the ability to select multiple content preferences, that requires you use a List data type custom property (help doc reference). That’s what enables the “multi-select” functionality of the block you described using.

This is one route, but use caution if you choose the List data type implementation path with your custom properties. 

Sometimes, List data types don’t get accurately recognized in the backend of Klaviyo IF you do not configure the property values in the correct format as specified in the help docs. They need to be compatible with a JSON array, even if you’re configuring just a single value at one time, rather than a list of all values. 

That can make it more complicated when you’re initially setting up custom property fields in optin forms, “manage preferences” pages, or doing a bulk import of profiles to add custom properties via CSV upload.

It’s doable, but it also might be more technical configuration of Klaviyo than you’re comfortable doing on your own right now! Totally up to you. (:

The simpler path: use Text data type custom properties

All of those complications are why I tend to recommend using the Text data type instead. It uses a single-select functionality instead of multi-select, and will lead to you having a greater number of individual custom properties. 

That said, the setup and later maintenance of this custom property data type tends to be simpler.

So to return to your example: You could use a Radio Buttons block, or a Dropdown selection block. Both correspond to the single-select values compatible with the Text data type. 

This means, yes - you do create separate custom profile properties for each content preference. So it could look like… 

Property 1: content_preferences_music where values = yes or no

Property 2: content_preferences_membership where values = yes or no

Property 3: content_preferences_announcements where values = yes or no

Also, to help you better understand this on a big picture level. Custom profile properties are case sensitive for both the property name AND the property value. That’s why I recommend you keep property names all lowercase, and separate words with and underscore like content_preference as well as keeping values all lowercase.

Warmly,

Gabrielle

P.S. I have a background in music, so I’m really pleased to see you taking such a strategic approach to your email list! It’s a high-value asset for any independent musician to have, and you clearly prioritize that. Bravo!