Clarification on monetizing complaints

There has been quite an interesting discussion in the comment stream of my earlier post about monetizing the complaint stream. I’ve found all the perspectives and comments quite interesting.
There is one thing multiple people have brought up that I don’t necessarily see as a problem. They assert that this idea will only work if all ESPs do it because customers can just say, “Well, Other ESP will let us do this and not charge us.”  I don’t quite understand why this is an issue. Customers already do this.  In fact, sometimes the assertion is actually true.
There are ESPs that let customers spam. There will always be ESPs that let customers spam. This is not new. Changing a pricing model isn’t going to change this.
As I was envisioning the monetization process, ESPs who wanted to do this could actually offer multiple tier pricing. The customer can choose a lower price point for their overall mail program, while assuming the cost of their recipients complaining. Or the customer can choose a higher price point and let the ESP absorb the cost of handling complaints. In either case, the customer would still have to meet the ESP’s standards for complaints and comply with their TOS.
Clearly I’m seeing the idea and industry differently than a lot of my readers. I’m interested to hear the thought process behind this so I can better understand the objection.
 
 
 

Typo traps
Why don't users want that mail?

Related Posts

Spammers react to Y! DMARC policy

It’s probably only a surprise to people who think DMARC is the silver bullet to fixing email problems, but the spammers who were so abusing yahoo.com have moved on… to ymail.com.
In the rush to deploy their DMARC policy, apparently Yahoo forgot they have hundreds of other domains. Domains that are currently not publishing a DMARC policy. Spammers are now using those domains as the 5322.from address in their emails. The mail isn’t coming through any yahoo.com domain, but came through an IP belonging to Sprint PCS.
ymail_dmarc
This is just one example of how spammers have reacted to the brave new world of p=reject policies by mailbox providers. If only the rest of us could react as quickly and as transparently to the problems imposed by these policy declarations. But changing software to cope with the changes in a way that keeps email useful for end users is a challenge. What is the right way to change mailing lists to compensate for these policy declarations? How can we keep bulk email useful for small groups that aren’t necessarily associated with a “brand”?
The conversation surrounding how we minimize the damage to the ecosystem that p=reject policy imposed hasn’t really happened. I think it is a shame and a failure that people can’t even discuss the implications of this policy. Even now that people have done the firefighting to deal with the immediate problems there still doesn’t seem to be the desire to discuss the longer effect of these changes. Just saying “these are challenges” in certain spaces gets the response “just deal with it.” Well, yes, we are trying to deal with it.
I contend that in order to “just deal with it”, we have to define “IT.” We can’t solve a problem if we can’t define the problem we’re trying to solve. Sadly, it seems legitimate mailers are stuck coping with the fallout, while spammers have moved on and are totally unaffected.
How is this really a win?

Read More

Gmail FBL update

Last week Gmail started contacting ESPs that signed up for their new FBL with more information on how to set up mailings to receive FBL emails.
One of the struggles some ESPs are having is the requirement for DKIM signing. Many of the bigger ESPs have clients that sign with their own domains. Gmail is telling these ESPs to insert a second DKIM signature to join the FBL.
There are a couple reasons this is not as simple or as doable as Gmail seems to think, and the challenges are technical as well as organizational.
The technical challenges are pretty simple. As of now, not all the bulk MTAs support multiple signatures. I’ve heard that multiple signatures are being tested by these MTA vendors, but they’re not in wide use. This makes it challenging for these ESPs to just turn on multiple signatures. For ESPs that are using open source software, there’s often a lot of customization in their signing infrastructure. Even if they have the capability to dual sign, if they’re not currently using that there is testing needed before turning it on.
None of the technical challenges are show stoppers, but they are certainly show delayers.
The organizational challenges are much more difficult to deal with. These are cases where the ESP customer doesn’t want the ESP to sign. The obvious situation is with large banks. They want everything in their infrastructure and headers pointing at the bank, not at their ESP. They don’t want to have that second signature in their email for multiple reasons. I can’t actually see an ESP effectively convincing the various stakeholders, including the marketing, security and legal staff, that allowing the ESP to inset a second signature is good practice. I’m not even sure it is good practice in those cases, except to get stats from Gmail.
Hopefully, Gmail will take feedback from the ESPs and change their FBL parameters to allow ESPs to get information about their customers who sign with their own domain.

Read More

Bounces, complaints and metrics

In the email delivery space there are a lot of numbers we talk about including bounce rates, complaint rates, acceptance rates and inbox delivery rates. These are all good numbers to tell us about a particular campaign or mailing list. Usually these metrics all track together. Low bounce rates and low complaint rates correlate with high delivery rates and high inbox placement.

Read More