- Developer Hub
- Email Tools
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- Deliverability Guide
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Contact Us
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.
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.
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.
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.
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.
I put up a post on permissions and deliverability a little less than a year ago in which I argued that marketers need to regard permission as transient: a point-in-time indicator of a desire to engage. To me, the more important principle is positive engagement: if you’re communicating an offer or information that’s relevant to that customer, then permission is implicit.
I bring this up because the permission concept of ‘forced opt-in’ came up recently in an exchange with an industry colleague. There are varying definitions of ‘forced opt-in’ but by whatever term you use, it’s a widespread practice. Customers opt-in for something of interest, but their permission is propagated across an enterprise or partner network under a not immediately evident data sharing provision. And before long they start receiving offers they didn’t ask for or want (spam by their definition) with no easy way to opt-out.
The practice can be rationalized as an attempt to better meet customers needs: “Given you’re interested in that, we thought you’d want to know about this…” It’s a quick and easy way for marketers to fulfill their legitimate relationship-building mandate. Unfortunately, many follow-on offers aren’t well targeted. They’re driven more by a simpleminded list-growth ambition or revenue scheme associated with lead capture.
So therein lies the challenge. When performed well and with the right customer-centric mindset, the practice can be justified as a way to deepen the relationship serving the interests of both parties. But when performed poorly, it has the opposite effect.
As I’ve argued in the past, the issue isn’t so much about permission but relevancy — relevancy to the customer’s needs, not to the marketer’s objectives. So I believe the principle that should be applied here is simple: if you share in the gain, you also share in the pain. What I mean by this is that there should be a reward/risk dynamic. If you share data or receive shared data, you’re gaining something — a reward of sorts. Fine. But you should also share in the pain of losing something — the risk — if the customer reacts negatively at any point along the permission propagation chain. Opt-outs should be applied upstream and downstream. Seems only fair and reasonable to me. The problem we’ve got today is that there’s really no risk associated with poor data sharing practices.
So in my view, the remedy to permission propagation is permission de-propagation. And the party that should be held accountable for de-propagation is the one who the customer entrusted with their permission in the first place and chose to propagate it. While tricky to apply, such a principle would keep all parties ‘honest’ by forcing them to focus both on the reward and risk of data sharing.
I participated in a lively exchange online with some email industry colleagues recently around the topic of improving deliverability through permission-based lists versus data management techniques, such as list hygiene. My contention was that for years the industry has been hung-up on the term ‘permission’ – single opt-in, confirmed opt-in, double opt-in, etc. But at the end of the day, does permission really matter? (more…)SparkPost © 2017 All Rights Reserved