Forum Moderators: open
I work for a nonprofit and we send out an e-newsletter using bcentral's listbuilder. We create two versions of the newsletter: .html and plain text. Bcentral inserts code at the top of each message that allows the e-mail client that receives the message to choose to display either plain text or .html.
Note that this has nothing to do with what the user themselves prefer -- at no point are they allowed to choose whether they want .html or plain text. The e-mail client makes the determination. If the client is .html-enabled, it displays .html and if not, it defaults to plain text. Not a perfect solution, but it works better than sending just an .html version.
My question is this: bcentral tracks how many people open the .html message by inserting a small pseudo-graphic in each message. If the message is opened in the e-mail client, bcentral can see that the message has been read and records it. But if the client displays only plain text for the user, this "open" is not counted.
What I need to know is what the split is nowadays between .html-enabled e-mail clients and plain text clients (how many plain text e-mail client users there are in relation to .html-enabled e-mail client users) so that I can estimate the actual "open rate" based on the .html open rate.
Note that this has nothing to do with what the user themselves prefer
That is not quite true .. If I receive a message from someone who's not in my address book the message will be viewed as plain text - no matter what. (Outlook)
Either way, most e-mail clients let you choose whether it will be viewed as plain text/HTML - and in most cases there's no way a message can override that.
Another thing is, your data might be slightly skewed. For example, some e-mail clients (or Web mail for that matter) might not display the HTML message. However, it might still display the graphic at the bottom.
Now, to your real question...
As with any stats, they can never be trusted 100%. The data might be skewed for one reason or the other. Also, it entirely depends on the user base the e-mails are sent out to.
Why don't you just use your "HTML stats" divided by how many e-mails are sent out each time?
Two years ago I read that around 2/3rds of e-mail clients displayed html and 1/3rd displayed plain text. Based on this information, I would inflate my html open rate by 50% in order to report the actual open rate to my boss. Example:
Bcentral reports that 6,000 people opened our newsletter. Since that only counts html opens, which are only 2/3rds of the e-mail clients, I tack on another 3,000 and report to my boss that approximately 9,000 people read the newsletter. I have plenty of room to inflate the figure because the newsletter was sent to 20,000 people.
My question is: Is the 2/3rds html, 1/3rd plain text still a valid assumption? My instinct is that as time goes on, more people will have html-capable e-mail clients. But perhaps the opposite is true -- since people are fearful of spam or viruses that come in html e-mails, perhaps more will become more sophisticated and turn off the html function on their e-mail clients.
However, and I'm just guessing now, because I have no real stats to base these assumptions on, these things should be considered:
1) Most e-mail client (software as well as Web mail) can handle HTML e-mails. I'd say that it's probably 80%
2) A lot of users do not bother (or simply don't know how, or even that it's possible) changing the whole HTML/plain text thing
3) Those who do know about it, I doubt that more than 33% actually do change the setting. It's hard to estimate, since there are several reasons for both. It entirely depends on the audience. Home users, not so likely. Professional, more likely. So, let's guesstimate 30%.
This gives a guesstimated ratio of 4:3
That seems unlikely, in favor of plain text e-mails. We need another factor.
Well, what about those that have the image cached? I'd be willing to say that it's probably at least a third.
Now, our ratio is 2:1... and that seems more likely.
So, yeah .. 2/3 viewing HTML and 1/3 viewing plain text is likely ...