Subject line: You have a credit waiting for you at 1800Headsets.ca

Email body:

We thought you should know, you have a $10 credit with us
You earned it, so why not enjoy it?

$10 may not sound like a lot, but ten bucks could get you 25% off a cellular headset, an extra 17% off a new Bluetooth headset, or even better…

Take $10 off any:

* Wireless Headsets
* Computer Headsets
* Home Office Headsets
* Wireless Telephones

There are many new headsets at 1-800-Headsets.ca

Call a friendly Headset Specialist at:
1-800-HEADSETS (1-800-432-3738)
9:00am to 7:30pm Eastern Time Mon – Fri

Or claim your $10 credit online by clicking the “Use Your $10 Credit Now” button below. Your Priority Number will be entered automatically at checkout.

Customer # HDS1231443
Priority # EH59720

There are several things I want to point out about this email’s brilliance:

1. The subject line gives a strong reason to open the email, piquing curiosity about the credit: “You have a credit waiting for you at 1800Headsets.ca”

2. “We thought you should know, you have a $10 credit with us” as a headline reinforces the promise of the subject line

3. Suggesting “ten bucks could get you 25% off a cellular headset” is smart. I purchased a computer headset. I’m more likely to be intrigued by a cellular headset than another computer one. It’s possible 1-800-Headsets segments customers by product category and customizes the message accordingly.

4. The credit is auto-applied by clicking the big (and I mean big) shiny red button. This makes it easy for the customer, no promo code to remember. It may also create urgency as to have the credit applied in the future would mean digging up the email and clicking through it again.

5. The products on the right hand side all have value propositions: best selling, best range and perfect for noisy offices. If you want to increase your click through for featured products, give the customer a good reason to be interested in them.

An added bonus of the credit idea is you are not reducing the perceived value of your products by reducing the price. Rather, you are selling at full price (and full value) and giving the customer virtual dollars to spend. Sales are boring, and “come back and we’ll give you 10% off something” is overdone and not that exciting.

Linda: We’re seeing a lot of changes with Yahoo and Bing merging. Does that make things easier or more complicated for advertisers?

George: We think it will help search advertising, at least in the short term. The richer data set afforded by combining the Bing and Yahoo.com traffic will be a boon to those who know how to exploit the long tail, and having one less set of copy changes to make won’t hurt either.

Long term, is the industry better served having one larger competitor to Google or two smaller ones? That’s a tough question. To the extent that Google acts as simply a marketplace where advertisers compete against each other for placements, one could argue that a Google monopoly poses no real risk. On the other hand, given an absolute monopoly, who’s to say that Google will stick to the auction model? If negotiated placements yielded more revenue per impression and greater profits, they’d drop the auction in a second. I don’t think that’s likely to happen; I think the reason for Google’s success lies in the fact that the ads are cost effective when managed properly, and moving away from that model makes them just another portal.

Linda: Keeping up with the changes in search engines and advertising program capabilities is a full time job in itself. It’s almost as if when you take a week’s holiday, you’ve surely missed a major announcement or change to the way things are done. The result is do-it-yourselfers may be relying on outdated books or blogs for guidance in managing their PPC campaigns, and even the professionals can be behind the times. In your experience, what’s the most outdated tactic that is still in use by too many advertisers?

George: Things do change all the time but in many senses the fundamentals haven’t changed, and what surprises me is the number of folks who still don’t seem to know the basics.

The fact that so many folks are still bidding by position just amazes me. In fact most of the platforms available for rent and used by many agencies are nothing more than position crawling systems. Even when turned to “efficiency targeting”, they find efficiency by hunting and pecking for the right position, rather than measuring the value of traffic, bidding what makes sense, and letting the position fall where it may. Position crawling guarantees inefficiency and lost opportunity, but even though careful studies have proved that the value of traffic is largely independent of position, people still use position crawlers.

Linda: Surely ignorance is not bliss! That reinforces the importance of having a search manager that really knows what they are doing. Often paid search is outsourced because the retailer does not have the in-house expertise to manage or even understand a campaign, which leaves the program without much oversight. How can you verify your campaign is being managed well? When do you know it’s time to fire your agency?

George: The devil is in the details. I outlined a process for a top-down evaluation of a paid search program. It’s imperative to periodically take the program apart to make sure it is being managed well. Too many folks assume that because they’re using a well-known, expensive agency that their program is therefore well-managed.

Certainly, you shouldn’t have to micro-manage your agency; if you do, what’s the point of outsourcing? But if periodic, detailed evaluations of the program reveal significant problems, the solution isn’t micro-management, it’s finding a competent agency.

Linda: I suppose when clients comes to you after working with another agency, there’s a certain degree of “reworking” you need to do. In your experience, what is the biggest (or most common) mistake that online retailers make in paid search?

George: The biggest mistake is also stunningly common, it’s failing to separate results of brand search and competitive search. Particularly for companies that do a great deal of offline marketing, brand search represents a fundamentally different subset of customers, those who are proverbially ‘walking through your front door.’ Crediting these sales to paid search efforts leads to tremendous overspending in competitive search.

Advertisers mistakenly believe that since the overall cost to sales ratio is reasonable, they’re spending money wisely. If we think instead about the law of diminishing returns and the question: what happened to the last $1,000 we spent and what would happen to the next $1,000? We’ll end up seeing that those answers are all found in the competitive non-brand search program, because that’s where all the incremental spending happens.

Linda: Speaking of keywords, it’s rare to talk about paid search strategy and escape the topic of the “long tail.” As you mentioned earlier, those who know how to work the long tail have an advantage. [Reader note: “Long tail” queries refer to searches that happen only a handful of times per year (maybe only once) can make up the lion’s share of clicks and sales.] What is the best way to capture the long tail? Is the broad match type with a thorough negative keyword list the answer, or should you try to predict the tail with keyword research and exact match terms?

George: I’ve written about this a good bit recently. The importance of the tail does vary a great deal from advertiser to advertiser so it’s not quite true that it matters tremendously for everyone. However, when it does matter, there’s no question about it: broad match by itself is not the best solution.

The right way to approach the tail is to build out the keyword list thoroughly and carefully, with attention to landing pages and copy to maximize both click through and conversion rates. Then, with sophisticated bid management and flexible attributes applied smartly, the real power of targeting bids to the differentiated value of the traffic takes over.

We like using broad match as a catch-all with lower bids on the broad matched versions than the exact matched versions. The keyword list can never be perfectly comprehensive, and broad match is tremendously valuable for catching word orderings and typos that you’d never catch with exact or phrase match.

Linda: Yes, sometimes the queries that trigger your ads can be very irrelevant (even humorous!) We would get searches like “granny cart” triggering our ecommerce software ads at Elastic Path, for example. When you add them up, there truly is a long tail of negative matches that can really dilute your click through rate.

Linda: If you’ve added sufficient negative matches and a keyword still suffers from low click through or abysmal conversion, Is it ever a good idea to delete the keyword? What are some strategies to turn a “dog” keyword into a “star”?

George: I once went so far as to say “there are no bad keywords, only bad bids.” That might have been a bit overstated, but my point was simply this: there are very few keywords – assuming they’re reasonably targeted — that draw in traffic of zero value. The value might be small, but it’s rarely zero. So, first and foremost is the notion that it isn’t a matter of finding keywords that “work” on the first page, and turning the others that “don’t work” off. Bid the appropriate amount and take whatever traffic you get.

Now, it is possible to improve the value of the traffic on a given keyword by identifying negative associations to knock out the wrong traffic, and by making sure the copy qualifies traffic as much as it can. If you sell “desk chairs”, but yours start at $350, where Staples has “desk chairs” for $35, you may find “$350 + for quality office chairs” helps steer the bargain hunters elsewhere.

To a large degree, paid search is dominated by mass marketers. Keywords that speak more to mass market intent can be tough for niche marketers who don’t have selections that appeal to the mass market.

Linda: Ad copy, like any copy, can benefit from split testing. What have been some of your most effective PPC tests? Are there any “rules” to live by?

George: There are very few rules that apply to every advertiser, so maybe one universal rule is to test assumptions! In truth, what may be a universal rule is this: never assume that the traffic on Google.com will perform the same as traffic on Google’s syndication network – even more true for Yahoo and its syndicates. Separate campaigns and measured bid differentials for the engine and its partners almost always delivers positive results.

We have some very exciting results from Yahoo’s new syndication bidding settings that should yield more revenue for our clients, and for Yahoo.

Linda: Sounds juicy! For my final question (you cannot interview a guru without asking something to this effect): where do you see the future of paid search going?

George: The two biggest changes on the horizon are likely to involve the ad formats and how paid search integrates with other marketing efforts.

Google is testing and testing to find formats that generate more revenue per impression, and they may find something. I don’t think product images are going to be it, though. Someone searching for “Pet Supplies” isn’t likely to respond to any particular product image. That said, giving marketers and agencies flexibility to design appropriate display ads for different levels of search depth might work. Providing a plus-box like expansion to the next level of depth, rather than all the way to the bottom with products, might be the best solution.

The ability to parse credit between multiple ads within a search program and across multiple marketing programs will become imperative. We’re launching an attribution management solution for our clients by the middle of March, and I’m sure other agencies will do the same. The better we understand what advertising dollars truly drive sales, the more efficiently we can allocate resources.

It keeps getting more complicated, but that keeps it interesting for us geeks.

Linda: It sure does! George, thanks again for sharing your brain. And now, we open up the floor to questions…

Can’t see video? View it on Youtube.

Can’t see video? View it on Youtube.

Here’s an example regarding canonical URLs and duplicate content:

Directory form, www.google.com/product(/)
www.google.com/product (canonical), try version:
www.google.com/product/

with: suboptimal behavior when trailing slash added
* includes product main pages in directory form without a trailing slash

200 status code given when slash added to Google Products’ canonical URL, Sept. 2009:

Avoid multiple URLs that serve the same content. From the example above, the good news is that visitors will reach the content no matter which version of the URL they choose. This is because a “200 OK” status code is given for both URLs. The bad news is that each of these URLs will get crawled and indexed by search engines, creating duplicate content. Search engines will have a tougher time deciding which URL is the canonical. Also, each URL will have its own reputation. Using a 301 on www.google.com/products/ will consolidate this valuable reputation so that the canonical can rank to its fullest.

404 status code given when slash added to Google Finance’s canonical URL, Sept. 2009:

Prevent 404s. A lot of visitors will try to reach Google Finance with the URL finance.google.com/. Many others will try www.google.com/finance, but a large number will also try www.google.com/ finance/, which leads them to an unhelpful 404 page. Some visitors will assume that the service is down (“Why wouldn’t www.google.com/finance/ work?”). Others might try another form of the URL, but say, “I never know which URL to choose for Google’s products!” Think of the most common URLs that visitors might try in order to reach your product, then 301 redirect these to the canonical URL. This will prevent a lot of frustration for users who access your product by typing the URL in their browser’s address bar.

404 page shown when slash added to Google Finance’s canonical URL, Sept. 2009:

To see the whole shebang, download the SEO Report Card < here.

With mobile commerce (mcommerce), merchants can reach potential customers as they commute, wait in the lobby at a doctor’s office, or eat lunch in the company cafeteria. But the mobile Internet can pose something of a challenge for web designers and developers, requiring an additional level of project planning and aforethought.

When we design websites for desktop or laptop computers, there is actually a tremendous amount of continuity. Sure, we might complain that Internet Explorer 6 is quirky; or wonder why Google Chrome and Apple Safari, which run on the webkit engine, manage some margins differently. But, for the most part, we can depend on a very consist user experience across web browsers, monitors, and operating systems. This is not true of the mobile Internet.

The iPhone, as an example, has a 3.5-inch diagonal, widescreen multi-touch display that is 480-by-320 pixels in resolution when held horizontally, and 320 pixels wide when flipped vertically. So for which resolution do you design?

If everyone was using an iPhone or a comparable smart phone, it would not be too bad. In fact, it would not be too different than designing for desktops and laptops. But what about a mobile Internet user in Africa, where the average screen width is only 120 pixels? You can bet a fixed width layout won’t work well on both of these platforms.

And it gets worse. The iPhone uses a mobile version of the Safari web browser which manages XHTML, CSS, and JavaScript like a champ. While an older handset’s browser, which probably cannot be upgraded, might not offer HTML support at all.

With such differing mobile browsers and platforms, a mobile web designer and developer should do more planning and approach site development with graceful degradation in mind. While mobile projects can and do vary greatly, I believe there are some basic project planning techniques that will help a project succeed, and in this post I will describe these techniques in general terms. Remember, the goal is to provide some basic mobile project planning steps, each of these steps will require refining specific to your organization and project.

Device Targeting

In his book, Mobile Design and Development, author and mobile design expert, Brian Fling, describes the concept of device planning. The idea is to identify which particular mobile handsets you want to target with your design and then identify each handset’s weaknesses.

“If you know the weakness of each of the devices you plan to support, along with what you will be able to safely accomplish, then you can have many successful mobile projects,” Fling wrote.

Sure, your client or company may want to reach “every” mobile Internet user, but certainly you will have some priorities.

For example, are you really targeting so-called emerging markets like Africa or India? If you are, you’ll need to consider the sorts of mobile devices that users in these regions favor. If not, you may not need to focus a significant portion of your design efforts on these devices. Likewise, if you are selling a downloadable product that only works on smartphones or on a specific mobile platform like Google Android, then you only need to aim for some mobile handsets, not all of them.

At its heart, device argeting is a business decision that should be made before developing a mobile-friendly ecommerce site.

Device Evaluation

With a list of target handsets assembled, you can categorize these devices based on what markup and programming languages they will support. Again using Fling as a reference, here is how he classifies mobile handsets for design purposes.

Table 1: The Mobile Device Matrix. Source Brian Fling, Mobile Design and Development

If you need to design for Class D mobile devices, you have a very different task than if your only targets are Class A phones.

Furthermore, some devices can and will support more than one mobile browser, so it is important to be familiar with some of the more popular mobile browsers. A list of some of these browsers follows. It is arranged in no particular order.

• Apple Safari
• Firefox for Mobile
• Minimo .2 from Mozilla
• Opera Mini 4.2
• BlackBerry Browser
• Palm
• Bolt Browser
• WinWAP Brower
• TeaShark Browser
• Obigo Q7 Browser
• Steel Browser
• Polaris Browser
• jB5 Mobile Browser
• Skyfire
• S60 Browser

Site Aim and Scope

After considering your target audience and the mobile devices that they are likely to be using, it is time to turn your attention to what your mobile site should offer. In a step analogous to other forms of site design, you should define site aim and scope.

Is your site a product catalog? Will it need to support demonstrations? What features are needed to meet your merchandising requirements? How will you accept payments?

Before you can really do a good job of designing a mobile Internet site, you need to understand what your site must accomplish. Put another way, you need to define your site project goals, and work out a design that helps your client or company achieve those goals.

WML, XHTML-MP, Or XHTML

Target devices selected and site goals in place, you will need to select a markup language. Fortunately, many modern mobile devices support XHTML, one of the most common markup languages and a markup language you have no doubt used when developing other sites. But depending on your target devices, you may need to support other, earlier markup languages or you may want to push the edge of mobile design and choose something like HTML 5.

-          HTML 5 — The fifth major revision of the Internet’s core language is a powerful update aimed at making web pages act more like applications. The recommendation is still not completely supported in desktop web browsers, and can only really be trusted at all in mobile devices running Firefox for Mobile, Opera, or Apple Safari.

-          XHTML —The extensible hypertext markup language is nearly ten-year-old web recommendation from the World Wide Web Consortium (W3C) that represents a reformulation of HTML 4 and XML 1.0. This markup language has been, perhaps, the most popular markup language for all web design for past several years. Class A, B, and C mobile devices support it, and Class A devices, which would include the iPhone, support it very well. For an even safer choice, use XHTML Basic, which is a subset XHTML that will almost certainly work on modern Internet-capable devices.

-          XHTML-MP — XHTML Mobile Profile (MP) is a modularization of XHTML Basic, which the Open Mobile Alliance, an industry association, named the preferred markup language for the wireless application protocol (WAP) 2.0 in 2002. According to Fling, if you can write XHTML, you can probably write XHTML-MP with little or no trouble.

-          WML — The wireless markup language (WML) is based on XML and was specifically developed for mobile devices running on WAP. Used mobile devices in some emerging markets, particularly those manufactured before 2001, may require a site to offer a WML version.

Basic Site Structure

In mobile website design, it is important to remember that not only is the platform different but the user is different too, or at least how the user acts is different. What’s more, whenever possible you want to build a single website that works across platforms, i.e.; mobile and desktop.

To achieve these ends, take a minimalist approach to XHTML site structure, and arrange the site in such a way that it would make sense to read it top to bottom. You can change the structure with CSS or JavaScript in the presentation or behavior layer, but in XHTML, you want simplicity.

Progressive Enhancement

This minimalistic structure is also a tenant of progressive enhancement. Progressive enhancement focuses on content, and generally encourages developing content first and gradually adding presentation and behavior layers to your content as you go. It has two important effects for mobile design.

First, by focusing on content, progressive enhancement helps the mobile design identify the site’s essentials.

Second, by adding presentation (CSS) and behavior (JavaScript or Flash) layers on after the content layer is developed, we also get a site that degrades gracefully. If we build content that is readable on a Class D mobile handset, adding CSS so that a Class A phone renders that content differently has no effect on the Class D user, but improves the experience for the Class A user.

Summing Up

In this article, I have tried to generally introduce you to the mobile site development process. Certainly, I have not provided an exhaustive list of everything that you will need to do, but I believe I have given you enough information to get your mobile project started properly.

This post was contributed by our guest columnist Armando Roggio. Armando is a journalist, web designer, technologist and the site director for Ecommerce Developer.

Aside from “doing nothing,” retailers have 2 options when considering mobile commerce: building an application (or “app”), or creating a website specifically for mobile devices. As Graham Charlton of Econsultancy has observed in the UK, some etailers are opting to bypass the mobile optimized website and go straight to a mobile app. This post continues the conversation and examines the differences of each and how you might choose between them.

Do Not Nothing

Smartphones are built for web browsing and users will generally be able to access your web site through a mobile browser even if you do not do anything. But this is not the optimal user experience, as pages designed for the web render very poorly on small screens:

Above left: Sephora.com website as viewed through mobile browser. Above right: Mobile optimized website at m.sephora.com viewed on mobile device.

While doing nothing is an option, any retailer who anticipates driving any sales through mobile devices needs either a mobile optimized version or a mobile application.

Mobile Applications

A mobile application is essentially software developed to run on mobile devices. Apps were popularized by the iPhone and Blackberry, but also may be developed for the Android, Windows Mobile and Symbian operating systems.

Mobile applications may serve as a mobile storefront, allowing in-app purchases. For example, the iPhone eBay app generated $400 million in revenue in 2009. It’s a tiny bit of eBay’s $59.7 billion in revenue but still impressive for an application people voluntarily install on their iPhones.

Pros & cons

Pro: User experience

The main advantage of building an app is the user experience. Most mobile browsers can’t handle JavaScript and Flash. A properly built app gives a developer control over the way text and images are displayed, as well as the use of sounds and videos. Apps can utilize the whole screen of the phone and remove other distractions from the shopper like address bars. There are also no compatibility issues when apps are dedicated to the device they were developed for. Screen size and features are consistent for all users.

Pro: Hardware features

GPS, camera and “shake” functionality can all be baked into apps. For example, a customer could add an item to cart by shaking her phone. For multichannel retailers with local stores, mobile applications can offer a GPS based store finder, or “augmented reality” where you can view a street through your iPhone’s camera and it will tell you the nearest gas station or fast food restaurant.

Pro: Loyalty

A customer who actively downloads and installs an app has a pretty good chance of using it. The app on the “desktop” is top-of-mind.

Pro: Off-line usage

Even when wi-fi or 3G is unavailable, a customer can browse your catalog or other application features which do not require Internet access.

Con: Development resources

Mobile apps take longer to develop than mobile websites. Not only because the look and feel of the app will usually have to be built from scratch, but also because you will need to create multiple apps to reach a wide audience. The iPhone currently dominates the app market, but with the large amount of other devices and app stores popping up, that will not last forever. Some think that Android-based mobile phones will surpass the iPhone in market share by 2012.

Con: Adoption and usage

Before a customer can experience your app, she has to download and install it. You will mainly reach your most loyal customers who are fairly invested in your brand. Just as with PCs, most people think twice before they install an app on their phone.

Con: Nascent market

Despite all the press coverage, the app market in total is not that big. Only 13.3% of the phones sold in Q3 of 2009 were smartphones, and of those only 17.1% were iPhones. With Apple controlling the app market for now, that’s a very small number of potential customers.

Mobile Optimized Website

As mentioned earlier here on Get Elastic, there are many ways to build a mobile optimized site which each have their own pros and cons.

Pro: Less required resources

Mobile sites will most likely be quicker to implement compared to building an app with a unique look and feel. Note that due to the wide variety of handsets available, you may have to optimize your website for more than one phone and/or screen size. In most cases, depending on your ecommerce platform, you should be able to reuse large parts of your existing infrastructure and focus on changing the website’s look and feel so that it fits a smaller screen.

If that’s not fast enough for you there are services like Usablenet and Mobile Aware that will take your existing ecommerce site and build a mobile optimized version in a few weeks without you having to lift a finger.

Pro: Accessible to all

If a user is not heavily invested in your brand chances are slim that they are willing to download an app just to be able to find the nearest store or buy the thing they’ve just seen an ad for. But a mobile site is accessible on any device with a mobile browser, including non-smartphones, as most of these have some form of WAP-browsing. Though WAP is fast becoming a long forgotten technology it’s still worth considering depending on the customers you’re trying to reach.

Con: Limited functionality

Even though all smartphones have browsers, most of them are very simplistic and cannot handle the same complexity and dynamic behavior as browsers on a PC. Flash is especially an issue, as hardly any of the smartphone browsers support it. Even some JavaScript that should be simple can be problematic.

Being confined to working with what the phone browser can handle means you cannot use any of the phone’s other features such as GPS for a location-based store locator. It also means the customer must have network coverage to continue to use your website. If the connection drops for any reason you could potentially lose a sale. As mentioned previously, building an app would help you avoid these restrictions as an app has better access to other features the phone offers, as well as being able to store information locally until the phone regains network access.

Con: Customer satisfaction

A mobile optimized site may not have the same appeal for a loyal customer who might expect a greater interaction or immersion on your brand.

How do you choose?

It should be clear now that neither solution alone is perfect for reaching all your customers, and if resources were not an issue the optimal solution would be to do both. So the question really becomes “If I can’t have both, how do I choose?”

The short answer is (as always): It depends on your target audience.

Apps are great when you have a segment of loyal customers who interact with you on a regular basis and want a fuller experience on their mobile. You can provide special news, content, offers etc. to these customers, leveraging the hardware of a device such as GPS, camera and “shake.” (Hint: Survey your customers through email, on-site surveys or social media like Facebook or Twitter).

In some cases, your customers are already screaming for a mobile app and are making their voices heard in online communities like the Sephora Facebook page:

Unless there is sufficient customer demand, an optimized mobile website is your best bet. It requires less commitment from a potential customer and allows access to all.

Besides considering your target audience, it’s also vital to consider the impact on your brand and how your mobile strategy in general fits with the rest of your offerings. You can still offer special content, products, offers to a select group of customers in other ways like SMS/text messages, email newsletter, physical newsletter, personal promotion codes, etc.

Dennis Newel is a business analyst and ecommerce consultant at Elastic Path Software.

Don’t forget:This month we are presenting a webinar on application stores: App store – a new way to sell software, media, and anything digital where we will discuss the app store as an ecommerce platform and its business models.

This week’s video is on mobile websites vs. mobile applications and features Elastic Path’s Peter Sheldon.

RSS and email subscribers, can’t see video? View this post on the web.

Video Transcript:

Mobile commerce is growing.

In fact in the US next year, it’s expected that 1% of all transactions will occur from a mobile phone. So many retailers are looking at growing their mobile commerce strategies and are not sure whether they should build a mobile optimized website or whether in fact they should build dedicated apps for the different devices like iPhone and Blackberry and Android.

There are pros and cons to both.

On the mobile website side, it is guaranteed that they can be used across all different phones. Any phone with a browser can view a mobile optimized website. But even then, some retailers are finding they need to build two versions of their mobile optimized website: one for the high end devices, and one lower fidelity version for the lower end devices. This creates a lot of constraints on your development capabilities, and the experience differs depending on what device one’s using.

On the other side, mobile apps like iPhone apps, Blackberry apps and Android apps have to be created for each of the different devices, but they’re dedicated for each device. They’re guaranteed to work and they can leverage some of the rich hardware features of the phone like the GPS, the camera and the maps.

So think carefully whether a mobile app or a mobile optimized website is right for you. Know what your customers are using or what devices they own. If all your customers are business users and are all using Blackberries, then think seriously about building a dedicated Blackberry rather than just a mobile optimized website.

On Monday we will follow up this topic with a more detailed post from Dennis Newel, Business Analyst at Elastic Path, Mobile Commerce: App, Mobile Site or Both?

And on Tuesday, March 30 we will be presenting a live webinar with Elastic Path’s CTO Michael Vax discussing the ins and outs of application stores: App store – a new way to sell software, media, and anything digital.

As I was wandering through the exhibition halls, it became apparent how popular the concept of the Application Store is.

The main goal of an App Store is to increase the attractiveness of a hardware or software platform to end users by engaging third party developers to increase platform capabilities.

Most of the current App Stores have been created either by a hardware manufacturer (Apple, Intel, Samsung, LG) or a wireless network operator (Orange, Verizon Wireless, China Mobile).

The Wireless Industry Partnership Connector Inc. (WIP) keeps track of App Stores for mobile developers and has listed 49 of them already on its web site.

However, App Stores are not limited to mobile devices. For example, Intel has created an application store for NetBooks which run on an Atom processor. According to Intel’s product manager Lucas Massuh, Intel sees the store as the main way to distribute software for NetBooks as they don’t contain a DVD drive. To make it very easy for a user to move applications from one device to another, the App Store keeps track of purchased applications and authorizes them on user devices.

Intel is planning to extend the App Store to its partners (netbooks manufacturers) and run white-labelled stores for companies like Acer. However, it looks like Acer already has plans of its own and will be offering downloadable software and e-book readers by mid-year.

Samsung has created a store for what it calls multi-device applications – programs that work on a variety of devices ranging from phones to netbooks, TVs to e-book readers. Samsung is encouraging developers to create applications that can utilize multiple devices. For example, using a phone as a remote control for a TV.

Pure software companies that want to attract developers to their platform are also joining the suite. Salesforce has created a store for applications that runs on the Salesforce cloud.

As the number of applications balloons, more specialized App Stores are appearing that cater to a specific market segment or to specific user needs. While most of the stores are targeting consumers, there are a number of new stores that focus on business and enterprise markets.

For example, MobileIron provides each corporate customer with its own customised Enterprise App Store, transforming the delivery model of enterprise applications from ‘push’ to ‘publish’.

The corporate IT department publishes approved internal and external applications, noting whether they are supported and/or reimbursed, and defining access based on the user role or IT policy.

Employees then browse their Enterprise App Store through the MyPhone@Work portal and select the applications best suited for them.

A similar model is used by AppCentral which brings together the efficiency of a self-service App Store with the power of IT controls.

Applications of Application Stores

Application Stores create an opportunity for a new business model when it comes to selling software and its components. Let’s say Developer A has a great idea for a new game. To get his super game to the market fast, he wants to use an existing game engine created by Developer B. Currently, the only way for a game developer to distribute his or her game with a 3rd party game engine is to license it upfront.

Intel plans to start a developer-to-developer application store with an innovative revenue sharing model. When Developer A’s game is sold, Intel will give Developer B an agreed upon percentage of the revenue. There is no risk for Developer A as he is not paying the licensing fee upfront and the application store takes care of all hassles associated with revenue sharing and payments.

Another ecommerce opportunity is “in-app” sales. In-app ecommerce refers to an application that sells additional content or services from inside the application. For example, a developer can release a free version of a game and allow users to upgrade to the paid version from inside the application, or buy additional virtual goods which can be used in the game.

Another example is an application that sells content. In Barcelona, I visited the booth of a Japanese company that sells Japanese Namga (Comic Books) on a variety of cell phones. The user installs the application on a mobile phone and uses it to purchase new comics which are immediately downloaded to the mobile device. e-book stores use the same approach.

The Application Store as a Marketplace

In essence, an App Store is a Marketplace for selling applications or content produced by a number of vendors.

There are substantial differences between an App Store and a regular ecommerce system.

A standard ecommerce system provides interfaces to two different types of users – shoppers and store operators. Application Stores have a third category of users – vendors. This means that an Application Store’s system needs to support interfaces for creating and managing vendors’ accounts as well as give the vendors their own interface to manage their products, prices, and generate reports.

The vendor interface needs to be simple and straightforward, as developers want to spend their time writing software or creating content instead of operating an ecommerce site. For example, Samsung, who plans to operate its App Store in 50 countries, makes it very simple for developers to set up product prices across multiple stores and currencies. A developer only needs to select a pricing tier for his or her application and this automatically determines prices in all currencies across all Samsung stores.

There is also an essential difference in managing shoppers’ accounts. In the Application Store, order history means “what the user owns” instead of “what the user has purchased”. Thus, the store should allow a user to reinstall applications on a new computer or phone as well as make sure that the user has access to application upgrades.

Another interesting distinction from a standard ecommerce system is that most App Stores don’t have a web storefront. Like iTunes, the App Store has two types of applications: a store application for PCs, and another for mobile devices.

Some App Stores do have a web storefront that customers can use to look for an application. When a shopper finds the application he or she wants to buy, they are asked to enter either an email address or a phone number, and a link to complete the purchase is sent to their phones via an email or SMS message.

As we discussed above, the main goal of an Application Store is to attract developers, and the main goal of developers is to maximize revenue by selling more applications. Most of the current Application Stores are built internally by companies that operate them, and do not have advanced ecommerce features that have become common in modern ecommerce platforms.

Functionally, most App Stores are very similar to iTunes. The selling process is based on a simple product search, category browsing, and user ratings. This works well for the small number of applications which have made it to the top of the charts. The rest of the vendors bring in less than optimal revenue from their less popular applications.

The Future of App Stores

I believe that a second generation of App Store systems will arrive soon from established ecommerce vendors which will adopt more sophisticated ecommerce techniques like bundling, SEO, cross-sell/up-sell, promotions, and tier pricing to increase revenues for store operators and developers.

Please join me on March 30th for this month’s webinar App Store – a new way to sell software, media, and anything digital where we will further explore this new fast growing trend in ecommerce.

Testing the Product List Page

The image below is the control version:

We looked at our previous tests and after several hypotheses and investigations we produced two alternative variations with following changes:

A) Introduced a vertical menu that shows all subcategories for easier access to other products
B) Provided color thumbnails to products that have alternative colors
C) With help of recommendation engine (cross-sell), showed most popular products from that specific category to increase revenue from top selling items
D) Introduced a minor face-lift to filtered navigation to improve usability

Treatment A:

Treatment B:

What We Learned

During the experiment all variations were equally distributed to 100% of all traffic. This was another tough experiment where even 2272 transactions and 10 days did not provide a statistically significant winner. But we gathered just enough visitor and ecommerce data for a decision to be made. Variation A was chosen based on following data in comparison to the control variation:

• According to Google Website Optimizer (GWO) Variation A converted better by 7.74%
• Overall site Conversion Rate increased by 22.18%
• Average Order Value increased by 7.06%
• During this period of test, unfortunately the bounce rate for Variation A was 19.45% higher than for the Control

What Surprised Us: Control vs. Control

Additionally, we wanted to do a little test on GWO itself. We created another variation which was an exact copy of the Control variation. Maybe it was a “statistical coincidence,” but this alternative “exact” variation performed 4.97% better! We didn’t do this for any other tests, and, thus, can’t confirm if there is a pattern for such behavior. So this is up for discussion. Have you tried a similar A/A test and found similar results?

This post is contributed by Janis Lanka (@janislanka, who manages front-end development for Elastic Path Software.