In my last post, Cookie open disclosure is good business, I suggested that disclosing what you are recording of user interactivity on your websites is just good customer management. I’d like to expand on a few implementation factors. If you do it right, I think it can expose new service lines, better margins and enhanced value definition for your customers.

Tactics

The EU guidelines, discussed in this post, differentiate between essential (strictly necessary) vs non-essential. Essential cookies are often implemented as session cookies and non-essential ones as persistent tracking cookies. The cookie guidelines which require the company to fully disclose and enable editing of those cookies by the end user only refer to the non-essential tracking elements.

I don’t think it is likely that the US will demand or ever enforce an explicit “opt-in” for web cookies but it might not be bad to at least have that incorporated into your thinking. If so, I mentioned in an earlier post the concept of putting the Opt-In and eventual cookie maintenance under a “Thanks for telling me” button.

How to organize the non-essential ones? One might categorize them around:

• Ease of Use / Navigation
• Performance
• Security
• Functionality
• Social

Software Engineers can easily own the Use, Navigation, Performance and Security attributes in terms of what is captured but Product Management should still be ready to provide the wrapping descriptive words.

Social attributes are where there is a bit of trouble at this point due to having to often rely on partners. Just because you drop a widget from a social network: Google, Facebook, Salesforce, etc., doesn’t mean you have abdicated responsibility for the compliance of that cookie maintenance too. You may not be able to provide the detail level editing, but you will have to give the user some abilities or make the partner provide it with their widget. While the younger generation doesn’t mind sharing everything some of the bigger wallet buyers don’t really want to share everything they do just because they Google or Facebook accounts.

It’s the functionality that is variant to your products which will have the most flexibility and value to you. Common customer tiering and product details are the easiest to think of.

Tiering

The classic categorization customers, silver/gold/platinum can be quite useful for enhancing a simple web experience. Carry over some features of frequent buyer programs for users: a) record of past transactions, for example; b) additional partner/vendor content; c) couponing, etc. Explore how cross-sell and up-sell fit into the long term value and timing of customer purchases and if you can enable it via a web feature. There is a positive human dynamic for people when they see just how close they are to the next “tier” of features & discounts available to them. Many companies expose the value of the “timeline” trigger, utilizing a calendar to trigger future purchases: “It’s time to get your air filter.” Use all these same concepts in enabling cookie tiers with each tier of profile completion or customer engagement. Finally, by combining into one editable attribute one attractive user feature with one less-attractive feature, you might be able to keep users engaged. For example, the user likes the calendar feature but is less interested in providing their email address. By making one a condition of the other, you get what you want and in the end, the user is in control. No surprises

(Web) Product features

I think it is very healthy for the product management team and the software development team for that matter, to think about their customers and to consider how they’d interact with that customer if they knew something dramatically less about them. How can we quickly re-determine the customer’s interests? Too often we rely on assumptions and stop learning each session. Pay attention and learn from the searches and navigation paths. Explore the ability to retroactively learn from A/B testing. By at least discussing these elements before all the web functionality is finished, the final web experience should at least be flexible for the future and for when you want to enable the full cookie disclosure.

As I mentioned earlier, think of your products from a detailed services perspective. What value added services can you bring to the table with your customer service staff? Is there any way you can enable a few of your users attributes in a relationship with hot Internet service (Instagram, Waze, etc.)?

Is there a parent organization for your visitors?

Are your web visitors individuals or do they visit through corporate (BtoB) relationships? This can be one “out” from having to do too much in the way of enabling personal choice. If the business you have a relationship with will provide an overriding “approval” construct for cookies (sharing of data), then the above can be moot. This is an accepted allowance of every US and EU model I’ve read. For example, if you are providing preferential pricing to all of a company’s franchisers, it is that agreement “cookie” which you will abide by. An individual theoretically does not have further rights to change or eliminate attributes outside of that organizational agreement. The employer’s wishes (or contract) will take precedence.

As I said in the earlier posts, I think the model for how to think about these disclosures is best reviewed by how the European community is addressing it. In particular, I think UK’s ICO has some helpful foundational data: http://www.ico.org.uk/for_organisations  has lots of good examples of the way to look at the various factors.