Skip to main content

The cranky user: Respecting user privacy, Part 2

Earning user trust through a clear, effective privacy policy

Photo of Peter Seebach
Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive.

Summary:  In Part 1, we examined why it's important to have an effective privacy policy in place. Here, we take a look at best ways of earning the trust of your users through straightforward, clearly-worded policies that meet consumer needs.

View more content in this series

Date:  12 Apr 2001
Level:  Introductory
Activity:  1200 views

User expectations

Most companies doing business on the Web thus far seem to have focused on ways to increase consumer acceptance of marketing tactics that border on outright abuse. They post policies, they warn people that they are agreeing to them by reading their pages, they tell users that they can easily "opt-out." What companies don't do, it appears, is try to find policies that consumers won't have to be bullied into accepting.

Remember that most people find sharing mailing lists to be just plain rude. Now, that's not to say none of your customers will be interested in other companies you like -- but they'll probably be a minority, so maybe you should leave everyone else out of it. You may not make much money selling the names, but you can charge a premium for names of people who really genuinely asked to hear about these related products. Furthermore, you'll get a lot less fake contact information if you promise not to abuse the information you have.

Many sites consider their privacy policies to be part of the "terms of use" of their site, and expect users to agree to those terms. There is no such thing as an agreement that can be changed, unilaterally, by one party to it. That's not an agreement, that's a decree. If you screw up, if you make a policy that doesn't work, you should accept the consequences like a responsible adult, not like a spoiled child. Contact your customers and ask them to agree to the new policy. Discuss, fairly and candidly, what's changing. Don't cover up changes. When a company I used to do business with updated their policy to say they could spam me at will, they posted a charming FAQ claiming that the only changes to the policy were in a separate part of the document. They lied, I caught them, and I am now an ex-customer.

Some customers won't want to accept the changes. If you have an ongoing relationship with them, you should probably just accept that some of them aren't going to switch over. Otherwise, you may need to terminate the relationship; if you do this, give fair warning. But never pretend you can simply change the agreement; that's not how an agreement between partners works.

Don't assume that a user who hasn't complained is happy; silence is not the same as consent. Users have learned that it's often less trouble to just delete the e-mail (and resent you for sending it) than it is to try to make you stop.


Internal privacy

Furthermore, note that privacy isn't just about what data you share with other companies. It's about what data you share internally as well. Is your marketing department obtaining data that was originally provided to the order department? In one particularly egregious example, a company requested technical support from the company I worked for, then added the address that replied to their message to a marketing list. (Basically, their privacy policy said, "If we can obtain your e-mail address, we may use it to send you mail.") People will tend to expect that the data provided in a given context will only be used in that context. This is a legitimate, reasonable expectation; tread on it at your peril.

The policy you choose should reflect the interests of your customers. Customers, in general, seem to prefer to be asked, rather than taken for granted. Want to run a mailing list? Invite your customers to be on it, but don't put them on it without their permission. Of course, the first instinct for many companies is to include a little tiny checkbox with negative wording, carefully designed to be confusing. This will, inevitably, generate complaints. The best solution I've heard is to have a set of radio buttons (checkboxes will do in an emergency), and require users to pick whether or not they would like to be on your list. If there is no default, everyone will choose -- and most of them will remember doing so, since they actively chose to be on your list, or to avoid it. Companies that keep lists this way get very few complaints.


Human response

Another key technique for reducing complaints: Require confirmation on mailing list subscriptions. This wasn't necessary five or 10 years ago, but since then, we've seen companies proudly bragging about collecting an e-mail address from everyone who visits their page or downloads their product. A lot of those e-mail addresses are, unfortunately, fake. Worse yet, some of these fake addresses turn out to be the addresses of real people who have never heard of you. So, the first e-mail you send to any address that has been submitted for inclusion in a list should say "This address was submitted to us, to be added to our mailing list discussing the following products: [...] If you wish to be on this list, please confirm your subscription by [...]. If this e-mail has reached you in error, you may ignore it (and you will never hear from us again) or you may reply and ask us to help you identify where we got your e-mail address, to help prevent any further errors." A human needs to read and respond to this message. Always. The default behavior of hitting "Reply" should reach someone intelligent, rather than automatically subscribing or unsubscribing them. People will hit "Reply," and they will write a message. You need to respond to that message. You have to follow through.

Truly meeting people's expectations for privacy requires a lot of manual intervention. If this is too much work, don't just cut corners. The work will still be done -- but you'll be effectively foisting it off on your customers. If the list isn't worth the effort required to maintain it properly, just don't build the list.

In Part 3 of this series, we will talk about the importance of sticking with your policy, and a few more ways to think about what that policy should say.

This week's action item: Imagine that you have a personal e-mail account that has never been spammed. Try to find a company whose privacy policy you trust enough that you'd be willing to share this address with them.


Resources

About the author

Photo of Peter Seebach

Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive.

Comments (Undergoing maintenance)



Trademarks  |  My developerWorks terms and conditions

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Web development
ArticleID=11522
ArticleTitle=The cranky user: Respecting user privacy, Part 2
publish-date=04122001
author1-email=crankyuser@seebs.plethora.net
author1-email-cc=htc@us.ibm.com

My developerWorks community

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Rate a product. Write a review.

Special offers