Part 2 in a Series on Web Analytics and Searching Engine Marketing Programs
Paul Bruemmer and I are going to be doing a Webinar on Search Engine Marketing and Web Analytics for SEMPO. If you’re following this series, check out the webinar this Thursday (http://www.sempo.org/learning_center/webinars/). It covers many of the basic themes I’m going to talk about in the next couple of weeks. And you will also get the benefit of Paul’s expertise – much beyond my own – on SEO and the hands-on practice of Search Engine Marketing.
SEM Analytics as a part of web analytics is a relatively recent development. But that isn’t because Search programs (at least Paid Search Programs) were going un-measured. In fact, a rich and fairly robust system of measurement has grown up around Search that is completely independent of web analytic tools. The world being what it is, this sometimes results in corporate spats that are pretty much the equivalent of my two daughters fighting over whose "stuffy" is better.
These separate systems are a bit of curse – but there are sound reasons for their existence. In this post, I’m going to walk through what Search practitioners traditionally measure and how this compares to what web analytics solutions provide.
Search measurement systems typically combine two major pieces of information – data about your bid and data about visitor behavior. This combination yields a fairly rich view of the immediate system. Key data points include:
- Keyword: The Term you are bidding on.
- Match Type: Broad or Exact – indicates whether the search must match or only include your target term.
- Max. Bid: Your Bid (usually expressed as the CEILING you will pay for a click).
- Impressions: How many times your ad for this keyword was shown to a visitor.
- Clicks: How many times a visitor clicked on one of your ads for this term.
- Total Cost and Avg. Cost Per Click: The amount you paid for the traffic on this term – the average is simply Total Cost / Clicks. Note that this is NOT Bid x Clicks since Bid is a ceiling not an actual bid amount.
- Avg. Position: The average display position (rank ordering) of your ad when shown. This is usually a decimal number like 1.5 – indicating that your ad was sometimes first and sometimes lower.
All of this information is reliable. There are no practical means of checking numbers like Impressions and Position, but I know of no reason to believe the numbers are not accurate. Clicks is a horse of a somewhat different color. For while there is no reason to believe that clicks are miscounted, there is every reason to believe that a fair percentage of clicks are "fraudulent." It’s also very important to understand that a Click is NOT a LAND. Nor is a click a SESSION. More about this in just a moment.
To this point, all of the data we’ve been talking about is native to the Search Engine. But Search Marketers have long realized that this data isn’t sufficient for optimization. To optimize, you need to know what happened after a visitor CLICKED.
To achieve this, Search Engines and Bid Management tools have implemented their own basic tagging implementations. These systems typically involve placing one or more tags on the web site. These tags use a 3rd Party cookie and are typically set with a moderate (30 or 90 day) expiration. The tags allow a Search Engine or Bid Management tool to bridge the gap from Click to LAND and, potentially, to CONVERSION.
In almost all cases, Search tagging schemes have the following characteristics:
- Only selected points on the site are tagged – typically conversions
- Commonly, no de-duping of sessions or visitors is provided
- Conversions are awarded to the most RECENT click
This basic outline should be enough to make it clear how web analytic tools and Search Engine reports will correspond and differ.
First, let’s start with what Web Analytics doesn’t provide. Your WA solution has no information about the Bid side of the equation (unless you are running a solution like Omniture’s Bid Center). That’s a big drawback. It means that most analysis you’ll do needs to paired up with outside information before it’s useful (that pairing-up, by the way, can be problematic even in solutions like Bid Center). Pairing up is especially difficult because, at the lowest-level – the Search Term – the Search Engine and the Web Analytics tool don’t match.
Even more important is the fact that your bid management tool doesn’t have access to the web analytic data. If you are relying on machine optimization, it’s absolutely essential that the optimizer have access to key site behaviors. If it doesn’t, then it can’t optimize. It’s this simple fact, more than anything else, which has led to the duplication of systems around SEM measurement.
On the other side, there’s quite a bit of information a web analytics solution has that isn’t available in Search reporting. Key among these are: detailed site behavior including paths and content views, information about sessions and uniques, information about prospects/customers and new and repeat visitors, information about other channel interactions and first sources and, in most cases, detailed commerce information or advanced measures of engagement. This greatly expanded view of actual behavior is the reason you need web analytics tools in addition to your SEM measurement.
But, of course, whenever you have two systems, you have issues with reconciliation. Clicks, for example, do not correspond to ANY of the expected numbers in the web analytics toolkit. In web analytics, a Click will normally trigger a Page View. If the visitor hasn’t been on the site in the last 30 minutes, this Page View will also start a Session and be flagged as Entry Page along with an associated Referral. This is what you'd expect to happen every time. But if the visitor has been on the site (and believe me, this happens) then the Click may be recorded but not as a Referral, a Session or an Entry Page. Some web analytics packages make this fairly clear. Others don’t.
In addition, many Clicks won’t show up at all. The reasons for this range from the obvious to the obscure and controversial. First, clicks from robotic sources may well be counted (and billed) by your Search Engine and yet discarded by your (tag-based) web analytic package. In addition, it’s possible the user can change his/her mind and stop or even kill the browser before your page loads. Or a user may click multiple times on the link. Engines are supposed to eliminate this, but you never know.
And don’t forget good old fashioned human error. Remember, your web measurement solution doesn’t know a Paid from an Organic click-through unless you code your Paid listings and tell your WA tool how to decode them. Forget this code, and you’ll be missing Paid clicks.
In addition, if you are running a tag-based solution, the tag may not fire on the Landing Page. This is especially likely if, like most sites, the tag is placed at the bottom of the page. Given a slightly weighty page, a visitor can kill or back-out of a page before it ever loads.
Finally (though we’ve never actually seen this happen), the amazingly sophisticated fraud detection measures used by the Search Engines might actually remove Clicks that you counted in your web analytic solution.
For the most part, you should expect a 10-15% difference between what your Search Engine reports as Clicks and what your tag-based analytic solution actually tracks as Clicks from Search. Think of it as a "cost-of-business."
Remember too, that a click is not a SESSION at all. If your web analytic package is tracking only SESSIONS, then the difference may be substantially greater.
The situation becomes even murkier once you start comparing conversion numbers. On the one hand, conversion numbers are actually being tracked using a pretty similar methodology – cookies. But if your site uses a 1st Party Web Analytics Measurement Cookie, then there’s going to be a fairly substantial difference in numbers. And if you have a long sales-cycle, then the expiry on the cookies can become a significant factor as well.
And, of course, as I’ve already remarked, the relative positions of the two tags can make a substantial difference in counting.
So what’s the bottom line on all this? First, it’s essential to understand that you live with two systems for a reason. Bid Managers need direct and continuous access to their operational information (Cost/Bid/Clicks) along with information about site behavior. This is always very important, and it’s absolutely essential when using any bid automation. You can ameliorate this disconnect by using a Bid Management tool from a Web Analytics vendor – but you’ll have to make your own decision about whether these tools are "best-of-breed, " whether they match your PPC Buyers needs (and knowledge/training) and how much you’re willing to sacrifice for integration.
On the other hand, SEM reporting is missing lots of data (and tools for analysis) that can provide a much richer picture of how SEM visitors behave, how they interact with other programs and how they interact over time. So there’s a decent chance you’ll be living with two SEM reporting systems: SEM measurement for operational optimization and cost reporting; Web Analytics for cross-channel measurement and strategic optimization.
[Don’t forget to register early for X Change – The Early Registration Discount ends July 31st! Use Coupon Code XCForum at http://www.semphonic.com/conf to reserve a spot!]

Hi Gary,
Interesting post. Generally speaking, the more components one adds to the ecommerce ecosystem, there more there is a tendency to create more and more "silos" of information. The typical online business might use ASP solutions for bid management , merchandising, personalization, multivariable testing and so on. The WA vendors are trying to bridge these data sources together (for example Omniture Genesis), which primarily helps for the tracking and reporting of data, but not in the automatic decision making process since the various optimization tools tend to optimize to a very broad definition of “conversions” only (for the reason you mention and because they cannot replicate everything a webanaltyics platform measures). The current data gateways between ASPs and web-analytics vendors are generally bespoke and one-way, but wouldn’t it be interesting if a third-party bid-management tool for example, could use an open webanalytics API standard to make use of bounce rate, abandonment and other more granular measures of outcomes that are abundant in all webanalytics tools and which clearly can improve the optimization process?
Clearly there are merits to select the components of a successful ecommerce ecosystem on a best-of-breed basis but careful consideration have to be made on how one can make use of the rich set of webanalytics data to flow back into external automated/rules-bases systems.
Posted by: Peter Ahl | July 19, 2007 at 03:35 AM