Why Meta-Data Matters when it comes to Implementation
Like most Web analytics consultancies, Semphonic does quite a few implementation projects. Unlike some organizations, it’s only a modest part of what we do. Most of our work, after all, is true analysis – either classic Web analytics or the type of Digital Marketing and Database analytics that I’ve been blogging about in my current series. So I think it’s fair to ask if that makes us better or worse at implementations – especially since this is a topic that came up repeatedly at my Summit discussions. What makes a good implementation team?
There’s no denying that a mono-focus on anything is likely to maximize your skill-set with reference to that task. If I’m looking for a brain surgeon, I want someone who’s done A LOT of brain surgeries. On the other hand, some tasks reward widely generalized experience. You can’t be a truly fine diagnostician unless you’ve seen a lot of different kinds of diseases.
The question, really, is whether you benefit most in an implementation from having someone with countless implementations to their credit or from someone who has implementations plus analysis. Because no matter how many implementations we do, you can always hire someone at Omniture or Webtrends or IBM who does nothing but implementations of their own product all day long.
I think the answer gets down to where you think the real difficulty in your implementation lies. If it’s on the technical side – the art of getting the tag on the page and making sure it’s working – it’s hard to see how our analytics experience is going to be much of an advantage. If, on the other hand, you’re primarily worried about getting the richest data capture you can, then it’s hard to see how someone who’s sole experience is doing implementations has anything like a complete knowledge set.
The fact is, implementation consultants rely on you to tell them what data needs to be captured or they deliver “best-practice” implementations based on somebody else’s experience. At their best, these borrow ideas from other people’s implementations and add them to yours (a practice we all engage in and that I heartily recommend). But the vast majority of vendor consultants and the myriad spin-offs from vendor professional service organizations have never DONE a single analysis. They’ve only heard, second-hand, about the data you need.
That might be alright except that most organizations don’t, themselves, have any clear idea about the data they’ll need. Unless you have deep analysis experience with the tool already, you’ll almost certainly miss all of the key data capture elements that ought to be part of the tool’s interface but almost never are (e.g. date-time, page depth, visit number, previous page). Yes, these are all captured by Web analytics tools. No, they aren’t captured in a way that facilitates actual analysis.
Even worse, you’ll likely miss the key meta-data elements that will ultimately prove necessary for nearly any type of analysis.
It should also be clear why ANY analytics implementation designed exclusively to support your Reporting requirements isn’t going to be rich enough. Analysis requires a fundamentally different and deeper set of data than reporting. You’d probably never use a page depth, visit number or time-stamp variable in reporting.
There’s a better than even chance you’d never use most of the meta-data fields I’ve described in reporting either. You will, however, need them for analysis and for Digital Database Marketing. So if you’re implementation group is pitching a process that bases your implementation on your reporting requirements, they’ve already gone badly astray.
When we develop requirements for an implementation, we do it on a combination of requirements from our two-tiered segmentation, reporting plan, analytics roadmap, and digital database marketing goals. Can implementers who haven’t ever done analysis or database marketing do the same?
Web analysis and Digital Analytics Marketing of the type I’ve been describing in my current series are not widely practiced or understood. In my last post, I described a dozen different Meta-data dimensions around page (and there are significant meta-data dimensions around visitor and visit that I haven’t yet tackled) that are common to many types of Web sites. The vast majority of Omniture implementations only capture a few of these – despite being done by very competent implementation consulting organizations.
After all, most organizations don’t know they need these dimensions, won’t ask for them, and won’t ever miss them until someone like us shows up. We’re not trying to cause trouble; we’re just trying to use the data.
The simple fact is that in our field, analysis is deeply dependent on data capture. That might be true everywhere, but the extent to which good analysis is dependent on meta not raw data points is unusual. Traditional database marketing analysis rarely needed meta-data to the extent that Web analytics does; and many of the other disciplines I’ve worked in are similar in that respect.
The necessity for meta-data in Web analytics (and the fact that our tools don’t allow for it to be easily grafted onto the data) places unusual demands on implementation. It’s why I firmly believe that the difference between a good implementation and poor one is most often found in the level of meta-data included in the data capture and is most often driven by the amount of analytic knowledge the implementer brings to the project.
Bottom line? You can’t build a great car if you don’t know how to drive. Software implementation always benefits at least a little from deep knowledge of actual usage; but in no field I’ve encountered is that more true than Web analytics. Unlike analysis, implementation isn’t all about the meta-data, but the difference between a good and mediocre implementation pretty much still is.
Next stop (after a post on comScore’s Digital Analytix), I’m going to tackle our Two-Tiered Segmentation. It’s a technique that lies at the heart of our approach to Web measurement and drives everything from better management reporting, a complete re-thinking of KPIs and Metrics, some of our most fundamental analysis techniques, and, of course, our data modeling efforts to support Digital Database Marketing.
