Skip to main content
  • EN
Solved

Building in suppression parameters into a newsletter list

  • 10 January 2024
  • 8 replies
  • 135 views

Hi folks,

Is it common/wise to bake in very general suppression parameters into a newsletter segment’s definition in order to keep the list clean without having to do regular “manual” suppression exercises? 

Background: I have a bunch of separate product family newsletters set up in Klaviyo. Since many of my subscribers receive multiple (different) product newsletters from me, I can’t to a traditional profile suppression since I’ve got global suppression activated and I don’t want to purge contacts who many no longer read one of my product newsletters, but is still engaged with another of my newsletters. Plus I don’t want to suppress them from my post purchase and abandoned cart flows. 

For each of my individual product newsletters, I have created really conservative “suppression” segments based on subscribers who have been signed up for at least 365 days but never opened or clicked on an email from that specific newsletter’s $group_ids.

tThose suppression segments have a flow set up to send them a sunset email. To allow me to keep folks out of that suppression segment who open my sunset email (and thus demonstrate a little bit of remaining interest) I’ve added a definition element wherein that suppression segment also includes profiles that have opened an email -- from that specific suppression segment’s $group_ids -- zero times.] 

What I want to do is add that suppression list to the definition of my specific product newsletter segments so that the final definition parameter in that list reads something like “Person A is not on Suppression list.”

My thinking is that if I do it this way, my newsletter segment is constantly cleaning itself of profiles that have not been engaged for at least 1 yr and I’m still sending sunset emails. 

Does this make any sense whatsoever?

 

8 replies

J
Rank
Userlevel 1
Badge

Hi @MattyO,

 

Thank you so much for your question here. I’m a Senior Solution Architect at Klaviyo and I’m hoping I can help you out here. First off, I want to make sure I understand your use case the best I can. It seems like your are managing multiple product newsletter lists that your customers can subscribe to and unsubscribe from if they choose. To reduce the amount of manual list cleaning you need to do you are looking to automate this by creating segments that exclude anyone who has unsubscribed from one of your product newsletters without affecting any of the other newsletters they may be subscribed to? Let me know if I’m understanding that correctly or not there.

 

If I am understanding that correctly, I think there is no reason to recommend against your approach but i would suggest that you be careful with what segment definitions you apply in this case as to not exclude profile you are trying to reach. I would recommend using a segment filter that removes anyone who unsubscribes from a specific newsletter list. It seems like this is your approach already though so you are on the right path here. Klaviyo will automatically not send to profile who are globally suppressed except for transactional emails so there is no need to define that piece of it explicitly within your segment definition.

 

Let me know if there is any piece of your question I’m missing or not understanding correctly and we can get you up and running here as quickly and efficiently as possible.

 

Regards,

Jeff

M
Rank
Userlevel 1
Badge +2

Jeff, first off, thanks for trying to decipher my convoluted thought process. You’re basically understanding my conundrum, but I think I can be a little more clear in overviewing my situation...

I built potential suppression lists to identify unengaged profiles for each newsletter. In a perfect world, I would simply suppress those contacts and move on and/or put them thru a sunset. However, since many of my customers subscribe to multiple product newsletters, if I were to suppress them for not engaging with one specific product email newsletter, I would end up suppressing them for all. I want to avoid losing people who might be engaged with one or two other product newsletters, but are clearly unengaged with another.

My other thought process was to just build these unengaged segments for each newsletter by using the $group_ids specific to each newsletter. Then, once a quarter I could convert these unengaged segments into a list and for the next quarter, I could simply exclude that list from any newsletter sends. 

That seems to be the best solution to my problem, but it doesn’t help me reduce active profiles over the long run. 

Another thought I had was to do a look up of those subscribers who are totally unengaged across all newsletters and suppress them, but that’ll likely be small potatoes.

Anyway, any additional guidance appreciated. 

Matty

J
Rank
Userlevel 1
Badge

Hi Matty,

 

I see what you are saying now. I think an important distinction to make here in case it is not clear is that you are able to unsubscribe a profile from a list (a list per product newsletter) vs a global suppression. In short, an unsubscribe is a type of suppression but it is not the same as global suppression which is what you are looking to avoid. With this being the case, you can segment by anyone who who is subscribe to specific product newsletter list which will be granular enough to include them where they need to be and exclude them from newsletters they’ve unsubscribed from without an unintended effects on each other.

 

Let me know if this answers your question.

 

Regards,

Jeff

M
Rank
Userlevel 1
Badge +2

Jeff, thank you and I’m with ya on that. Unsubscribe was actually the path I wanted to take from the beginning, but I wasn’t able to figure out a way to do bulk segment (or list) unsubscribes.  

 

I’ve just got way too many unengaged folks to be able to handle it manually for each newsletter segment.

 

If there is a way to do that, my life will be changed forever. Please say there is. 😁

 

Thanks again, 

Matty 

 

J
Rank
Userlevel 1
Badge

Matty,

 

This is possible but it is not available out-of-the-box. This is where this begins to get technical since we are working with a custom solution. Here is what I recommend.

  1. When someone notifies you that they want to unsubscribe from a specific product list, send Klaviyo a custom metric that you can name whatever you would like. We will call it “Unsubscribed from Product List” for now. You can do this client-side as well
    1. In the event payload, include the Klaviyo list_id of the product list the profile wants to unsubscribe from. I’ll attach screenshots of this
  2. Create a flow that is triggered by the “Unsubscribed from Product List” metric
  3. Add a flow action webhook to the flow as the next step
  4. Create a Napkin.io account
  5. Clone this Napkin function I wrote
  6. Set up the webhook to point to that Napkin Script in your Napkin account
  7. The webhook body will need to reference the list ID you want them remove from by using Klaviyo’s event object and the profile’s email. I’ll provide screenshots of this as well.
  8. The Napkin script will hit Klaviyo’s Remove Profile from List endpoint and will remove the profile from the list ID you provide without affecting the profile’s consent status

I’ve tested this out in my test Klaviyo account and it’s working as intended. Let me know if you run into anything

Webhook that reached out to Napkin Script
Send initial event to Klaviyo

 

J
Rank
Userlevel 1
Badge

Matty,

 

One thing to note is in the Napkin script you will need to create and add a private API key to the environment variables I have created for this to work. 

 

Regards,

Jeff

M
Rank
Userlevel 1
Badge +2

Thanks, Jeff. Really appreciate it. 

J
Rank
Userlevel 1
Badge

@MattyO,

For more in-depth technical solutions that require larger customizations such as this one, I recommend utilizing Klaviyo’s Developer Community moving forward. You will be able to find a lot of great resources there as well and a community that is in place to help with these sorts of use cases.

Best,

Jeff

Reply


Most helpful members this week

Terms & ConditionsCookie settings