I came across a great video on a relatively new start-up in the UK called Shutl that runs an innovative service for retailers to speed up their e-commerce delivery service. And when I say speed up I really mean it as well, the average delivery time is 75 minutes from the time an order is placed and is currently used by Argos, Maplin, Coast and Warehouse. It takes same day delivery to a new level.

Intrigued?

Watch the video for more insights; you can then skip to the end of the blog post where I looked in brief at the broader e-commerce delivery service landscape.

<Video Summary Start>
Presented by Tom Allason, Founder and CEO of Shutl, the video has some compelling stats and arguments as to the value of the Shutl service, although I’m not aware of the sources of the data, it does make perfect sense.

Beyond the product and price, delivery is the single biggest influence in determining whether or not a consumer buys from you and continues to buy more or less from you in the future. It also represents the last interaction with customer, so you want to leave a lasting impact.

Key stats:

Failed delivery attempts or complete delivery failure, the cost of which is often picked up by the retailer, cost businesses £1billion (probably in the UK) last year

Two thirds of consumers who abandon their purchase cite delivery as reason

90% of online shoppers list delivery as top pain point

On average each year every consumer loses £177.111 in lost time and wages waiting for a delivery

61% of online comments about home delivery are negative

Traditional delivery routes are managed through what is called hub and spoke collections. This method of delivery is the only cost effective solution for deliveries above 10 miles. However, less than 10 miles it can often be comparable or even more cost effective to deliver something point to point and essentially deliver straight from A to B.

In the UK big courier companies don’t do point to point delivery. Only 3% of courier companies provide this service. This is where Shutl comes in – it works as an aggregator for pulling these fragmented courier companies together to make a point to point delivery service a viable and affordable solution of retailers and consumers. Tom Allason asks you to think of it “as a kind of PayPal for really awesome delivery” where the delivery promise is 90 minutes and the average delivery time is 70 minutes (on March 7th it was 75 minutes as taken from the Shutl website) for immediate deliveries.

You can also select the exact time you want your purchase(s) to be delivered – 24 hours a day, 7 days a week. As the cost is comparable to traditional hub and spoke delivery methods this can often be free to the consumer.

Quality Service
Customer service and quality is of the up most importance as providing a bad service means that customers won’t use Shutl elsewhere and the lifetime value of consumer is critical to Shutl’s success. So the company does two things.

It tracks every order and measures the performance of each courier company against delivery SLAs that are set. Each company is given a rating that is affected by the success or failure to delivery on time that in turn impacts the amount of business the courier company will get as part of the aggregator service Shutl provide. The start-up cleverly incentivises fast delivery that in turn boosts the Shutl brand with consumers.

Shutl request customer feedback after every order that is shared whether it’s good or bad on the company’s website.

Incredibly 26% of shoppers provide feedback completing the full survey.
Furthermore, 81% of respondents rate the service as a 9 or 10 out of ten in terms of their likelihood to recommend. The video concludes that delivery has always been a reason not to buy online, the aim of Shutl is to make customers more likely to buy from a retailer that supports the Shutl delivery service. From the feedback data over 70% of Shutl users are either more likely or way more likely to retailer again.

This was a great slide in the presentation. Shutl showing measurable return on investment.

</Video Summary End>

I personally used the service in December when I ordered a Christmas present from Argos. After purchase I was able to request immediate delivery via Shutl and due to my order size it was completely free. I was called to say that due to demand there were a few delays and was given a revised delivery time, but from memory I believe it was still delivered in less than three hours. I was impressed!

Of course there are limitations to the service; proximity is critical so coverage is going to be limited. And for smaller, cheaper items like CDs you’re probably still more likely to hunt out the free delivery option as the Shutl option would be more like a Special Delivery cost. But excluding these considerations it really does start to alleviate a major frustration in the e-commerce buying process that I hope will make others stand up and take notice.

Other examples of this type of customer service are limited, but they do exist. Florist brokers such as Interflora offer same day delivery on flowers by aggregating smaller, often independent florists across the UK. Some companies in London have also been able to provide same day delivery, albeit at an exorbitant cost.

Amazon UK provides a same day evening delivery service at £14.99 for certain large cities. However, I feel like this is only paying lip service to the idea. Amazon has been more focused on its delivery loyalty scheme Amazon Prime that for £49.99 allows free and unlimited one day delivery for a year. An interesting concept and I’ve heard that Amazon Prime has been very successful.

When a page moves it is recommended to use a 301 redirect from the old to new page to tell search engines to index the new result. This will also tell search engines to remove the old page from their index and pass any search value to the new URL (although this may not be all the old search value).

This post outlines what Google and Bing thinks about chained redirects. In some cases they can’t be avoided – so I’ve taken a look at what you should you do in this instance. Read Google’s moving your site Webmaster Tools Help guide for more general information.

For those with little time here is the takeaway from the post:

Remember that ideally you shouldn’t have any stacked redirects or even a single redirect if you can help it, but if required Google will follow chained redirects

But every additional redirect will make it more likely that Google won’t follow the redirects and pass PageRank

For Google keep it to two and at a maximum three redirects if you have to

Bing may not support chained redirects at all

Read on for more info.

What is a 301 redirect?
Like it’s cousin the 302 redirect, a 301 redirect is a 3xx redirect status code used to indicate that a page at a specific URL has moved. The image below courtesy of Elliance does a good job of explaining this further.

How many redirects I can chain together?
I’ve deeplinked into one of Matt Cutt’s Google Webmaster Central guides to the part where he discusses this exact question.

The key points were as follows:

Best practice for 301 redirects is to only have one redirect (one hop)

But Google does follow chained redirects (if absolutely necessary)

That said, at some point Google will “get dizzy” and stop following the directs. The odds are close to zero that Google will follow four, five or more chained redirects

Recommendation if you have to use chain redirects is have two redirects, maximum three

What about Bing?
Unfortunately it appears that Bing is not quite so fond of chained redirects. Below is a recent quote I found.

As a closing thought, be sure not to stack redirects. Doing so almost ensures we won’t pass the value through to the end.

Obviously this is not ideal, but I guess this doesn’t change the recommendation because I’m not saying chained redirects should be used, it’s only when you are forced to by a system such as a CMS that there isn’t an alternative.

Why would you have to have chained or multiple 301 redirects to get to a page?
Good question. Websites, blogs, content management systems etc. can be complicated. Sometimes it’s impossible to avoid chain redirects, for example what happens if you create a short URL for a page and that page subsequently changes. It’s not always possible to change the short URL redirect to the new URL, equalling a chained 301 redirect.

This is just another reason why the number 1 rule of good URL design is to not change a URL once it is created. But unfortunately as in life we have to be prepared for the unexpected.

301 redirects and site speed
It’s also worth noting that minimizing redirects can improve page speed. Every additional redirect adds additional waiting time for users so webmasters should always only use a chained 301 redirect when absolutely necessary (and still only two or maximum three). The same is true for a single 301 redirect, avoid them whenever you can and avoid causing them too. For example always use the correct URL when linking internally and not a redirecting URL.

In SummaryDon’t use stacked 301 redirects unless there is no other choice. When you have to work with whoever you have to work with to ensure that it’s only two and an absolute maximum of three chained redirects.

What do you think?

Have you run into problems with 301 redirects?

Does any one have any additional insight into how Bing handles multiple 301 redirects?

From my research international SEO is still struggling with the question of how to localise the URL after the domain name. This post reviews this subject in some detail, but if you would like the executive summary here are my recommendations.

Don’t forget the basics of best practice URL design.

Always localise a URL for non-English pages when the suggested localised URL does not have any special characters in them.

Do not use special characters in landing pages that display next to the root of the domain name e.g. www.mybrand.com/page or at least provide a marketing URL that is used that does not include special characters.

For all other URL structures I’d like to see more evidence as to the pros and cons, but I believe that they should be fully localised with UTF-8 encoding to ensure backwards compatibility.

To give these recommendations some context lets start with one of the golden rules of best practice URL optimisation – make sure that the structure of your URL describes the content of your page.

This has two benefits.

Most importantly it is helpful to a user, they can establish what a page is about without having seen the content of that page. For example when a link is emailed or shared its very often the URL that is seen first. Keyword context in good URL structures is a fundamental component of increasing the click through rates on a URL.

How do you include URLs that describe the content of a page when a language includes or is made up entirely of special characters when traditional convention dictates that best practice dictates that URLs only be made up of ASCII characters (a-z, A-Z, 0-9, -, ., _)?

So herein lies the dilemma with URL structures – do you localise the URL or not? Is a localised URL better for SEO, usability and crucially for a websites users? Will a localised URL break old browsers or my website? What are the technical issues with special characters in URLs?

How are special characters included in URLs?
Regardless of whether its right or wrong for a good localised URL design special characters are technically implemented in URLs through the use of percent encoding, also know as URL encoding.

Example of percent encoding: B3%D0%B5%D0%BD%D0%B8%D0%

Currently the UTF-8 format is used as the specification for encoding of any special characters that traditionally were not supported in a URL.

What are the SEO best practices for localised URL designs if I don’t want to or can’t include special characters in the URLs of my website?
Before we get into the debate, if you do fall on the side of the argument that does not advocate the use of special characters in URLs or more simply your blog, CMS or website does not support them then its still important to follow SEO best practice for localised URL structures.

You should continue to follow the mantras of good URL designs, just like you do for English URLs. They should be descriptive and focused on the content of the page. This means that:

1. For languages that use the Roman Alphabet such as French and Spanish translate the URL into those languages.

www.mybrand.com/shoes

www.mybrand.com/chaussures (French)

www.mybrand.com/zapatos (Spanish)

A translated, keyword rich URL will have much more impact when localised. Who in France or Spain would search for shoes when looking for shoes in their language?

2. Often these URLs do not get localised or websites that have multiple locales that stem from an English locale. There is an argument that the extra work in localising the URL outweighs the benefit, but I disagree on this point and any process that removes the need to include an English word on a non-English site should be encouraged. When there are special characters in a Roman alphabet it has become common practice to replace them with the its nearest equivalent so an é with an acute accent would simply become an e. Its important to remember that these changes can significantly impact the meaning of a word, but due to the initial limitations in URL standards this does work. Indeed search engines will often, but not in all circumstances return the same results for a term with or without the special character.

3. For URLs in non-Roman alphabet languages such as Russian, Chinese and Japanese the default has been to just use English. As most URLs for web pages in these languages continue to not be localised you won’t be at too much of a disadvantage. One option might be to localise the URLs using languages like Pinyin or Romaji the phonetic equivalent of Chinese and Japanese languages, but I’ve not seen any evidence to suggest that this works.

Even though the above if implemented will make a big difference for maximising the benefits of a good URL in international SEO the impact on non-Roman alphabet languages is still limited. There are many arguments against full special character URL localisation I will try and tackle them one by one.

Do search engines even understand encoded special characters?
From an initial research yes they do, or at least some do. I found this note from Google on Google Groups.

Yes, we can generally keep up with UTF-8 encoded URLs and we’ll generally show them to users in our search results (but link to your server with the URLs properly escaped). I would recommend that you also use escaped URLs in your links, to make sure that your site is compatible with older browsers that don’t understand straight UTF-8 URLs.

Would you really expect many users to remember and type this in, even if it was made entirely of words? They are going to search for it, not go direct.

Even if the keyboard input was a concern most users who want to type in these type of URLs are either likely to have a localised keyboard that supports the characters or use keyboard shortcuts to get what they want.

For these type of URLs that are at the root of the domain I feel the best approach is to use URLs that don’t use special characters or at the very least provide a vanity URL without special characters in marketing communications that redirects to the page URL via a 301 redirect.

How is there benefit to the user if the URL is displayed with percent encoding in the address bar?

Modern browsers support UTF-8 character encoding. The only ones I have on my list, beyond the most archaic browsers, are IE6 and Firefox 2.0. These browsers return percent encoding instead. When testing this yourself you might find that a browser such as IE8 is not showing the encoded URL, but this is often because you don’t have the relevant language support installed against that browser.

For the users that matter, except for those using old browsers such as IE6 (which to be fair is still has high usage in countries like China), they will see the localised URL encoded in their language.

So overall, much better for the user, and as we have seen better for search engines.

UPDATE: I’ve been looking at this further and I’m only getting consistent results in Chrome. I’m going to investigate this further.

Won’t an encoded URL create errors when sharing or bookmarking an encoded page?
I’ve read that it might, but on the social sites I’ve tested there were no issues, see screenshots below.

Link takes you to http://www.dmoz.org/World/Japanese/%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%97/%E3%82%AA%E3%83%BC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3/ without an issue.

Will special characters break my website in IE6?

I’ve seen this mentioned on some forums, but I can’t find conclusive evidence to suggest that it will. I’d expect IE6 and your website in general to break if you don’t probably encode the URLs, but if you use the applicable percent encoding for special characters the site should work without issues.

This said I’d love to hear if anyone has found issues even with special characters in IE6 or elsewhere when fully localising URLs for all languages.

Any other comments?

Has anyone seen significant search benefits using special characters in URLs?

Is there a URL localisation browser support cheat sheet out there to help us SEOers understand if users will see encoded URLs or percent encoding?

Does anyone have any additional concerns or insights when localising URLs for non-English web pages?

The problem with subscribing to a blog RSS feed is that you then need to have some downtime to connect and absorb. Other people may have a system worked out, but I’ve never found a way to make accessing and reading my RSS feed as second nature as checking my email or Facebook. However, finding something to do on my daily commute led me to a solution that I wanted to share – mobile RSS, and specifically a fantastic iPhone application of the same name.

Living in London, I take the dreaded Northern Line to work, which is generally a very hot and uncomfortable experience. As the outside world is unreachable when you are on the tube you are forced to find alternative modes of entertainment. I’ve found using MobileRSS on my iPhone an excellent way to pass the time and also read up on latest industry news. That is when I can keep away from my Civilization Revolution iPhone app! GEEK ALERT.

MobileRSS takes your Google Reader subscriptions and displays them all within the iPhone app, ready to be read. There is a free and paid for, Pro version of MobileRSS, the former displays adverts, but they don’t get in the way of the experience in my opinion.

Here are a few screenshots of the app.

So what makes this app so useful?

1. Offline reading, when connected to 3G or WiFi the app downloads all your subscriptions
2. Auto syncing with Google Reader on the web. If you add a new feed on the web, you’ll see this updated within the app.
3. Easy sharing of blog posts via email, Twitter, Facebook and Delicious, amongst other options.
4. It’s usable – a great, easy to use iPhone app, MobileRSS does exactly what it says on the tin.

Now I’ve got a tool for reading my blog subscriptions, the next step is making sure I action what I read. To paraphrase Tony Robbins, “Information isn’t power, it’s potential power”. Perhaps I’ll save that for another blog post.

Has anyone else used MobileRSS on the iPhone? What do you think?
Do you use a different iPhone or Android app for reading your RSS feeds?

To coincide with World Aids Day on December 1st 2009 AKQA were asked to promote the start of (NIKE)RED partnership global launch of the (NIKE)RED shoes laces.

As Account/ Project Manager I led the Creative and Development Teams to deliver a campaign feature on NikeFootball.com, a Gamechangers section to promote Nike’s involvement with football based charities and a (NIKE)RED widget that could be installed on consumers Facebook pages and blogs.