Gilligan on Data by Tim Wilson

Tonight (Tuesday) was our fourth Web Analytics (Wednesday) in Columbus. We switched venues this month, and it looks like it’s going to stick — settling in at The Spaghetti Warehouse. Bryan Cristina’s concern was warranted — I don’t know that I’ve ever been to a restaurant that has beer on tap…but only two beers, and one of them really doesn’t count. But, I’ll deal with it. And I’ll make sure I’ve unzoomed the camera the next time I hand it to a waiter for a picture, so the flash is actually in range of the group!

We had attendees from far and wide. Judy Thaxton-Borlin from Brulant, who sponsored the evening (thanks!) headed down from Cleveland. And we had the entire Chicago office from Resource Interactive (that would be…Ty)! Unfortunately, our speaker fell through due to a scheduling mix-up — we were slated to have the Community Manager from Bazaarvoice, but settled for a couple of handouts from the recent Bazaarvoice Social Commerce Summit 2008. We had a good discussion about social media — where, when, and how ratings and feedback work on a site (Bazaarvoice’s specialty, and Nicole West of Bath & Body Works discussed how they’ve used the technology, as well as the challenges they’ve come across in mining the data and assessing the impact of the initiative). We had a conversation about Twitter — myself (@tgwilson) and Bryan Cristin (@bigbryc) being the biggest users in the group, although neither of us are diehard advocates. That led to the tale of #wa and Twitter.

A good time was had by all. We’re planning a multi-pronged assault on various WebTrends contacts (Noe…we’re gunning for you!!!) to get beyond the Coremetrics and Google Analytics-centricity of the group.

We’re on tap to have our next one on July 15th — another Tuesday, again at 6:30, again at Spaghetti Warehouse, with Coremetrics as the tentative sponsor. Details to come at the WAW site!

Google Analytics recently had a bit of a hiccup with their data processing, which caused the tool to present inaccurate data for many users’ sites for the period between April 30th and May 5th. Google is reprocessing the data, and they expect to get most of it corrected. But, the situation triggered a lengthy and heated debate on the webanalytics Yahoo! group about what Google Analytics is/is not good for.

Stéphane Hamel assessed the situation using a strawberries/oranges/piña colada analogy that was pretty slick. I wrote up my thoughts on his thoughts over on the Bulldog Solutions blog.

(Yes, I’m still struggling to answer the weeks-old question: “If you contribute to two blogs, neither of which has a particularly large subscriber base, to which one should you post?”

I just got back from our third Web Analytics Wednesday — hosted on a Tuesday, because, doggonit, that’s just how we roll in Columbus. Deal with it!

We had a great guest speaker — Ken Barhoover from Brulant drove down from Cleveland and gave an excellent presentation on A/B and multivariate testing. Brulant uses Optimost for the most part, but they are tool-agnostic. The presentation covered both the basics of “why” on A/B testing, but Ken also went into some decent detail as to the logistics behind implementing A/B and multivariate tests. Very interesting stuff.

Finally, another Twitter user in the group — @johnboker attended!

And, thanks to Web Analytics Demystified for sponsoring the event!

Stéphane Hamel, it seems, is a bit peeved with Eric Peterson. These are two pretty big names in web analytics — Eric as one of the fathers of web analytics, and Stéphane as both a thought leader in the space as well as the creator of one of the most practical, useful web analytics supplemental tools out there — WASP: The Web Analytics Solution Profiler plugin for Firefox. With the plugin, you visit any site, and a sidebar will tell you what web analytics solutions it looks like it’s running. It’s pretty cool.

I don’t know the full background of the current back-and-forth between these two guys, but I’m a huge fan of Stéphane, and my ears perked up when I read this observation in the post:

Business Process Analysis implies understanding & improving a collection of interrelated tasks which solve a particular issue. Nothing new here… Most businesses face complex and “hard” processes, and the way to make them “easy” is by decomposing them into smaller sub-processes until they are manageable.

For one thing, for a period of ~8 months, my job title was “Director of Business Process Analytics.” And, frankly, I was never sure what that meant. In hindsight, if I’d had these two sentences from Stéphane and if I’d replaced “Analytics” with “Analysis,” I would have seen a much clearer mapping from my label to what I was actually doing in the role.

More important, though, is the concept of “decomposition.” I find myself preaching the Decomposition Doctrine regularly. And I believe in it strongly.

As an example, when it comes to the Holy Grail of Marketing Analysis — calculating the ROI of your marketing spend — many, many B2B marketers start out looking for the correlation between leads generated and revenue. I have yet to see a case in B2B where this can be found with a sufficiently tight, sustained correlation to be meaningful. That actually makes sense. It’s like looking for a correlation between the state someone is born in and the achievement of a PhD. There’s a lot going on over time between Point A and Point Z.

In the case of B2B marketing, decomposition makes sense. Decompose the process:

• The lead-to-qualified lead sub-process
• The qualified lead to sales accepted lead sub-process
• The sales accepted lead to sales qualified lead sub-process
• The sales qualified lead to close sub-process

Each of these sub-processes have people who proceed to the next sub-process as well as people who do not — put simplistically: people who “fall out of the funnel.” But, you can further decompose — of the people who fell out, where did they fall out and why? And does that mean they are gone forever, or are there processes/subprocesses that can be used to reengage them in the future?

The key here is that, from a theoretical perspective, if you link together all of the simpler sub-processes, then you’ve got an accurate representation of the more complex master process. The problem is that this is mostly true. There are probably other sub-processes that are unknown — those pesky “corner cases” that the real world insists on throwing at us. And, each sub-process likely experiences various anomalies over time. Add those together, and you’ve got a complex process that verges on the unanalyzable.

On the other hand, if you focus on a sub-process, you can analyze what is going on, including accounting for the anomalies. “But, isn’t there a risk that you’ll be missing the forest for the trees?” you ask. Absolutely. That’s why it’s important to start with a high-level view of the whole process, with a clear picture of the components that go into it. If you simply pick a “simple sub-process” to focus on, without understanding how and where that fits into the big picture, you run the risk of rearranging deck chairs on the Titanic. On the other hand, if you simply try to “analyze the Titanic,” without some level of decomposition, you’re equally doomed.

The topic of “Marketing ROI” has crossed my inbox and feed reeder on several different fronts over the past few weeks. I don’t know if the subject actually has peaks and valleys, or if it’s just that my biorhythms periodically hit a point where the subject seems to bubble up in my consciousness.

The good news is that the recent material I’ve seen has had a good solid theme of, “Don’t focus too much on truly calculating ROI.” The bad news is that that message has been in response — directly or indirectly — to someone who is trying to do just that.

One really in-depth post came from — no surprise — My Hero Avinash Kaushik. He did a lengthy post, including five embedded videos, each 4-9 minutes long: Standard Metrics #5: Conversion / ROI Attribution.  What the post does is walk through a series of scenarios  where a Marketer might be trying to calculate the ROI for their search engine marketing (SEM) spend. He starts with the “ideal” scenario: a visitor does a search, clicks on a sponsored link, comes to the site, moves through and makes a purchase. In that case, calculating/attributing ROI is very simple. But, that’s just a setup for the other scenarios…which are wayyyyyy closer to reality. The challenge is that, as Marketers, it’s we all too often ignore our own typical behavior and common sense so that we can assume that most of our potential customers behave in an overly simplistic way. When was the last time you did a search, clicked on a sponsored link, and then, during that visit, made a purchase?

Unfortunately, very, very, very few Marketing executives would ever actually spend the 45 minutes it would take to truly consume all of Avinash’s post.  And, honestly, that’s not really “the solution.” The smart Marketing executive will find the Avinashes of the world and will hire them and trust them. Avinash (and John Marshall) really make the case that “time on site” is a more useful metric for assessing the effectiveness of your SEM spend — ROI just brings in too many variables and too much complexity.

In short: Don’t treat ROI as the Holy Grail and try to tie every one of your marketing tactics to “revenue generated.” For one thing, you will head down so many rat holes that you’ll start drooling whenever someone says, “cheese.” For another thing, you will find yourself facing decisions that seem right based on your ROI calculation…but that you just know are wrong.

Another place where this topic came up was in a thread titled ROI Models - High Level Thinking on the webanalytics Yahoo! group. I responded, but others chimed in as well. Some of those responses, in my mind, are still a bit too accepting of the premise that “I need to calculate a hard ROI.” But, other responses go more to a “back up and don’t look at ROI as the be-all/end-all.”

And, finally, ROI crossed my inbox last week by way of a CMO Council press release from back in January. I saw this when it came out, but a colleague forwarded it along last week, which prompted me to re-read it. The press released emphasized how much marketers are focussing on accountability when it comes to their marketing investments. One data point that jumped out was “34 percent [of marketers] said they were planning to introduce a formal ROI tracking system.” This is an alarming statistic. Marketers absolutely should be focusing on accountability – finding ways that they can measure and analyze the results of their efforts. But, if they truly are framing this as the need for “a formal ROI tracking system,” then that means 34 percent of marketers are going to be largely chasing their tails rather than driving business value.

I’ve been a fairly avid follower and contributor to the webanalytics Yahoo! group for several years now. It’s a Yahoo! group that is almost 4,500 members strong and includes active participation by many of the top minds in the web analytics industry. I actually follow the group via e-mail, which seems awfully old school. As a matter of fact, the WAA Community and Social Media committee (which I’m a new…and not very active member of — Marshall Sponder does a great job of running the committee, and I do feel bad that I don’t help out more!) is trying to figure out how to get the group onto a better platform. There’s a bit of “if it ain’t broke, don’t fix it” discussion on the subject, honestly. And unfortunately. The fact is that I doubt that a majority of those 4,500 people are really embracing social media just yet. And this online community is already awfully vibrant and successful on the current platform.

The Yahoo! group was originally formed by Eric Peterson. As that list grew (Eric passed it over to the WAA a few years ago), Eric got the idea to start up a convention of having a “Web Analytics Wednesday” on the second Wednesday of the month. This would be a designated date for web analytics professionals throughout the world to get together for a few drinks, to network, and to share ideas and challenges. Initially, the organization and coordination of these meet-ups happened directly through the Yahoo! group. But, Eric eventually put up a nice little application on his web site to facilitate these, and they’ve continued to grow.

Several months after moving from Austin to Columbus, I caught two posts in rapid succession on the webanalytics group that were clearly from people in Columbus. A couple of e-mails and a lunch meeting later, and we were hosting the inaugural Web Analytics Wednesday in Columbus! We actually held it on a Tuesday, as the venue we found promised to be less crowded then. We had a dozen people show up, it lasted for over 3 hours, and the overwhelming consensus was that it was worth doing again. Now, we just have to figure out how to structure it!

Unfortunately, one of the key organizers — David Culbertson of Lightbulb Interactive — wasn’t able to make it. But, he did manage to get a nice post up on his blog, including the picture that we took with Jonghee Jo’s camera.

I guess I’m getting old enough that I’m still amazed at the power of the internet to pull together a group of people with a very focussed area of interest. And to make the leap from online to in-person interactions so smoothly no less!

Avinash Kaushik just published a post titled History Is Overrated (Atleast For Us, Atleast ForNow). The point of that post is that, in the world of web analytics, it can be tempting to try to keep years of historical data…usually “for trending purposes.” Unfortunately, this can get costly, as even a moderately trafficked site can generate a lot of web traffic data. And, even with a cost-per-MB for storage of a fraction of a penny, the infrastructure to retain this data in an accessible format can get expensive. Avinash makes a number of good points as to why this really isn’t necessary. I’m not going to reiterate those here.

The post sparked a related thought in my head, which is the title of this post: bounce rate is not revenue. Obviously, bounce rate (the % of traffic to your site that exits the site before viewing a second page) is not revenue. And, bounce rate doesn’t necessarily correlate to revenue. It might correlate in a parallel universe where there is a natural law that no dependent variable can have more than 2 independent variables. But, here on planet Earth, there are simply too many moving parts between the bounce rate and revenue for this to actually happen.

But.

That’s not really my point.

What jumped out at me from Avinash’s post, as well as some of the follow-up comments, was that, at the end of the day, most companies measure their success on some form of revenue and profitability. Realizing that there is incredible complexity in calculating both of these when it comes to GAAP and financial accounting, what these two measures are trying to get at, and what they mean, are fairly clear intuitively. And, it’s safe to say that these are going to be key measures for most companies 10, 20, or 50 years from now, just as they were key measures for most companies 50 years ago.

Sales organizations are typically driven by revenue — broken down as sales quotas and results. Manufacturing departments are more focussed on profitability-related measures: COGS, inventory turns, first pass yields, etc.  Over the past 5-10 years, there has been a push to take measurement / data-driven decision-making into Marketing. And, understandably, Marketing departments have balked. Partly, this is a fear of “accountability” (although Marketing ROI is not the same as accountability, it certainly gets treated that way) Partly, this is a fear of figuring out something that can be very, very, very difficult.

But, many companies are giving this a go. Cost Per Lead (CPL) is a typical “profitability” measure. Lead Conversion is a typical “revenue” measure. That is all well and good, but the internet is adding complexity at a rapid pace. Pockets of the organization are embracing and driving success with new web technologies, as well as new ways to analyze and improve content and processes through web analytics. No one was talking about “bounce rate” 5 years ago and, I’d be shocked if anyone is talking about bounce rate 5 years from now.

Social media, new media, Web 2.0 — call it what you like. It’s changing. It’s changing fast. Marketing departments are scrambling to keep up. In the end, customers are going to win…and Marketing is going to be a lot more fun. But we’ve got a lonnnnnnnnng period of rapidly changing definitions of “the right metrics to look at” for Marketing.

While it is easy to get into a mode of too constantly reevaluating what your Marketing KPIs are, it is equally foolish to think that this is a one-time exercise that will not need to revisited for several years.

Oh, what exciting times we live in!

We’re working with a client who is simultaneously deploying Eloqua for marketing automation while also switching from Urchin 5 to Google Analytics. All three of these tools provide some level of web traffic data. And, right out of the chute, the client was seeing 40% lower traffic being reported by Eloqua than was reported by Urchin 5. That raised questions…as the deployment of concurrent web analytics tools always does! Having put myself through this wringer several times, and having seen it crop up as a recurring theme on the webanalytics Yahoo! group, it seemed worth sharing some material I put together a couple of years ago on the subject.

First off, it is largely a waste of time to try to completely reconcile data from two different web analytics tools. This post really isn’t about that. Mark Twain, Lee Segall, or perhaps someone else coined the saying, “A man with one watch knows what time it is; a man with two watches is never quite sure.” The same is true for web analytics. Thanks to different data capture methods, different data processing algorithms, different data storage schemas, and different definitions, no two tools running concurrently will ever report the same results. The good news, though, is that most tools will show very similar trends. WebTrends preaches, “in web analytics, it’s the trends that matter — that’s why it’s part of our name!” But, even in the broader web analytics community, this is widely accepted. Avinash Kaushik had a great post titled Data Quality Sucks, Let’s Just Get Over It way back in 2006, but it still applies. Read more there!

This post, rather, is more the basics of “log files” versus “page tagging,” which are the two dominant methods of capturing web data. Page tagging has been much more in vogue of late, but its got its drawbacks. In the case of our client, their Urchin 5 implementation is log-based, while Google Analytics and Eloqua are tag based. And, not surprisingly, Google Analytics and Eloqua are providing traffic data that is fairly similar. But, even when two tools use the same basic data capture method, there is no guarantee that they will present identical results.

The following diagram tells the basic story of how the two methods differ (click on the image to see a larger version):

“But, wait!” you exclaim! “How come both of these have ‘log file processed’ in them? I thought one method was log file-based and the other was not!” <sigh> As it turns out, both methods are, in the end, parsing log files. With page tag solutions, the log file being parsed/processed is the page tag server’s log file. In theory, your main web server(s) could be the page tag server…but then the tool would be stuck having to sift through a lot more clutter to get to the page tag-generated requests.

I’m getting ahead of myself, but go ahead and file that little bit of information as a handy cocktail party conversation…um…killer (unless the cocktail party is a Web Analytics Wednesday event — it’s all about your target audience, isn’t it?).

In a log file-based solution — the left diagram above — the “hit” is recorded as soon as the user’s browser manages to get a request for a page to your web server. It doesn’t matter if the page is successfully delivered and rendered on the user’s machine. This is good and bad, as we’ll cover in a bit.

In a page tag-based solution — the right diagram above — the “hit” is recorded much, much later in the process. The user’s browser requests the page, the page gets downloaded to the browser, the browser renders the page and, as part of that rendering, executes a bit of Javascript. The Javascript usually picks up some additional information beyond the basic stuff that is recorded in a standard web request (such as screen resolution, maybe some meta tag values from the page, and so on). It then tacks all of that supplemental information onto the end of an image request to the page tag server. The page tag server log file, then, only has those image requests, but it has some really rich information included in them.

Got all that? Well, there are obvious pros and cons to both approaches.

Log File-Based Tools Pros and Cons

The good things about a log file-based approach

• They (more) accurately reflect the actual load on your web servers — your IT department probably cares about this a lot more than your Marketing department doe
• They captures data very early in the process — as soon as you could possibly know someone is trying to view a page, they record it

But, it’s not all sweetness and light. There are some cons to log files that are nontrivial:

• They miss hits to cached pages (by browser, by proxy) — this can make for some rather nonsensical clickstreams
• They are limited to data captured in the Web server log file — this can be a fairly severe limitation if, for instance, you have rich meta data in the content of your pages and you want to use that meta data to group your content for analysis
• They capture a lot of useless data — I just went to the Microsoft home page, and watched 65 discrete requests hit their web servers to render the page (images, stylesheets, Javascript include files, etc.); this is fairly typical, and means you wind up pre-processing the log file to strip out all of the crud that you don’t really care about
• It is difficult for them to filter out spiders/bots — there is a “long tail” of spiders crawling the web, so this is not simply a matter of knocking out Google’s bot, Yahoo’s bot, and Baidu’s bot; there is an unmanageable, constantly changing list of known bots and spiders…and many bots mask themselves, which is extremely difficult to detect (this was actually the far-and-away biggest culprit with the client who spawned this post)

Page Tag-Based Tools Pros and Cons

Alas! Although page tags address the bigger negatives of log file-based solutions, they have their own downsides. But, let’s start with the positives:

• Because they are Javascript-based, they are able to capture lots of juicy supplemental data about the visitor and the content
• Most (not all, mind you) spiders/bots do not execute Javascript, so they are automatically omitted from the data
• The Javascript “forces” the page tag to fire…even on cached pages

There are some downsides, though:

• They requires the page tag Javascript to be deployed on every page you want tracked — even if you have a centrally managed footer that gets deployed to all pages…chances are there are still some important corner case pages where this is not the case; and, even if that is not the case now, that could happen in the future; we had a pretty robust system that was undermined when the design of a key landing page was completely overhauled…and the page tag was nuked in the process
• They do not record a hit to the page until the page has been at least partly delivered to the client — if you have visitors that bounce off of your site very quickly, you may never see that they hit the site at all
• If Javascript is disabled by the client, then you have to put in some sort of clunky workaround to capture the traffic…and what you capture will not be nearly as rich as what you capture for visitors who have Javascript enabled

So, What’s the Answer?

The obvious answer may seem to be to employ both approaches in a hybrid system. And, that is obvious if you or your management is so aggressively compulsive that you are willing to deploy major time and resources to try to pull this off (and very likely fail and create confusion in the process).

Let’s toss the obvious answer out then, shall we?

The answer is more simple, actually:

• Understand the pros/cons of both approaches
• Be clear on what your objectives are — what do you care about?
• Determine which approach will more effectively help you meet your objectives and go with that

Now, if you are a Marketer, there’s a pretty good chance that you’ll wind up settling on a page tag-based solution. If that’s the case, then it might still make sense to figure out where your log files are and to do a little snooping around in them. I’ve found log files to be very handy when the page tags throw some sort of anomaly. If you can narrow down the anomaly, the log file can be a good way to get to the bottom of what is going on. Page tags…with log files to supplement. Does that sound like a tasty recipe or what?

Avinash Kaushik — the man, the myth, the legend — had another excellent post yesterday. He titled it Web Metrics Demystified, which is a take on Eric Peterson’s Web Analytics Demystified (book, brand, catchphrase). Avinash has a background in data that extends into the broader world of BI and data warehousing. So, typically, his posts talk about “web” metrics and “web” data…but the “web” can be removed and you’ve got insightful thinking that is much broader than the world of web analytics.

In this post, Avinash laid out four attributes by which any metric should be judged. The metric must meet all four criteria to be a good metric — no ORs in this evaluation:

1. Uncomplex (or…um…Simple…but Avinash feels like the term “simple” has a “semantic implication” that he wanted to avoid) — all too often, we head down a road of trying to limit the number of metrics we’re looking at, so we combine multiple metrics into a single metric (I just saw one today: “annualized revenue by role based on current month’s revenue divided by number of people in the role and multiplied by 12″…OUCH!); or, we feel like a metric is too simple and doesn’t sufficiently reflect the nuances of our business…so we add in adjustments and tweaks that, in the end, just make the metric much harder to understand while only getting incrementally closer to an accurate reflection of reality
2. Relevant – it seems like this would go without saying…but it’s critical; have you ever found yourself or your company reporting on something simply because “we’ve always reported that?” It brings to mind a case at my last company where new functionality had been rolled out on the web site that was expected to offload some of the work that CSRs were doing with repeat customers; a report was established and distributed to a broad group on a weekly basis to monitor the global adoption of that feature; 3 or 4 years later, that feature was pretty much defunct…but I’ll be damned if we didn’t have someone still spending 15 minutes every Monday morning putting together that report and blasting it out to the masses! Relevancy is a slippery slope — it’s easy to think relevant means “directly links to the bottom line,” which it doesn’t necessarily need to do (see my last post).
3. Timely — Avinash has a great example of a company that had a query that took 3 months to run. That’s an extreme. He is also an anti-”real-time” guy, which I wholeheartedly support. Timeliness is indeed key. Somehow, I’d like to work Frequency in there, too, though. BI vendors often talk about having data that is real-time or near real-time…and then start pitching how you can check your dashboard “every morning.” This is misguided. The reason to have data near-real-time is so that whenever a user looks at it, it is as current as possible. Businesses are like boats — the bigger they get, the more room they need to turn. If you plan your Marketing campaigns on a 2-month horizon, then it doesn’t make a whole heckuva lot of sense to check your results every day! As a matter of fact, if you start making changes before you’ve let your last set of changes play out, you’re headed for a heap of trouble! But, Frequency is more a business usage of the metric than an attribute of the metric itself, so I’ll call this a side note to Timeliness.
4. Instantly Useful — I love this one as much as Avinash does. The challenge, in my experience, is that, when someone looks at data that is not instantly useful (read: actionable…but I suspect Avinash steered clear of that term due to its overuse), he almost never says, “I guess I shouldn’t be looking at that.” Rather, he says, “It’s not useful now…but it will be if we keep reporting it for the next few months,” or “It’s not useful now, but it’s important for me to see it.” That’s why I’m a major proponent of probing for actionability when establishing the metrics, rather than waiting until after they’ve been delivered and then seeing if they drive action. And, to be clear, “no action” is a valid action in my book, as long as it’s a conscious decision to take no action (as in, “we are hitting our target for this metric, so our ‘action’ is to maintain the status quo).

Good, good stuff that!

I got way backlogged (over a week — 150+ messages) on the webanalytics Yahoo! group. I started catching up last night, and then hit it again this morning.

This was the first I heard that WebTrends has had a major management shakeup (there’s another good article at MSN), with the CEO and a couple of other executives being removed from the company by the investors. The timing of this is really interesting, since it’s very fresh news that Omniture is acquiring Visual Sciences. And, Omniture acquired HBX/WebSideStory several years ago.

So, major consolidation in the space…and then a major shakeup at one of the few unconsolidated remaining players.

Anil Batra’s blog seems to have one of the most active discussions going on the subject. What’s interesting is that, so far, there is no emerging consensus as to what’s going on.

I was a driver behind switching from SPSS NetGenesis (groan!) to WebTrends On Demand three years ago at my previous employer. We didn’t even look at Omniture because we intentionally narrowed our scope to vendors that had the same product available in both an ASP and software model. It’s been hard to ignore the buzz about Omniture, though.

When we went with WebTrends, it was just as WebTrends was being spun off from NetIQ. I’m inclined to believe the speculation that there was one type of management needed to manage that transition — NetIQ was really weighing WebTrends down innovation-wise. And, the landscape has changed sufficiently that it may be that they simply need a different set of skills to continue.

As “Steve,” my favorite webanalytics poster put it — just because WebTrends still has the largest installed base of any major WA vendor, that’s not a guarantee that they’re here to stay. He cited WordPerfect and Lotus 1-2-3 as examples!

In my opinion — supported by various case studies and discussions in business school — mergers and acquisitions generally don’t add much, if any value. That doesn’t speak well of the acquisition frenzy Omniture has been on for the past few years. But…I still hear a lot more of interesting stuff being pulled off successfully with Omniture than I hear from WebTrends.

It will be interesting to see how things play out.