How to Use Feedback Loops

For the uninitiated, FBL stands for feedback loop, the mechanism ISPs like Hotmail and Yahoo! use to report spam complaints to senders.

I know this will be totally shocking because, of course, your customers love you, but your messaging programs generate spam complaints if you send commercial email. And while there is a direct correlation between solid deliverability and a healthy response to complaints, I’m not going to drone on about it for another 500 words.

Instead, I’m going to show you how the newly­ released feedback loops module inside 250ok’s Reputation Informant helps you overcome the historical problems preventing senders from getting the most out of FBLs. It enables you to quickly understand complaint trends, pinpoint problem spots, and take immediate corrective action.

feedback loop
See? Problem spots pinpointed.

The key component of thinking about how you respond to complaints is time. Most feedback loops operate in near real-­time, meaning while there can be a delay of days or weeks between the time you send the message and when it is reported as spam, the FBL notification arrives very soon after the recipient files the report.

The only safe way to interpret a spam complaint is to take it as an indication that the recipient wants to opt-
out of that mail stream. Therefore, your responsibility is to do so, immediately.

Why?

Repeatedly sending messages to recipients who have opted-­out of those messages is the fastest way to tank your reputation. You can wind up in the spam folder, or worse, be fired by your email service provider for not playing by the rules.

Reputation Informant’s feedback loops module gives insight into several things. It shows your complaint reports over time, the current and historical rates at which you receive complaints, the largest sources by reporting domain, and top sources of complaints broken down by sending IP, subject line, and the sending and receiving addresses.

This visibility enables you to:

  • Understand the campaigns generating the highest complaint rates.
  • ­Identify the recipients hitting report as spam most often.
  • ­Predict which of your IP addresses are likely to be affected and at which ISPs.

You’re also able to drill down and examine the fine details of each complaint event.

Most importantly, the feedback loop module makes it incredibly easy to process opt-­out for complaints by allowing you to export a list of their email addresses. It’s essentially the magic-­unicorn functionality you’ve been seeking in managing your complaints.

feedback loops
Exporting a suppression list will help you opt-out your biggest complainers.

The module’s IP and date­-based filters, along with hour­-level granularity, allow you to examine complaint activity preceding a drop in deliverability at a specific ISP. You can also explore the correlation of your heaviest complaint times with your sending patterns.

Our goal at 250ok is to make every sender look great by empowering them with data and tools that simplify email. By partnering with SparkPost to bring the FBL module to every SparkPost user, we’ve made it easy to understand and effectively respond to spam complaints.

Okay, true. It was also an excellent excuse to create pretty graphs and play with a lot of data. But we swear the main motivation was building great tools for our joint customers. Ahem.

Enjoy.

paul headshot

Paul Midgen believes that inside every ruthless revenue-driven sender lurks a recipient-centered Jedi master, and he’s dedicated to setting them free one sender at a time. Before joining 250ok as VP of Engineering, Paul was CEO of Message Bus, ran Inbound Delivery & Anti-Spam at Hotmail, and has spent a lifetime working on things that allow machines to talk to each other for the benefit of humans.

 

 

suppressionlistsIn this post I’m going to show you some details on our new SparkPost Suppression List API and how to test it in conjunction with our Webhooks feature to validate that recipients are being automatically added to the account’s Suppression List for the appropriate events.

What causes SparkPost to add a Recipient to your account’s Suppression List?

  • Hard Bounces
  • SPAM Complaints
  • Link Unsubscribes
  • List-Unsubscribes

Step 1: View your account’s current Suppression List state

cURL Example to GET all the recipients on your SparkPost Suppression List

Step 2: Generate a Hard Bounce using Transmissions

The /transmission response should show the recipient was accepted by SparkPost’s API.

Step 3: Verify that the recipient is now on your SparkPost account’s Suppression List

The response should now contain the replacement value you used in the /transmission body.recipients.email property. Here is what a GET response from the Suppression List service looks like (just for reference):

Troubleshooting

If you follow the steps above and you do not see the new email added to your Suppression List, here are some steps to troubleshoot.

Webhooks to the Rescue!

I have a running Webhook consumer configured so I hopped over and started watching what was happening in my SparkPost events.

If you do not have a SparkPost webhook created and SparkPost webhook event consumer running, read our User Guide: Creating Webhooks. Make sure to configure your webhook with the bounce, spam_complaint, injection, and rejected message_event types.

Observe the Webhook events

Example of a valid hard-bounce Webhook event that triggers SparkPost to add the specific recipient to your Suppression list

Note: that if you did not generate a hard bounce, spam complaint, link unsubscribe, or list unsubscribe event type…you are NOT testing properly. Notice the type (delay) property and the bounce_class property in these two webhook events. If you don’t use one of the appropriate events to trigger an addition to the Suppression List you may start looking at webhooks like you see below and asking…“Wait a minute, that domain is totally invalid as is the user…what gives???”.

Why don’t we add these types of soft-bounces to Suppression Lists?

  • Because lack of DNS returning a valid MX record for a domain may in fact be a temporary error – so SparkPost will automatically retry sending that message again.

Hopefully this gives you a good initial overview of the power of SparkPost’s suppression lists!

Happy coding!

~ Benjamin