Someone asked yesterday
What business advantage is there to an ISP in offering a feedback loop? I’ve never really seen one.
It’s a good question. There’s a fair bit of work involved in offering, maintaining and supporting a feedback loop. What makes it worth it?
At a consumer ISP there’s some email sent to customers that’s easy for spam filters to recognize and handle correctly. On one end of the spectrum viruses, herbal pills spam and spam from botnets is easy to recognize and block, while on the other end individual one-to-one mail from regular correspondents is easy to recognize and deliver. Most ISPs handle the easy messages well, so their customers experience with their spam filtering will be dominated by the harder messages to handle in the grey areas between these two extremes.
Of the unwanted email that ends up in recipients mailboxes the hardest, by far, to filter out is “legitimate bulk mail” – mail that’s coming from legitimate companies that’s likely to be wanted by a big fraction of the recipients. Some recipients want to receive the mail, others don’t object to receiving it, while others consider it unwanted spam. As any particular mailing of this type will look just the same and come from the same source a typical spam filter will find it nearly impossible to make the right decisions for all recipients.
The This-Is-Spam button allows an ISP to handle this sort of mail on a per-user basis, by providing an easy way for the user to flag the message as unwanted in a uniform way. The ISP can use that information both to tune user-specific mail filtering and to send a feedback loop report to the bulk sender. The bulk sender can use that report to stop sending mail to that customer and, maybe more importantly, it allows the bulk senders to tune their processes so as to fix the problem of sending mail to recipients who don’t want it. It gives the senders a metric to measure their process changes against – a pretty good metric.
That reduces the amount of unwanted email seen in customer inboxes, especially the unwanted email that’s very hard to filter in other ways. That leads to a better customer experience, which leads to happier customers and less customer churn. Customer churn is expensive in many ways other than the obvious problem that each customer lost is a monthly payment lost. It also leads to increased marketing costs to bring in new customers to replace those that are lost, and significantly increased technical support costs as new customers are brought onto the network.
“Too much spam” is a very commonly given reason by customers who are changing from one ISP to another, so controlling the hard to manage spam in this way – both directly and indirectly by improving bulk senders practices – can have a significant benefit to the ISPs bottom line.
RSS - Posts
Most of my FBL reports are from COI lists where the subscriber lost interest. That’s fine with me, I can handle them entirely automatically, so it’s less work for everyone involved than trying to educate subscribers on the correct way to unsubscribe.
this explain why feedback is good for the isp but why should we share it wit hsenders they just whine and ask for more?
Great post, Steve. All too often, receivers are myopic about offering any sort of service which can both be beneficial to them and senders. But, offering a service which assists senders does not inherently make it bad for receivers. FBL’s, until a new technology service is offered identifying spam further upstream from the mailbox (a predictive voting mechanism), will serve the best way of expressing recipients’ wishes. It’s closest to the actual subscriber experience. But, handling FBL notifications responsibly still falls on the sender.
I did some poking around at the origin of the FBL at my former place of work. It was not done out of a “business case” or anything nearly that structured, just as I suspected. It was originally set up as a hammer, and was not requested by the recipient network. It was an attempt to get networks to realize just how much spam was pumping out of their servers and maybe get them to DO something about it. Later, around when I was hired, the ability to request them was created, but I remember dealing with a lot of angry people back then who thought it was terribly highhanded of us to just start pummeling their abuse inboxes with their OWN SPAM without asking.
The Proverbial Barry touches on one of the reasons that was discussed during the time of my tenure there: there were many conversations about whether or not we should keep sending FBLs since the cons seemed bigger than the pros, a lot of the time. Inertia won the day more often than not. My perception of why the FBL offering stayed in place was not due to a business case, but more to a “it’s there, it works, leave it alone cos it makes people happy”. If other reasons were discussed, it was not in my presence, so I’d be interested to hear from madkins on this.
Steve’s post is an interesting take on the subject that I’d not given much thought to before. Thanks for posting it.
Er…sorry, it’s early in the morning. Clarification:
“…if reasons other than “its there, it works, and it makes people happy” were given as to why the feedback should continue to sent instead of only used internally, I am unaware of them. The biggest objection to sending the loops were from a legal liability POV (which is why the annoying ownership checks were created), and from a “helping to listwash sucks” POV. No guesses on who defended the legit sender uses of the data.
[…] Why offer a feedback loop? – Word to the Wise – Aider certains de vos abonnés à se désinscrire pour augmenter votre délivrabilité chez vos autres abonnés. Cela peut sembler paradoxal et pourtant … […]
chris we’re not myopic we just have priorities
my users are more important so thats where we put the money and manhours
never going to change that so stop asking
If you bulk send and subsequently receive loads of feedback abuse emails, processing them can take ages.
If you want a system that automates the processing of email feedback loops then look here: http://www.geakeit.co.uk/2010/06/25/automating-email-feedback-loop-fbl-processing-and-getting-around-aol%e2%80%99s-recipient-email-address-issue/