16 Mar 2012
When users out-think you
A client wanted to prevent paid users of their product from sending messages with email addresses to the free users. The client felt that allowing such exchanges to happen would make the free users less inclined to upgrade to a paid account. Anyhow, we went ahead and implemented a robust email masking “feature” which blanked out any fragment of text that appeared to be an email address. We felt pretty smug about it because it could even catch smart users who pulled tricks like john at example dot com. Heck, we had automated tests to cover all those edge cases and hairy scenarios!
The users defeated the system in the following ways:
You can contact me off here – jack sp 1967 at g mail (all in one address).
Take the first letter from each of the following words: please don’t count rabbits because they increase everyone’s expectations at great mayhem and internal lost dot clouds over mountains.
When we were implementing the email masking functionality, at one point, I was wondering whether we were going overboard in coming up with all kinds of ways to break the system. In fact, I’m sure I even thought, “Huh, these are probably non-technical folks, so we don’t have to go to really convoluted extents”. Boy, was I wrong.
My favorite exploit included sending the email address using NINE separate messages:
r
w
a
1
t
at
gmail
dot
com |
I’m sure even if we had spent two more weeks on the masking feature, we wouldn’t have been able to catch that one!
NOTE: the above messages do not of course contain the actual email addresses of the users.
This is also one of the reasons why sometimes it’s better to trust your users.
Give them a compelling reason to upgrade, not a crippled free version.
Based on what little context we have here, I’m guessing it’s a dating site
It’s difficult to discuss the merits of opening up the system without having an A/B testing and/or well defined analytics system to prove a point to the clients. And the fact that there are always so many things to be done also makes selling such experiments hard.
Ideally, I wish all development is analytics and data driven, rather than gut-feel driven.
I think you have some quite conclusive metrics here. If you try and control your users, they will find ways to work around. At the moment, they are being creative. Very soon, it might be that they just leave for a more trusting environment.
I would always recommend to my clients that they start with the simplest option and put in restrictions only when:
(a) They have proof that their users are abusing their priviledges
(b) They have proof that this abuse is costing money rather than bringing people to the site.
I would tend to be turned off by a site that doesn’t trust me, or tries to charge me for what should be basic functionality.
Also, I don’t believe that this is a data issue. As a user, I don’t care about your data, but I will get a sense of whether you’re creating an antagonistic “them and us” situation by not trusting me.
Analytics and data can give you the wrong impression
In any profitable business there are way more customers than employees of the company. Make sure you’re on the same side as the bigger army
In the above comment, Analytics and data can give you the wrong impression was supposed to link to this article:
http://blog.intercom.io/know-your-customers-and-how-they-decide/
Sounds fair. Should look into how we can do a better job of messaging these things to clients right from the start. Sometimes, like in this instance, I have to admit that I myself under-estimated the nature of this issue.
Good Learning. Curious if you went too far and had a story to catch those kind of exploits as well.
No we didn’t! We did identify some easy tweaks to make a it a little better, but overall, some of these can’t be caught via automated means without false positives.
Ah, just the kind of conversations I miss out on