« December 2007 | Main | February 2008 »

January 24, 2008

Accenture buys Memetrics and Maxamine

image More news from the big-dog-eat-small-dog world of online marketing & optimization: Accenture (specifically, its Online Marketing Sciences group) announced yesterday that it's to buy both Memetrics and Maxamine. The Memetrics deal has already closed; the Maxamine deal will likely close within 30 days.

I know the guys at Memetrics and Maxamine pretty well - they're both great little companies and this is a great result (coincidentally, both hail from Australia). Memetrics has been playing in the Enterprise MVT space for several years, with some significant successes at large clients like Amex, whilst Maxamine provides testing & validation services for sites, in particular, checking whether a site's instrumentation tags (e.g. for web analytics, or ad serving) are correctly deployed. Maxamine has been an Omniture partner for years - I wouldn't have been surprised to see them swallowed up by the Omnivore, in fact.

The acquisitions tell us that Accenture is serious about helping companies bridge the gap between their marketing management (media buying, campaign management) and their site management & optimization. Few agencies have the nous or client relationship depth to do this - media/creative agencies tend to focus on the media side, whilst web agencies stick with the site. As a result there are still millions and millions of dollars falling down the cracks between brilliantly executed campaigns and brilliantly executed (but totally unconnected) sites. It'll be interesting to see how Accenture fares.

del.icio.usdel.icio.us diggDigg RedditReddit StumbleUponStumbleUpon

January 22, 2008

Tags vs Logs: The big fight

sp3There are many in the web analytics industry who could say (with some justification) that the tussle over whether to use client-side JavaScript tags or web server logs as your source of web analytics data has already been settled, with tags being declared the winner by a knockout. Certainly with Gatineau we've decided to place ourselves firmly in the tags corner (if you want to provide a hosted web analytics solution, and collect the data centrally, you really don't have any other option).

But logs aren't beat yet. Many vendors - Google, Webtrends, Clicktracks, WebAbacus, Site Intelligence to name a few - still offer the option to use logs as the primary data source. How come? Let's take a look at how this battle plays out.


Round 1: Convenience

Say what you like about accuracy (and you will, I'm sure), but you can't beat server logs for convenience. If you have the logs to hand, once you've installed your web analytics product, you simply point it at the logs, press the button, and sit back and wait for your data. There are wrinkles to be dealt with, for sure - you might have non-standard logs; you might have multiple web servers; or it might be difficult to gain access to the logs on your network (the three letters that strike fear into my heart? FTP), but most decent analytics tools can take these things in their stride.

Tag-based systems, by contrast, won't yield up a scrap of data until you've made code changes to your website and cut them live to your server. Then there's the hassle of ensuring that all the pages are tagged, and that pages don't become untagged at some later date when some developer looks at the code and thinks "what's this muck?" and removes it.

Round 1 winner: Logs


Round 2: Historical data

Straight back out of its corner after the success of round 1, logs delivers a second blow to tags: historical data. If you've been keeping your raw log files, a logs-based web analytics tool will be able to process that set of historical data and give you an instant picture of weeks, months or even years of activity on your site.

Tags just can't match this - the data only starts to be collected on the day you implement the tags, so you can't get a historical picture, by definition. This also makes it more challenging to move from one web analytics tools to another, since in the new tool you can't get a historical picture to ease the transition. It means that many companies leave their old tool in place for months whilst the new tool builds up a base of data - costly if you're paying for one or both tools.

Round 2 winner: Logs


Round 3: Visit and visitor counts

After its easy victories in the first two rounds, logs comes out with a swagger to square up on visit and visitor counts. But this time, tags is more than a match. Pretty much every tag-based analytics system serves up a persisitent cookie with the tag, and uses this cookie to sessionize the data (that is, build visits, by identifying page requests from the same user) and generate counts of unique users over longer periods of time. Once you've gone through the pain of instrumentation, this stuff comes pretty much for free, and is a great benefit.

It's perfectly possible to use cookies as user identifiers in a logs-based system; but firstly the site has to issue a cookie, and secondly that cookie has to be persistent and pervasive (i.e. every page should issue it if it isn't already present in the browser). This can be a royal pain to set up.

Round 3 winner: Tags


Round 4: Accuracy

With a win under their belt, the team in the tags corner is starting to feel a little more bullish. And, sure enough, when it comes to accuracy, tags give logs a run for its money. The main reason for this is that the actual tag request made by the JavaScript in a tag-based system cannot be cached; so every request made by a visitor ends up being recorded by the system that's listening out for the tag requests, resulting in pretty good accuracy at the page impression level

Log-based systems, on the other hand, are at the mercy of intermediate caches on the Internet - if a particular page (say, the home page) is relatively static and popular, a big subset of users will never hit the actual site's web server when they request that page - they'll be served a cached copy from a proxy somewhere between them and the site's server (probably at their ISP, or their corporate firewall). So a tag-based system can under-report page impressions by as much as 80% (though 40-50% is a more common figure). Worse still, the pages in a web site are not evenly cached, so a home page will be served from cache much more often than a deep page or a checkout page. This means that the shape of funnels can look screwy, and it is very difficult to determine anything other than broad traffic patterns.

Round 4 winner: Tags


Round 5: Non-HTML content

Not every web site is made up entirely of HTML. Come to that, not every transaction-based system that you might want to analyze the usage of is HTML based - for example, call center or IVR system usage. In these situations, log-based systems come into their own; many log-based analytics systems can turn their hand to a surprising number of analytics tasks, as long as the system they're analyzing the usage of can generate a log of its usage.

It used to be the case that this was a sucker punch for logs for non-HTML content on web sites too - but recently tag-based systems have got more adept at finding ways to track the usage of PDF files and other non-HTML content. Both Google Analytics and Gatineau have this functionality, for example.

Round 5 winner: A draw


Round 6: Sub-page events

Another knock-down for tags in this round. Sites which refresh content (manually or automatically) without executing a full page refresh present a particular challenge for web analytics tools of all stripes; but tag-based systems rise to the challenge much better than log-based ones. Increasingly, tag-based analytics tools offer the ability to attach a JavaScript event call to sub-page events, and track them as a separate kind of interaction (i.e. not a full-fledged page impression, but something worth counting nonetheless).

To pull this off with a log-based system, you'd have to modify your site code to generate a dummy log entry on your web server (perhaps by requesting a non-existent HTML file), and then, whilst processing the data, treat this HTML file and others like it as a special case, ensuring the analytics system doesn't accidentally count it as a page impression. It's doable, but gnarly, gnarly, gnarly. And I don't know of any log-based analytics system which implement a sub-page event model (perhaps someone can enlighten me via the comments box).

Round 6 winner: Tags


Round 7: Data integration

The team in the tags corner cries foul at this point, pointing out that data integration is more a function of whether you run your analytics system in-house or have it hosted as a third-party service; and that there are plenty of web analytics tools which can combine tag-based data collection with an in-house service. But there's a strong correlation between logs/tags and in-house/hosted, so the referee allows the fight to continue.

In-house systems do make data integration easier. A log-based analytics system will capture all the user identifiers (in cookies, typically), including those used by the site's own CMS, and a half-way decent web analytics tool will allow these identifiers to be extracted and then used as a key for the import of related data (for example, the purchase history of a known customer).

Because tag-based systems tend to send their tag request to a third-party server (the web analytics provider's data collection server), these cookies are not automatically captured. You can modify or customize the tag script for some tools to capture identity cookie values as variables, but then you're still left with the challenge of importing potentially sensitive customer data across the Internet. Data protection laws in the EU and US state that in order to use customer data for this "secondary use" and transfer it to a third party, you have to get the customer's explicit permission - something that most site owners are reluctant to do, for obvious reasons.

Round 7 winner: Logs (kinda)


The final score

Finally the competitors stagger back to their corners, bloody but unbowed. After some debate, the judges declare the final score to be:

Tags: 3,    Logs: 2½

So, a closer result than you might think. Tagging wins out (just) because of the better quality of the data it yields up; although it's a pain to instrument a site, you immediately get access to pretty good-quality, well sessionized data that you can start to build reports around. Logs are much more of a struggle to get set up to deliver good quality data, but once you're there you have as much flexibility as with a tag-based system, and more in some respects (for example, in the area of data integration).

del.icio.usdel.icio.us diggDigg RedditReddit StumbleUponStumbleUpon

January 15, 2008

Web Analytics in the movies

image So if you thought you were destined to spend the rest of your life explaining what web analytics is to bored-looking people at cocktail parties, think again, because Sony Pictures is about to take the industry mainstream (kinda) with the release of Untraceable, a movie about a serial killer who uses real-time traffic data from site visitors to decide how quickly to kill people. I always knew it was a dark art...

One of the more amusing details about the movie is the location that it was filmed in - none other that Portland, Oregon, home of Webtrends, and, of course, the one and only Eric Peterson. Anything you want to tell us, Eric? ;-)

del.icio.usdel.icio.us diggDigg RedditReddit StumbleUponStumbleUpon

January 09, 2008

Why can't you install Gatineau? (And other questions)

floppy We've had an interesting post over on the Gatineau discussion forum from Dan Regalia. In his post, Dan asks why we've chosen to provide Gatineau as a hosted-only service, with no API or connections to Microsoft's (or anyone else's) CRM platform, and no ability to run locally. I started writing a response to Dan's post on the Gatineau forum, but given the slightly wider readership of this blog, and the broader questions that Dan raises, I thought I'd put those answers here. Dan, if you're reading this, I hope you don't mind that I've answered your question in this way. If you have further questions, you're more than welcome to contact me directly.

You can read Dan's full question here. But here's a slightly shortened version (for those of you unfamiliar with DeepMetrix, the company we acquired to build Gatineau, LiveStats is their previous product line - see www.deepmetrix.com for more information):

While Livestats was valuable as something I could run locally, and manage my log files, (5 years worth of log files) etc, I'm finding that this is no longer the case with Gatineau.  So, any website trends that I've had until I get my beta code, are basically lost.  Secondly, there is no integration points with any of my current systems, such as our CRM or custom membership providers.  I am going to assume that all I get is a javascript link that I put into my webpage (much like i do for Google) and view a bunch of canned reports.

I guess what I'm saying is that while the current version of Gatineau, as it stands, will be no better than what's currently available for free from Google, we will not have any access points for system integration, and we will not own our data.  While this may be good for a personal website, or a small business, this is not something that I would not recommend for a corporate solution.  Google at least has Urchin, which is available to host on your own servers, but integration with that system may prove to be too large of project that we want to tackle. 

I would expect though, from Microsoft Corp (not the Live franchise)  is to have something available for us (corporate developers and system integrators) to tinker with and build internal systems with, with our own bells and whistles.  I am hoping that this may be something that is part of Gatineau in the near future, if not the final release.  I wouldn't mind purchasing a 'Corporate Edition' vs. a private or small biz edition if one were available with features that were addressed above (hint hint hint)

The Question I pose to the forum is this:  What did you expect to see with Gatineau, and what did you want to do with it?

There are several interesting questions here. I'll try to pull them out and answer them below.


1. Why is there no installable version of Gatineau?

The best way to answer this question is to look at some of the reasons why we are introducing Gatineau, and some of the qualities of the service. Gatineau is intended to be a complement to and extension of the services we provide in our adCenter platform. For those of you who are not familiar with it, adCenter is our self-service advertising platform that allows advertisers to buy paid search and contextual ads on Microsoft's network (live.com and the MSN network).

Our advertiser customers have told us that they would like to see better analysis of the effectiveness of their advertising expenditure. We also feel that adding a useful and well-integrated analytics package to our self-serve advertising platform, we'll make that platform more attractive to advertisers. And finally, given that it is known that web analytics helps marketers to spend their online budgets more effectively, we're hopeful that the analytics capabilities in adCenter will lead to a little more money being spent in adCenter.

To achieve these goals, Gatineau needs to be tightly integrated into adCenter. And because adCenter is a hosted service, Gatineau needs to be a hosted service. Plus, there are a number of key areas of functionality (in particular, the demographic segmentation capability) which can only be delivered via a hosted service.

Now, we could (as Google has done) introduce a separate version of Gatineau which is installable, and perhaps charge for it. Doing so would certainly offer our existing LiveStats customers a smoother transition to a new product. Indeed, it's something we thought long and hard about doing. I can't say that this is something we'll never do, but for the time being (and the foreseeable future) we have taken the decision not to provide the software in this way because we feel our engineering and support resources will be more efficiently allocated against a single product. I know from my experience running engineering and support for WebAbacus that supporting an installed product is no trivial matter - and Joel Spolsky agrees with me, so there.

To address the other part of Dan's question here, we don't feel that just because we are offering Gatineau as a hosted-only service that it therefore is exactly the same as Google Analytics. After all, Omniture and Webtrends' primary offerings are also hosted services, and they compete very robustly with Google's product. We feel that the demographic data in Gatineau is a significant differentiator, as well as its custom taxonomy capabilties - and those are just beta 1 features. From beta 2 onwards, we'll be seeing the advanced visualizations that I've trailed previously, as well as integration of paid search bid data from the three major search engines. So we're confident that Gatineau's not just another "me, too" product.


2. Why no integration?

Another aspect of Dan's post questions whether there will be any integration hooks in Gatineau to connect it to CRM, CMS and identity systems, and the like. It is one of the slight downsides of offering a hosted web analytics service that offering integration into customers' own systems becomes more challenging - not solely from a technical point of view, but more from a data ownership perspective.

At the moment, the only information I can share in this area is that Gatineau V1 won't contain any hooks or APIs to integrate external systems; but this is certainly something we're looking at. In these deliberations we need to make some key decisions about which integration points would be most valuable for our customers and partners.

Would it be most useful to offer a souped-up/automated data export feature so that other providers of services can integrate Gatineau data into, for example, CRM systems? Or would it be more useful to provide an interface UI so that other companies can "re-skin" Gatineau and offer it as part of their own suite of online services? Or on the third hand, should Gatineau be able to import data from other systems, keyed against some provided user identifier? If you have thoughts, my comments box is only a click away (well, probably a click, a scroll, a bit more clicking, tabbing and typing, and then a final click, but you get the idea).


3. What's the vision for Gatineau?

As I mentioned above, Gatineau is a key extension to our advertising platform value proposition. Even before our acquisition of aQuantive, this was a 10-figure business for us. Not only are we now in the business of selling advertising space on our own properties, such as MSN and Hotmail; we also represent (i.e. resell) a huge amount of ad inventory from third parties, ranging from Facebook through to Digg, CNBC, and the publishers who participate in our DRIVEpm ad network.

To compete effectively in this business, you have to offer advertisers great tools and data to help them make smart advertising decisions which will give them the best return on investment; and you have to offer intelligence and tools to publishers to make it easy for them to maximize the value they get from their inventory.

Analytics is central to this story. For advertisers, it delivers the insights about who the audience is, and how they're behaving after they click, helping those advertisers to make better media buying decisions, and optimize their site for conversions. For publishers, analytics provides the insight into content usage across the audience base which enables the publisher to sell that content (or advertising within it) at the best price.

What this means for Gatineau and our analytics efforts going forward is that you can expect to see Analytics capability very tightly integrated with our advertising tools, for both advertisers and publishers. I can't comment on the exact form this integration will take, or the timing on specific aspects, but if you're trying to understand the direction Gatineau will take in the future, you can be sure that it will continue to serve these two audiences as a priority. After all, they're the ones paying the bills.

del.icio.usdel.icio.us diggDigg RedditReddit StumbleUponStumbleUpon


About me



Enter your email address:

Delivered by FeedBurner