Though the percentage of survey respondents who turn to social media to complain is less than who will complain to personal friends offline (52% vs 16%), the negative reports that make it to the Web have wider reaching and often permanent effects on your reputation. Considering more than 60% are influenced by what others have to say about a company online (whether they are personally acquainted or not), it’s important to optimize your service channel upstream to prevent the negative effects in social media.

How does your site score on customer service? Download our free customer service scorecard, with tabs for Retail and Software/Telco: Excel or Google Docs

Click to enlarge infographic.

Image originally posted on Zengage, The Zendesk Blog

Susbcribers, can’t see video? View this post on GetElastic.com

Interview highlights / summary

What is the background on the Elastic Path story with APIs?

At Elastic Path, the history and legacy of the company is the conventional ecommerce platform for retail, with a Web storefront, order capture, monetization etc. But one of the interesting things we’ve seen in our customer pool (digital content) are the things they were doing with the ecommerce platform — moving away from the storefront, and taking that functionality they were used to (merchandising, storefront, order managment) and presenting them in different touchpoints. For example, a magazine offers subscriptions for various mobile devices, in-app purchases within software, etc. Rather than creating a shopping experience, they were taking the commerce experience and putting it in their product.

This turned our paradigm of commerce upside down. In the past it was “push commerce.” Take the platform, wrap an ecommerce experience around it and push it out to customers. Quite often you would hear vendors talking about a mobile shopping experience or tablet experience, that’s a push conceptualization.

What we did was take a step back from push commerce, absorbing the ideas of API and taking it 180 degrees, to a commerce engine, where you do what you want, create your experience, and use the bits and pieces that you want from the commerce engine to power those experiences, through the API.

There are big differences between the 2 streams of API monetization. The simpler stream dealing with content provisioning, like Facebook Open Graph or Google Maps, is relatively simple. You put a request in, you get content out. But it’s not like commerce where you have a very long use case where there are multiple steps in the flow, and authentication and security is an issue at every single step.

So with our API, because we’re a commerce company, we’re not quite at the point yet where our customers would want to create public APIs. That is the next step, and we’re still conceptualizing what that business model would look like, and what are the technical issues around it. What we’re trying to do in the immediate term is to foster internal innovation to allow our customers, both within their organizations and with their trusted partners (marketing agencies, affiliates), to use the API to pull commerce into those experiences, and eventually they may open that up.

Who are the people that would use your API?

Developers in our client base and their trusted partners. Those trusted partners typically have had to make a very big investment. When you look at conventional SOAP and Restful API in a commerce engine, there’s authentication, security and issues around user flow, a lot of states to deal with, and in order to do anything with that, you really have to know the commerce system.

If you are a marketing agency who wants to add a click-to-buy button within a marketing campaign, its very difficult if you look through some of the commerce platforms’ developer guides. They’re not like the Open Graph where you read a web page and fire away at it, there are literally hundreds of thousands of pages. So many calls, so many individual elements, so in order to develop against that, you really have to immerse yourself in it.

We want to make it as simple as hitting up the Open Graph to build transactional ecommerce experiences. For example, you have gaming companies that have rooms full of developers, but they’re not commerce guys. And they don’t want to be commerce guys. And we don’t want to force them to be commerce guys, and we don’t want to force the company to go out and hire commerce guys in order to embed commerce into their products. So, we want to make it simple enough that as long as you have some measure of knowledge about Javascript or HTML5, you can embed commerce.

In terms of security, what do you see as the main needs around security, how do you make it secure enough without dissuading people from using it?

With commerce, it’s all about who you are and what you do. It’s all about authentication, and what kind of use cases you can do at a certain point in your flow. If you think about the conventional way, exposing the internal processes, trying to build security around that is a nightmare. You either have to secure each individual service point way down in your platform, or else you have to build a proprietary layer that’s a middleware security layer to authenticate before you get access. With our API, there’s a central integration point where everybody hits up. It’s form based, requesting access to individual services at any given time, and every element in the protocol is authenticated with a user ID.

What are the main focus areas that you have right now, are there particular audiences you’re going after? Or components of your API you want to offer up to the world?

We have a couple of focuses. The first is scalability. Some of our customers deal with pretty high traffic volumes and the issues around scalability are different from a content API — you’re not trying to push vast amounts of data through the API. It’s more about handling the traditional traffic issues of ecommerce, and transactions through the API.

Another focus is the ability to package up all the different types of features one would traditionally find in an ecommerce platform, and exposing them through the API. Not just 1 or 2 use cases. You can go into dozens or hundreds, whether looking up entitlements, placing an order, or going through order history, streamlining them through the API, without making it a monolithic chunk.

There’s always issues around versioning, and making sure that the API remains consistent even as the features and functionality evolve beneath it. You may add new payment methods, or have new merchandising rules. We want to disconnect the operations of the API from the functions underneath it so that it won’t suddenly break, but it will evolve gracefully.

With regards to monetization, for your clients who utilize APIs, how are they making money?

It’s a two-step process. First, the transition to an API-based strategy to grow transactional business. We do see increases in conversion and average order values when you start shifting from the Web storefront to new touchpoints (in a game, using software, etc). Making it easy for customers to spend money whatever they happen to be doing is the first benefit of moving to an API strategy.

The second step is moving towards a more open model, where certain aspects of commerce functionality may be opened up to the “public” (though I don’t think ecommerce APIs can l ever be completely open). But it will allow partners and affiliates to link in and maybe not place an order, and look up things like entitlements and authentication.

For example, if you were watching a movie on US Airlines, you paid your $5.99 to watch but didn’t finish it, you would be able to complete in your hotel through Lodgenet through an API enabled partnership. It could use the API to look up and see you have another 48 hours to watch it and pick up at the point you left off on the plane.

Are your current APIs an evolution from where you started, or did you have to go back to basics?

All ecommerce platforms since the beginning have had to have some form of Web services available, some combination of SOAP or early attempts at Restful APIs. You always had to integrate with catalog, inventory systems, fulfillment systems, etc. The use cases for this are very different than what we’ve been talking about. They’re all internal, they’re secured behind a firewall. We started looking at how an API can enable the consumer side, and there really wasn’t anything in the market. We really started on a blank page to conceptualize.

Do you have a strategy around versioning? How do you distinguish between versions today?

The general strategy is to maintain the front-end side, without versioning to maintain backwards compatibility. It’s a strategy of isolating the business logic and the data objects underneath from the consumption and service side of the API.

What are the benefits of Level 3 REST (for non-technical, business guys?)

It’s always about increasing revenues and lowering costs. If you think about the time, effort and money spent doing integrations, when you create and API-as-a-product type strategy, the integration is the most important thing — that’s what your product is. If the effort to integrate is too great, there’s no ROI there. Being able to deliver really advanced services that would typically involve crazy amounts of effort very quickly is huge. We’re starting to see concrete examples of this. Working with potential partners, giving them access to an API server, we’ve seen incredible results. Without any knowledge of our platform, being able to develop a commerce enabled click-to-buy into their product within a week or two with a very small development team, in one or two meetings. We don’t have a manual yet — one of the key elements of Level 3 REST is discoverability, everything is self-contained within the API payload. When you multiply that by all of the touch points that you need to be in, how much is it going to cost you to get senior developers that know commerce do something as basic as put a buy button on your Facebook store, and then your Android app, and then your iOS app, and then your HTML5 web app, versus Level 3 REST, where a junior Java developer could go ahead, stick that buy button in there and you’re done.

For more information on DCAPI, visit Elastic Path.

Tech Talk Tuesday is live on Facebook and Twitter every other Tuesday. For more information, visit Layer 7 on Facebook.

Some APIs are even monetized. Google Maps is a “freemium” API, API access is free if the application built will be free for all users, or licensed if the end-product will be itself monetized by the developer.

Then there are ecommerce APIs, or shopping APIs.

According to Brian Walker, VP and Principal Analyst of eCommerce and Multichannel Technology at Forrester Research:

A Shopping API is “a way of describing the exposing of core content and commerce functions in a programmatic way, over the Internet, for use either internally or by exposing to third parties. A Shopping API includes the ability to place orders.”

Put another way, typical commerce web services like customer information, merchandising systems, order history, search tools, product catalogs, etc. can be exposed to different consumer touch points, connecting through the application programming interface.

7 Examples of Shopping APIs in the Wild

Tesco API

Foodie.fm, a personalized grocery shopping app, uses Tesco’s API to build its Apple and Facebook apps — an example of a 3rd party leveraging a shopping API.

And of course, Tesco’s South Korean subway experience. Using mobile phones and QR code readers, commuters can grocery-grab on their way home without ever visiting the supermarket. An example of an internal use of the API.

Sears API

Sears augments its merchandising and creates a truly entertaining, interactive catalog for baby items.

Shoppers can answer quiz questions, listen to lullabies and download their lyrics, hover over hotspots and access customer reviews and social sharing tools. This is not your grandmother’s baby catalog.

Best Buy API

You can now conduct voice searches with nouveau-search engine Wolfram Alpha, Siri and Best Buy.

Search and compare prices, and access detailed information in or out of store.

Marketplace APIs

Outright is a freemium small business accounting software program that connects easily with PayPal, Etsy, Amazon and eBay.

Using APIs, Outright can call in sales, tax, shipping and other expense data directly from marketplaces and PayPal.

Verizon Wireless

Verizon is planning to allow both developers and consumers to take advantage of its upcoming “turbo charge” API. Network customers can tap into extra bandwidth to power their smartphone apps during times of high network congestion through a microtransaction API. For example, if a Skype call starts breaking up, the user can make a small payment to improve it.

The catch is the app must also use the API to enable the turbo option.

Nike

Nike’s FuelBand records biometrical data while you exercise and syncs it to your smartphone app to keep you on top of your fitness goals. Nike opened up its FuelBand API to developers to hack and mash up with music (announced at SXSW this year) — we’ll see what kind of wicked augmentations they come up with.

Path and Nike have also teamed up to create features for sharing your favorite runs with friends.

Not only is opening up the FuelBand API to other developers great for branding, it creates demand for the $150 gadget.

But the possibilities are endless.

Why think about APIs now?

FuelBand is just one example of new consumer products that will be increasingly connected, social and even commerce enabled. According to Forrester Research in 2010, 8 million American adults owned 8 or more connected devices in their home.

It’s undoubtedly even higher now.

The Web is key channel to service and sell to customers, but it’s a maturing one.

Consumer expectations for how to leverage their connected toys continue to increase. As consumers engage across wide variety of touchpoints, it becomes more complex for businesses to deliver great or even viral experiences, to market and extend the business leveraging that consumer’s network.

And innovators are creating these high expectations. Amazon is the perfect example of how you can leverage APIs to deliver consistent, relevant experience across touchpoints including the Kindle. A “single view of the customer” allows account holders to see the same personalization and site content across channels touchpoints.

How different industries use commerce APIs

Digital goods

APIs support in-app purchases and upgrades, subscription management, and entitlements management. For example, TapTap Revenge allows users to buy more tracks within the game. In many cases, a shopping API can be used to do much the same thing, instead of using the iTunes platform.

Sports Illustrated and many others provide access to subscription content across multiple platforms, recognizing entitlements to view content. But as new platforms are continuously emerging, without a scalable solution like a commerce API, keeping up will be very difficult.

Retail

APIs make it easier and cheaper to deliver consistent pricing, offers, features and content across form factors (screen sizes), without the need to support each system with its own resources, and to integrate multiple touchpoints (mobile, mPOS, kiosks, digital signage, IPTV) into a single commerce engine more efficiently — with your own existing teams. Marketing and customer service can be supported more effectively, reducing the total cost of ownership for development and integration.

For businesses selling through marketplaces, using APIs can be way to scale across multiple properties. 3rd party tools may be more costly than using your own shopping APIs, and don’t offer you the flexibility to innovate that using your own does. Ditto for social networks.

Brick and mortar stores can use APIs to enable offline orders that are fulfilled in a traditional way to take place in the digital environment. Fulfillment systems can connect through APIs to enable drop-shipping direct from both warehouses and retail stores, increasing efficiency and availability of products.

Your API questions answered by our expert panel

Our webinar Shopping APIs and How They Future-proof Your Business (available on-demand for a limited time) included some very lively discussion around audience-submitted questions.

What makes shopping APIs different from traditional content APIs?

Sal Visca: We have seen application programming interfaces for many years. Essentially, what we’ve done in the past is take a technology platform, its user interface, the business and data logic, and rip off the user interface from the technology stack, and say the services underneath is really what the APIs are. Then you would put different technology layers on top of that that – a SOAP interface, or web services, REST, and say “let’s just manifest the services that are in the platform through these different technologies” and have this multi-channel access in. So in a mobile web interface, you’d have a mobile application calling those APIs.

At Elastic Path, we tried to look at this by turning it on its head. Instead of looking at the services we offer in the platform, and manifesting those, we turn it around and ask “how are these services going to be consumed by the end user?” The reason we’re excited about this at Elastic Path is it enables what we refer to as “Elastic Commerce” – the frictionless, social, everywhere type of commerce that looks at the Internet of things, and the ability to weave commerce transactions into the context of life.

Brian Walker: The ecosystem has evolved to the point that APIs are core to business strategy. A business leader needs to think about APIs as a way to drive and extend their business. It’s not just about integrating 2 technologies together and leveraging APIs to do that in a programmatic and efficient way. What makes a shopping API different is it’s a productization of what APIs can do, and it becomes part of a business strategy moving forward. Think about a shopping API as an investment, and in itself a channel that can be utilized in a wide variety of ways to drive the business forward.

Which consumer devices are best positioned to benefit from a Shopping API?

Brian Walker: Those that are best positioned are conventional Web as well as touchpoints like tablets and smartphones. Whether building out versions of your site or developing apps for them, the shopping API can enable a business to extend and embed commerce into wide variety of devices more easily. Digital display advertising, interactive TV and more futuristic applications, like appliances and cars represent what’s perhaps coming. It will change rapidly, but it’s hard to predict what will resonate the most. Commerce will become more increasingly embedded within the product itself. In order to “future proof your business,” here’s a good opportunity to think about how laying this foundation can enable you to adjust and adapt more quickly because you can expose more quickly and embed commerce within products and services.

From the consumer POV, how will they perceive the benefits of a Shopping API?

Sal Visca: Consumers themselves won’t care so much that there’s a shopping API, they care about the end-user experience, and the fact that a shopping API can enable new forms of innovation. In my role, I talk about some of these silly examples like being able to order from a watch using near-field communication. The end-user doesn’t have to think too hard about going into a shopping experience, they’re just going about their day-to-day business and using different devices to interact with life. Whether they’re playing a game, or in a social context, it’s what’s enabled by underlying technology like a shopping API that can really support those new models.

Brian Walker: The consumer is looking for it to work, and for it to work on the next device that they own. They can’t understand why it wouldn’t work, or why there would be a problem transacting when they can elsewhere, and the bar is set higher and higher by their experiences with other companies. The shopping API is an important tool for the business to react to how things change, and enable them to work in a consistent and scalable way. You don’t want an offer on your tablet app that is no longer available because it is sold out. If you can’t keep your different consumer touchpoints in sync, you’re going to cause frustration and increase your customer service cost. Although customer doesn’t care, they do care about the quality of the end experience.

Can you describe how as a publishing company with multiple websites, we might capitalize on shopping APIs?

Sal Visca: A shopping API enables new forms of consumption. So, if you have multiple sites with content, you can break up that content into more fine-grained components — maybe a chapter, maybe a complete book or volumes of books — whatever the granularity is, an API can now enable you to allow those to be consumed. E.g. if you’re reading a book, and you reach the end, you now have a promotion to buy the next version of it. Or, if you’re a law firm reading an article, and you need other case files, the recommendations we’re all familiar with in an ecommerce experience. An API allows the elasticity and flexibility to take your digital content and intellectual property, and package it up in different ways to be consumed in different ways.

How should we get started with a shopping API?

Brian Walker: It’s easier to begin with product catalog as a way to begin working with APIs, and begin understanding how to establish that. Focus primarily on an existing project. For example, developing an app or mobile site is a great opportunity to take a step back and recognize that investing in APIs could establish that connection programmatically. It may take more time and money up front, but beginning that work now, leveraging an existing project, is going to pay dividends in the future.

Another important issue to mention, APIs are not a project, they are a program. One mistake clients may make is thinking of the API as a project to launch, and moving on to the next project. They need to recognize that having someone from the business side as well as developers working on APIs as an ongoing program is critical to further developing them, leveraging them and supporting them, and providing a platform to grow the business on. It’s not a situation where you launch it and walk away, and sometime come back to it to do an upgrade.

Sal Visca: At Elastic Path, we’re all about agile development, learning, evolving and continually refining your usage. And in terms of getting started, we always recommend to start with a mobile app or web interface and try to call some of the different APIs, and see what you get back. It’s amazing, once you get started, it begins to enable new forms of innovation. This needs to be an ongoing process that you incorporate into your overall process. As we get new form factors and new devices, it’s important the API doesn’t require a large amount of understanding of the underlying system and all the objects that get touched during that process. It’s easy to slap on a REST interface or Java services, anyone can do that.

You talked about using shopping APIs to enable 3rd parties to integrate with our ecommerce platform. How about using shopping APIs for internal expansion, such as splitting the front-end from the back-end, putting the front-end on the cloud, and so on?

Sal Visca: I was working at SAP, a very large software company, and we found we had to build APIs between internal components to ensure that we were building nicely architected, layered solutions. It’s amazing, if you put an API on a core set of services, it enforces a certain discipline on how internal development is done. And you become very componentized in your internal development, which is very key for not building old, monolithic systems, and enabling high adaptability to innovate and move quickly in the future, whether it’s a public or private API.

Brian Walker: Internal flexibility, and separating the front-end from the back-end is probably the most important value of an API strategy today. Exposing through 3rd parties is an interesting way that shopping APIs will continue to evolve, but the value proposition for businesses is about the increased flexibility internally.

What business models would be most effective at monetizing an API?

Sal Visca: Obviously, you can get into transaction-based models where you’re providing Commerce-as-a-Service, which allows a vendor to put a product into a catalog and sell it to end consumers. You have a transaction price, and some percentage of that price. Those are models that we’re fairly familiar with. As we start to embed commerce in other applications, like a game — I have credits, I want to buy more ammunition, these kinds of things — there’s lots of micro-payment type models that come out of that.

Brian Walker: A lot of it does depend on what types of products a company is selling, and what’s happening in their industry as a whole. For example, if you’re a software publisher, you’re probably feeling a lot of pressure at that $40-$50 price point. We’re increasingly seeing, whether it be a game or an application being sold at a lower initial price point, the carving up of different levels or features / capabilities of the application, which might increasingly be delivered as a service itself, and allow users to pay as you go or pay for increased capability or features within the product. Media companies have the opportunity to deliver cross-platform content, and take a direct role in the commerce that they want to do, not relying always on third party marketplaces for distribution.

Bottom line, there will need to be a lot of experimentation, embedded and as devices continue to evolve, and integrated solutions within stores that can leverage ecommerce capabilities for “endless aisle” etc. Shopping API can help that occur much more efficiently than in the past.

What are some use cases of the Shopping API that couldn’t be done as easily with existing shopping methods?

Sal Visca: If you’re in the retail space, when a customer is in-store and looking at a camera, using NFC and a touch pad can bring up generic information, reviews etc. A flexible API in the mobile shopping app can support that. In digital goods, it’s more around I’m watching video, and at the end I’m offered a promotion to buy the next episode — to get people while they’re consuming content. Having a flexible API that can be embedded in consumer applications would have been extremely difficult in the past, because you have to know so much about the underlying system, get back information in the mobile app and parse it, and deal with it. Now, you need to know a lot less about the underlying systems.

Brian Walker: Look at the cost to integrate to a marketplace when Amazon began, or the early days of eBay, and even now. Those projects were in some cases hundreds of thousands of dollars. Shopping APIs streamline costs to launch a mobile site or mobile application, and really, it’s about lowering the cost to drive and expand the business. Not that you couldn’t do these things before, but it’s about making it more efficient, more readily accessible and a core part of the business strategy. An area of investment and focus, rather than a project.

Interested in learning more about APIs? Please view our on-demand webinar Shopping APIs and How They Future Proof Your Business, and stay tuned for our next post.

• 31% are worried that their internet behavior will be tracked
• 54% don’t trust most online banner ads they see
• 55% are worried about getting a virus
• 57% are afraid of receiving spam from advertisers

Click image to enlarge

Nevertheless, ad spend is expected to grow by 23% this year, and Facebook will pull in $5B in ad revenues. Are advertisers getting their money’s worth?

Kin is an engineer who has been building database driven web apps for 12 years, and working with data for over 20. Watching API usage really rise in the last few years and seeing it drive innovation in social, cloud computing and more, and so much talk on the technical side of the world, Kin began to explore the business side of APIs. What does it take to deploy, what business elements do you need to support an API? Not just what resources from what department, but what are the building blocks you need to support developers?

As an API Evangelist, Kin follows a broad spectrum of API players including Twitter, Facebook, Google, eBay and Amazon to figure out what the best practices are in order to educate business leaders and developers. He currently works on behalf of a local online advertising platform CityGrid to market its API to developers to bring in more, and cultivate the ones they already have.

Interview recap

What are the big mistakes businesses make when serving developers?

• API registration. Developer approval can slow down the process
• Poor documentation. If you can reduce onboarding time from 8 hours to 30 minutes and make it really easy to get going with great documentation, your developer’s chances of success increases
• No quality code samples. Provide samples in as many programming languages as possible
• No clear value proposition. A developer shouldn’t have to think too hard about why he or she should get hackin’ on your API. Offer real value

What’s the best way to gather feedback from developers to provide input into your roadmap?

Within your API ecosystem, a forum where devs can post comments is key, as well as some sort of email address or ticketing system. But you can’t expect developers to only dialogue on your domain. Have a presence on StackExchange, Twitter, LinkedIn, Stumbleupon, Reddit, HackerNews, etc, where developers already are. Gather feedback within and outside your ecosystem, and evangelize it internally to evolve the roadmap. (That’s a truly “open” API).

If you’re a developer, in terms of ecommerce, how important is social?

As a business that is using other people’s APIs, what are some of the ways can you protect yourself from that API not being around tomorrow?

There’s a lot of complaints around APIs that they can disappear at any moment, they don’t care about developers, or they’re unstable, and that’s true in some ways, but it’s true with any business vendor. The corner sandwich shop should have multiple vendors, if one doesn’t deliver one day, there should be a plan B, C or D.

But that doesn’t always apply, especially when it comes to Twitter and Facebook. Where else do you go to get Tweets? It’s difficult to have a plan B, but you should have some form of cache so that when Twitter breaks (which it often does) your app can still function. Have some kind of failover within your code. When applicable, have multiple APIs. For example when Google stopped supporting their Translation API, and then brought it back as a paid product, there are a number of other you could substitute to keep your app working.

Social is hot, but where is there opportunity outside social to build great new experiences in the ecommerce world?

Twitter Firehose and Facebook Timeline are obvious, second to that are some of the pioneers in the space like Flickr. Instagram built a very cool app with social hooks to the other networks, and these hooks made it a viral app. Another one is the video space, we haven’t seen it all yet. Youtube doesn’t embody it all, there’s room for innovation from some of the quiet players out there. E.g. mashups, splicing in products into television, movies, video games, layering in content to sell things to users, then beyond that console or online gaming. APIs allow splicing of products and services to embed commerce.

Kin and his partner have authored The Business of APIs, available on Amazon. Check it out.

For a refresher on what the new law is about, check out Silktide’s brilliant (and humorous) explanation of it.

I was asked in an interview by Mike Arsenault of Rejoiner last week what I thought of the law’s impact on personalization. My biggest concern is that consumers unreasonably fear cookies and their impact on privacy, without understanding how they make life easier for web users in terms of personalization and time-saving.

According to the eCustomer Service Index survey conducted by the IMRG and eDigitalResearch:

• 75% of UK consumers had never heard of the e-Privacy Directive before taking the survey
• After being “informed” (for the purposes of the survey), 89% of respondents indicated they believe the EU cookie law is a positive step towards online privacy
• 79% believe changes are needed to address the lack of public knowledge about cookies
• 33% believe cookies may be used for viruses in Trojans
• 23% of consumers do not object to cookies that improve their browsing experience
• That means 77% are against cookies that improve their browsing experience!

Website optimization is about usability, persuasion, and addressing the FUD inside users’ heads. If you do business in the EU, you’re going to have to ask for permission. And the key to gaining permission is in your copywriting.

Remember to:

1. Stress the value proposition to the user of allowing cookies.

If the features you offer that require cookies are attractive enough, users will submit. Don’t be afraid to be specific, and think about what the customer wants to get out of your site.

2. Explain what cookies are and that they are not used for a sinister purpose on your site

Laws like this only reinforce the idea that cookies are bad. You have to re-educate the visitor that not all cookies are evil, and that the ones you use are not going to harm the user’s computer or track personally identifiable information.

3. Use bullet points in accordance to web usability best practice

Regular web copywriting standards apply. Users don’t want to read blocks of text.

4. Include a link to a more detailed privacy policy

Show you have nothing to hide by linking through to a reader-friendly privacy policy, written to address the FUD (fears, uncertainties and doubts) that your visitors are likely to have.

In addition to crafting your copy, download EU Cookie Law: a Guide to Compliance which includes information on performing a cookie audit, adhering to the ICO’s requirements and understanding your UI options for implementation.

Image credits
Edudemic
The Daily Dose
The New Yorker

Perhaps tablet penetration is only 13%, but 69% of tablet owners make a purchase from their device every month.

This week’s infographic is courtesy of Mobtext and inMobi: The Role of Connected Devices in the Customer Sales Journey. It breaks down how tablets, laptops and mobile phones are used at home, at work and on the go throughout the purchase funnel.

Click to enlarge infographic to full size

Surprised that tablets are rarely used in the purchase funnel on the go? Not so surprising when you consider 9 out of 10 tablet owners prefer wifi to 3G. Smartphones are more likely to be connected to 3G, and perhaps tablet owners don’t want to shop over insecure wireless networks.

Considering many report tablet conversion rates to be the same or higher than desktop, ignore your mobile strategy at your own peril.

Custom Facebook buttons enhance the connection between consumption and social networking, allowing consumers to express how they feel about brands and products – a trend that’s catching on thanks to Pinterest.

But just having buttons isn’t enough – like any call-to-action, they should be optimized.

5 Tips for Custom Open Graph Facebook Buttons

Tip 1: Style them like a Facebook Like button

Early adopters of custom buttons must understand the average web user won’t recognize these as Facebook sharing buttons right off the bat. Unless they look like Facebook buttons, customers may not understand.

Styling the button using the Like button’s color/font helps users understand what the heck they are. Though in the beginning, many will still be confused.

Another option is to incorporate the Facebook icon into the button. This example is my rendition of what it could look like for a gaming product like EA Sports MMA.

Tip 2: Put a callout on your site explaining what they are for

Deb Shops puts a hot pink callout in its navigation, so no matter where you land on the site you can click on the tab to learn more.

A landing page gives you an opportunity to create excitement around the buttons while clarifying what they mean.

Tip 3: Use this information for marketing campaigns

Personalization tools often suffer from misunderstanding true user intent. Just because someone viewed a product, doesn’t mean they want to buy. They could own it, or they could be researching or comparing items.

Hypothetically, American Apparel could use its Want, Love and Have buttons to gather input from visitors that could be used for site or email merchandising.

The examples shown from American Apparel, Hayneedle and Deb Shops are powered by 8thBridge’s Graphite Platform, which has the ability to feed this information back into email campaigns for better targeting.

Tip 4: More isn’t better

Be judicious in your choices of sharing buttons. Don’t use too many buttons (remember the “paradox of choice.”) And avoid labels that are too similar (Like and Love, for example).

Tip 5: Get Creative

Angry Birds has teamed up with MTV Voices to promote its secret level created to promote anti-cyberbullying.

Players can access the secret level only after posting a positive action on MTV’s Draw Your Line app (not to be confused with Draw Something).

Notice the “I Care” button is used far more than the other available social sharing options.

Digital products enjoy even more possibilities for the Open Graph. The social hooks can be baked right into the products themselves. For example, Netflix could publish “Linda is watching Napoleon Dynamite on Netflix.”

We’ll be watching the unfolding applications of Facebook Open Graph.

Today we drill down into the challenge of converting free users to premium — with tips to maximize your potential.

Note: this article focuses on freemium models with premium “upgrades,” rather than free apps with add-on options that may be purchased to enhance user experience.

Stop selling free

Think it’s easy to turn a free user to a paying customer once they get hooked on your product? Not necessarily. If your product offers free and paid versions, users who choose the free option off the bat are likely are not your target for premium anyway (remember, there’s a difference between a free trial and a free version).

Your business plan may be to capture market share by building a large free user base and monetize 1-5%. But if you want to get paid, aim to sell your paid version upon sign up.

Too often, signing up paid users is an afterthought, evidenced in the design and navigation of websites. Premium product and pricing information is often shrouded behind a Pricing link or tab.

Another mistake is assuming a new visitor wants your free version. Zoho offers one call to action – “Sign Up Now!”

Clicking the juicy red button leads you to a sign up form for a free version.

It’s an enclosed conversion funnel – navigation is removed. There is NO indication on this page that there is a premium version.

Your home page is critical. Make sure you present why your pro version is kick a$% somewhere on the home page.

Persona-lize your options

Before you design your landing pages and sign up funnels, make sure you’ve clearly defined your premium target market. Use marketing personas. Don’t just throw up a bunch of columns with checkmarks! Understand how each persona will compare your prices, and ensure he/she can select the right option easily.

Present pricing tiers wisely

Businesses that provide more than simple free/paid options (such as a menu of subscription tiers) must optimize their presentation. The way you present pricing options (and even the order you present them) matters!

If you’ve seen Dan Ariely’s TED talk, you may recall the portion where he explained the brilliance of the Economist’s seemingly silly presentation of subscription offers:

It appears to be an oversight that the print subscription and print-plus-web subscriptions are both the same price. But this presentation has the effect of making the print and web option look so much more attractive than just the web edition, no?

Ariely tested the offer with and without the second option. With the funny middle offer, 84% chose the “combo deal.” Without, 68% chose the web-only edition, at a much lower price point.

Removing the option nobody wanted did not optimize the page.

In fact, the useless option served to help people make sense of the options presented, and help them make a decision.

But a magazine subscription is not the same as a freemium business. The pricing tiers correspond with differences in functionality or service levels. There’s no point in copycatting this tactic if it doesn’t map well to your business.

It’s very common to highlight one option on a pricing table. Perhaps this is the most common option, or you want to position the middle priced option against a higher one so the middle looks more reasonable. Fair enough.

But the “highlight the middle” trick doesn’t make sense for all freemium businesses, either!

If you present tiers based on business size or other categorical market segments, there is no need to highlight one option over the others. Small businesses are best to choose the cheapest option, medium the middle tier, and large the top tier. No psychotactics there.

The price-positioning trick only works when a user could reasonably choose between multiple options.

Another tactic is to use “badges” or other visual elements that make one tier stand out among the others. Again, this is not effective when options are segmented. In this case, it is irrelevant to services businesses.

For more pricing table tips, check out Bryan Eisenberg’s entry designing effective pricing tables.

Converting the choir

Ideally, premium users are won at sign up. But there’s still a chance to upgrade free users, if you do it right.

Stay hungry, stay foolish

A twist on Steve Jobs’ famous saying, stay hungry for media attention. Get as much PR for your new releases and feature additions as possible. Keep your free users hearing about the wonders of using your premium version.

But stay foolish – don’t build these new features based on what you think is sexy. Involve your free and premium customers in shaping your product’s future through feedback and surveys. Don’t waste your time building features your customers don’t want to use (or pay for).

Bake carrots into your cake

If possible, bake conversion carrots into the free version. Show off premium features by making them accessible in navigation, but throw up an upgrade page when these carrots are clicked. This way you present your message when the user is in the right mindframe to care.

Target your home page

Cookie users to recognize returning, registered users, and present different home page messaging than you offer non-users. Romance new features, highlight companies-like-them that are using your service/app, show video tours and the top ‘X’ reasons to upgrade.

Oh yes, and always be testing your tactics to learn which are most effective.

Click to enlarge infographic

How could this impact ecommerce?

Should this become law, we could see more people spending less time on social networks, which could impact the effectiveness of social media marketing. It could also cause more fear of sharing personal information like names, addresses and phone numbers to make purchases online and use apps and subscription services, whether these activities are related to “cyberthreats” or not.

Infographic credit: Paralegal.net