Enter a search term such as “mobile analytics” or browse our content using the filters above.
That’s not only a poor Scrabble score but we also couldn’t find any results matching
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
The observant among you will have realised that we launched a new website last weekend. I thought it would be a good idea to interview Econsultancy CEO Ashley Friedlein to explain more about the challenges of managing a ground-up rebuild.1. What were the key reasons for building a brand new platform?
Our old site was starting to creak with age. It was increasingly held together with bits of digital tape to keep it going. It had grown organically since 1999 so was based on a mish-mash of old and new technologies and the data, especially the user and metadata, was inconsistent.
As we had grown the business over the years things had been tacked on. It had come to a point where we really needed to step back, completely review what we needed, and rebuild everything from scratch. You know there comes a time when, however much you love your old car, it just isn't economical or sensible to keep fixing it.
Given we talk about best practice in digital marketing and ecommerce we're keen to try and practice what we preach as far as possible. Again, the old infrastructure and platform just wasn't capable of going where we want to go. Things like APIs, Unicode support, personalised RSS... all of these were pretty much impossible on the old platform.
Also the new site genuinely is much more of a 'platform' than a website. In theory we could re-sell it as a platform to others, though we're not planning to go down that route.
What we definitely are doing is providing completely customised versions of the site to customers. For example, for our training customers, we can provide private forums, blogs, content that only they can see. They can add their own content to share, then we can customise how it looks and works, and will automatically track learning outcomes and continuing professional development points online etc.
2. How long did you expect it would take to complete? How long did it actually take, start to finish?
You're asking a man who has written two books on Web Project Management? ;)
The truth is we had no real idea of how long it would take. We guessed about a year. In the end it was more like a year and a half. And, of course, there are loads of things on our 'to do' list now that we'd hoped we would have for launch but haven't.
I'm formulating a new law which says that all major web projects are at least three months late, and usually more like six months late! I talk to plenty of site owners whose projects were a year late.
I'm a great fan of Agile approaches for web development. And I think working in small, highly skilled, teams works best.
However, on our own project, we followed what I optimistically call 'Agile Lite'. Which is like Agile except without any discipline or procedures at all! When you are your own client, and the team is small, then you can be very flexible which has obvious advantages, but also disadvantages in the lack of discipline you apply.
3. What resources did you allocate to the project? The core team was really just me and our three internal developers. Obviously there was a lot of input from everyone across the company and we used external contractors and agencies for specific advice and work. The design and branding, for example, wasn't done in-house.
If you total the in-house costs, in terms of salaries, and the external costs then it will have cost us around £300,000 so is a significant investment financially and in terms of time.
4. What were the primary areas of focus? What were the key things to get right?
At our recent Online Marketing Masterclasses event, one of the speakers talked about 'beautiful basics', while another spent half an hour talking just about best practice form design.
I think 'beautiful basics' is a great phrase, particularly given the state of the economy. Much as we like to get excited about whizzy stuff, the reality is that it is the basics that really matter; and the basics are surprisingly hard to do. And to do them 'beautifully' is that much harder still.
Show me a truly experientially beautiful web form and I'll show you a bunch of unusually talented people and about a month's worth of work!
Take something as seemingly innocuous as a URL - surely a simple 'basic' you can't get that wrong? Not so. I could bore you for quite a while on the importance of beautiful URLs and how important they are (alternatively, check out http://blog.welldesignedurls.org/). We must have spent, collectively, about a month's worth of time thinking very hard about URLs. Not least because of their importance for search engine optimisation (SEO) in migrating from our old site to new.
Other 'basics' are things like information architecture, navigation, styles (e.g. links), site search, forms, email, validation errors and messaging.
These are all easy to do badly, easy to do in a mediocre way, but hard to do well, and truly hard to do beautifully.
But, even more important for me, though almost invisible to a site user, is the data, and metadata, and meta-metadata, that underpins the whole thing. The longer I spend in digital marketing the more I realise that it's about the data, stupid.
With good data - what I like to call 'smart' data - which has embedded in it the very DNA of your business and your customers, there's almost nothing you can't do. Take smart data, add in web services, and you can really have some fun.
And if that sounds techie then I'm afraid you'll never make a great digital marketer. It always frustrates me talking to 'marketers' who bang on about personalisation and segmentation but run scared of 'metadata' because that's supposedly something for the techies.
We were thinking about our data taxonomy for about six months before we began to build anything. It's tragic really but I remember waking up in the night with the odd 'Eureka' moment relating to metadata.
For example, we have metadata around what we call 'georelevance' i.e. is a piece of content *only* relevant to a particular country, or is it *mostly* relevant to one country but *also* relevant globally. Likewise we have metadata around 'expertise level' i.e. is this data for beginners, or expert practitioners?
This kind of data allows us then to slice and dice our content in new and useful ways. So if you want a customisable widget about affiliate marketing that's pitched at beginner-intermediate practitioners relevant to the US only... well, now we can do it.
5. How will you measure the effects of the new site? What KPIs do you rely on?
We've just starting using Google Analytics on the new site and it is integrated with AdWords which we use too. We have a three page document which outlines all the various KPIs we track so a little much to replicate here.
However, broadly speaking we think more like a retailer than a publisher in terms of our metrics. So key ones are around sales, conversion rates, average order value, CPA by marketing channel etc. Unlike a retailer, though, we have no physical stock, no warehouse, nothing that perishes (though events are fixed in time, and content ages), our margins are close to 100% and fraud is pretty much a non-issue. So really we've got it easy!
Historically we have been guilty of the same thing that many of us involved in web analytics suffer from i.e. plenty of reporting but too little analysis and too little actually done with the analysis. So we're very keen to move as quickly as possible towards as much 'optimisation' as possible rather than reams of reporting. So multi-variate testing and incremental optimisation is very much on the cards.
6. Is the new site converting better than the old one?
This is a slightly atypical (quiet) time of year for us as we're B2B and most of our customers right now are busy with reviews, office parties and the like.
However, after only a few days of being live our conversion rate from new visitor to member has almost doubled. Most of these are at our new free level of membership so the challenge over time will be to convince these people to pay for something!
7. How much of a challenge was it to preserve the data / business rules?
My psychiatrist has advised me not to think too much about this... ;)
It is a huge challenge. Massive. Keep in mind that we have more than 100,000 pages of content; there are at least 80,000 user profiles; we have not just one-off payments but all sorts of recurring payments across numerous different services; in three different currencies; globally.
8. Why did you choose Ruby on Rails to underpin the new Econsultancy site?
I didn't really. It was Tom's recommendation - our Head of Website Development. To a large degree I had to trust what he was recommending. I figured that if he was going to have to build and maintain the site then it was best to go with what he wanted. That's why we hired him - to be right about these things! Time will tell.
From a commercial perspective there are some obvious advantages to Ruby on Rails:- It's free / open source- It's 'cool' among developers so it's much easier to attract and hire good people.
My only concern was a 'word on the street' that Ruby "didn't scale too well". Twitter (built in Ruby on Rails) famously fell over a while back. But we're certainly not Twitter.
Our complexity doesn't come from huge user volumes but on the complexity of what the application has to do - a mixture of content management, user profile management, commerce etc.
9. Are you concerned about your natural search rankings given you've got a new site and new URL?
Not just a new URL and new site, with a new directory structure, but it's now hosted in the US so on a completely new IP address too.
On the old site around 90% of the new visitors to our site (around 5,000 unique users a day) came from natural search engines, and almost exclusively Google. We have spent years building our reputation and working on our SEO. Along with email, SEO is by far the most important form of marketing for us.
So, am I worried? Are the shareholders worried? Just a little.
It hasn't helped that all the SEO gurus we talked to, and we do know most of them, looked aghast and sucked their breath quickly through their teeth when we told them what we were planning - "I wouldn't do that if I were you...".
Our SEO migration strategy really boils down to only one thing - getting the 301 redirects right. And we've moved our Google Webmaster verification code from the old site to the new. Our thinking is that Google should know we've moved the site and that what was the old site is now the new one. And our credibility should thus also transfer.
It's too early to tell for sure but we're currently seeing Google index the new site whilst showing dual listings in the search results for both the old site and the new. So actually, at the moment, we're getting *double* the page real estate in many cases. I'm hoping that this is part of Google incrementally switching over from old to new and that we'll see the old listings disappear in the coming weeks.
It will be interesting to see whether our US search referrals go up as a result of the site being hosted in the US now rather than the UK. But I think our rankings these days are largely governed by the inbound links we get, and these are based largely on the nature of the content we publish.
10. What can we expect to see happening next? Any big plans for 2009?
Lots. We're opening an office in New York so will be doing a lot more in the USA next year. Given the US economy is in such a good way, it seemed like the right time ;)
Other things high on the agenda as far as the platform is concerned include:- Elearning (we've looked at commercial options out there but don't think they're any good so are going to build our own)
- Online benchmarking applications (for our members to share benchmarking and KPI type data).
- Online tracking of Continuing Professional Development so that you can gain CPD points just by interacting with our site e.g. contributing our Forum etc.
- More granular internationalisation / localisation
- Mobile, DRM, widgets, APIs, personalised RSS...
Watch this space!