I was talking to a senior marketing friend the other day -- he's been CMO at a couple of major analytics vendors -- and telling him about how the enterprise analytics applications (Omniture and WebTrends mainly) often require some level of customization before yielding meaningful results.
He said marketing folks tend to get scared when they hear the word "custom" applied to web analytics because they think it means endless rounds of semi-successful -- not to say quirky -- workarounds that are both expensive and time-consuming.
I had a tough time telling him he was wrong, generally speaking.
The fact is, web analytics doesn't often yield great results for companies that don't invest in some type of customization. Keep in mind that web analytics is a mature space, and what may be "custom" to your organization may actually be a "been there and done that" situation for a good consulting team.
And, as in many analytics conversations, there's the gentle reminder that "Google does that for free," which creates the temptation to hold off customization in the (usually unfulfilled) hope that the solution might be hiding somewhere in that free offering. Yes, you can spend zilch on Google Analytics, and have a Google-fanatic make the thing stand on its hind legs for you, but as of this writing, Google just isn't going to get you close to an enterprise solution, no matter how many times you count the dollars you saved by using it.
So let's talk about what "customization" means in a world where big companies are making big decisions based on their web analytics. Here are a few of examples of why that word should not make you run for your torch and pitchfork just yet.
Example No. 1: "Why can't I see my important data all in one place?"
The reason you can't is because you have not applied a custom solution.
Your analytics application isn't built just for you, but for lots of folks like you (and some not so much like you). It needs to satisfy enough of the people enough of the time so that there's actually a market for the product. That's why the better vendors build APIs (application programming interfaces) into their products. APIs are interfaces within the tool that allow a developer to either yank data out, plug data in, or create single views of data. Sometimes people call custom solutions "dashboards." We're seeing lots of folks asking for them these days.
Once you pull the data out of the application and into a common presentation layer like Excel, you start to see magic happening. Not only are there pie charts and completed ROI columns, but the pie-charts and completed ROI columns auto-update. I know this works because I know people who create this stuff using proprietary scripting that cuts down workload and minimizes risk. Is it still customized? Technically, yes. But it's also tested and known to work. It just isn't built right into the analytics application.
Example No. 2: "I'm stuck with incomplete and inaccurate data until my new site is finished."
Not if you let the right team deliver some customization.
Let's say your prior agency built a beautiful site that seemed to accomplish most of what you needed it to. But what if that agency (or your current agency, using prior specs) didn't do such a great job tagging the site? If that happens, you're stuck in no-analytics limbo until the new site is built. So you have to put up with inaccurate reports. But you may also be putting up with skyrocketing analytics vendor charges due to wasteful server calls (for instance, because the code was sloppy, you're getting charged more whenever on-site ads are rotated).
The existing site's code is frozen, and the new site is months off. Poor reports are one thing, but throwing money down the drain is quite another. Deploying a custom solution happens to save the day here: In a case I know of, a custom JavaScript was written and intercepted the existing tags, improved accuracy, and saved tens of thousands of dollars in overage charges on server calls.
That's not very scary, is it?
Example No. 3: "Mobile is really important to one of my overseas brands, and there doesn't seem to be a way to track this in my vendor's offering."
True, there probably isn't.
But that doesn't mean you have to tell your colleagues they can't track all the valuable mobile users after migrating to your new analytics tool. Sure, the old log-analysis method they used seemed to do an adequate job of tracking mobile activity, but it had other significant drawbacks. How about a solution that delivers both tag-based accuracy and mobile tracking?
In this case, there was a custom web-server plug-in that automated all aspects of the required mobile tracking, thereby saving the cost of tagging the many mobile sites and allowing the vendor consolidation to proceed.
Custom wasn't scary in this case -- it really delivered and saved a bunch of money.
I've just given three examples where customization is known to work well and deliver noticeable results -- even saving the customer significant dollars. And based on my experience, I know of very few sophisticated analytics environments that function without some level of customization.
So when you hear your analytics expert use the word "custom," there's no need to run in the other direction. Try to think more about how you can get the right team working on your specific business need, rather than whether customization indicates a flaw in either the application you bought, or your need for detailed data.
Andrew Edwards is managing partner of Technology Leaders, a web analytics consulting and technology firm.
On Twitter? Follow iMedia Connection at @iMediaTweet.