The Most Expensive Search Keywords
"It's cost/day (keyword price X clicks/day) that makes you rich, not keyword price itself," Xendant.
Hello everyone and welcome to my Web Experience/Performance blog. I hope you enjoy reading about my experience in the Analytics space and post back in a manner that will benefit us all. Happy Blogging!
Posted by
Adam Berlinger
at
9:17 AM
0
comments
Links to this post
...is like gaging gas consumption by pounds. Would you fill your car up with 100 LBS of gasoline? I bet you're scratching your head or clicking over to Google to find out how much a gallon of gasoline weighs, 6 - 7 LBS depending on the tempurature when you weigh it and if its deisel or not. Lots of different factors can effect the weight of gasoline; similar to the multi-faceted aspects that determine an actual visit. Not to mention our frame of reference, we're supposed to deal with liquids in terms of volume. And we're supposed to compute page usage via page views.
Let's not get confused with "Single Page Visits," visit sessions where visitors only view one page. Just my thought on a Thursday night.
Posted by
Adam Berlinger
at
9:08 PM
2
comments
Links to this post
Hello again everyone, it's been a while since my last post. Today I'd like to talk about internal search and how best to approach measuring it. Almost any analytics solution will allow you to track raw instances of each term entered into a site's internal search engine. In fact, many search applications will provide analytics reporting to the business users. But the key here, along with anything else in this space, is how to act on this information.
OK, so you've tagged your site to track each search term and you know what you're visitors are searching for, great! Now what? First and foremost, DO NOT ASSUME that visitors are searching from just your "home page." For some reason, many analysts (including myself) think of search in terms of landing on an unfamiliar site. Is search enabled/persistent across every page within your site? I hope so! If that is the case, then you need to pass the page the visitor was on when they executed a search, the term they entered and the content they viewed as a result of their search. How? By appending unique parameter strings to your URLs and pass that information to your reporting tool.
Let's take a look at what I mean via amazon.com. The screen shot below illustrates what content I'm viewing, found their via their navigational links. In this case, it a Samsung HDTV that' I'm trying to talk my wife into buying so we can watch the Super Bowl, er, I mean cuddle up and watch a nice movie together.

"url=Search-alias" tells us that a search was executed and "field-keywords=Invicta" gives us what I entered. You could pass these entities to separate reports depending on what analytics package you are using. Navigational analysis will tell us what I clicked on within the "Search Results" page. If you cannot track this kind of information and aggregate into something actionable, then get your analytics vendor in to make it work or dump them!
So now what do we do? Strategize on how you're going to act on this information. What business problems can I solve? If I cannot get to certain content easily while I'm deep within the bowels of your site, perhaps you'll need to evaluate your navigational design. Another great idea is to create a frame that provides a "Top 10 or 20 Items Searched For" and have it persist throughout the site. I hope you enjoyed this post and welcome replies to it!
Posted by
Adam Berlinger
at
2:24 PM
5
comments
Links to this post
Many applications require end-users to login in order to access there content. As such, we decided to pass the Authenticated UserID, e.g. aberlinger, of each visitor via sProp1 in Omniture. EVERY (yes every) user must login to access these sites. We started to notice a significant difference between unique visitors and authenticated userID's. Check out the stats below for March 2007:
How is this possible? What are the reasons driving the discrepancies in the data? We first need to understand how our analytics solution determines unique visitors as each package has its own proprietary method to calculate unique visitors:
SiteCatalyst determines unique visitor information using several technologies. The primary method of calculating unique visitors is by setting a persistent cookie on the visitor’s browser to uniquely identify the visitor. Cookie technology helps to avoid common pitfalls, for example, IP Pooling, caching, or tracking visitors behind a firewall, when counting unique visitors. If the visitor has disabled cookies on their browser, or if the visitor’s browser does not support persistent cookies, Omniture uses a combination of the IP address and the user agent string to determine if a visitor is unique or not. SiteCatalyst reports a small percentage (usually 1-2%) of visitors who do not support cookies.
Did you notice "cookies" in Omniture's definition above? Perhaps we should research cookies and their impact on analytics data. ComScore and many industry experts have found that cookie deletion can be as high as 40%! Have I totally ruined your day? Are you questioning the sanctity of your reports, especially the ones that end up on your CEO's desk? Wait, it gets worse. I ran some reports which illustrated users logging into our sites from multiple machines, IP addresses and with different browsers, yikes!!! Not to worry, there is a solution!
What we did was implement what Omniture refers to as "Visitor Optimization" where Omniture's proprietary/cookie-dependent visitor ID is replaced with our unique authenticated UserID. Once a visitor logs into the site, their authenticated userID gets recorded as a unique visitor. This takes IP addresses, cookies, and user-agent strings out of the equation, woo-hoo! The trick is to make sure that the authenticated UserID's are passed to each page viewed by each visitor. Guess what? It's working! The numbers match!
Ask your analytics vendor if they can implement the same type of solution. However, the fact that your tool might indicate that your site attracted 1,000,000 visitors when it was actually 750,000 should not matter. Why? Because the percentages of your KPI's will not change. Remember, KPI's are a ratio of visitors to success events/conversion rates over a period of time. In other words, if 3% of your visitors purchase a product, generate a lead or apply for a job...the 3% is what you should be focused on improving in context of the total visitors. While 3% of 750,000 is obviously less than 3% of 1,000,000...the patterns you notice on your site remain the same. I hope this helps, Adam.
Posted by
Adam Berlinger
at
12:39 PM
3
comments
Links to this post
Labels: authenticated userID, KPI, omniture, visitors
Someone on the Yahoo! forum asked is there where any good articles or opinions on what the KPI's should be for their B2B site. What I found interesting is why someone would go to external resources for help in determining KPI's for their site. Is that what he was really asking for? A simple list? I hope not!
In my humble opinion, the definition of and the process for determining KPI's are what really matter when approaching what to measure on your site: B2B, B2C or B2E. Eric Peterson does a great job of defining KPI's in his book, "The Book of Key Performance Indicators." Once you are comfortable with the terminology, start peeling the onion of your site by asking questions.
Now you'll start to give some context behind the purpose of your Web site and what you need to measure for continued success. Remember, each site is different...it's goals and business drivers will change over time as things evolve.
Of course, business stakeholders almost always gut hung up on the raws numbers and freak out when the exact totals don't look right. This is when you need to hold your stakeholders accountable by asking how their "traditional" metrics have helped them in the past. What actions have they been able to take by knowing the total of unique and repeat visitors? Then watch their eyes glaze over or stump that their management demands those numbers. Please remember folks that analytics solutions are not calculators nor were they meant to be. Get comfortable with the terminology and create a process for solving business problems by asking the right questions.
Posted by
Adam Berlinger
at
8:37 AM
2
comments
Links to this post
For those of us that work with IIS log files, enjoy the table below. The challenge is to know which fields within the logs will provide you with actionable data. For instance, will knowing the User-Agent string of each visitor to your site help your business? Eric Peterson covers this topic very well in his book, "Web Analytics Demystified." It would also be helpful to understand how to enable/disable specific fields within IIS manager along with the status codes for each server call.
The W3C Extended log file format is the default log file format for IIS. It is a customizable ASCII text-based format. You can use IIS Manager to select which fields to include in the log file, which allows you to keep log files as small as possible. Because HTTP.sys handles the W3C Extended log file format, this format records HTTP.sys kernel-mode cache hits.
| Field | Appears As | Description | Default Y/N |
Date | date | The date on which the activity occurred. | Y |
Time | time | The time, in coordinated universal time (UTC), at which the activity occurred. | Y |
Client IP Address | c-ip | The IP address of the client that made the request. | Y |
User Name | cs-username | The name of the authenticated user who accessed your server. Anonymous users are indicated by a hyphen. | Y |
Service Name and Instance Number | s-sitename | The Internet service name and instance number that was running on the client. | N |
Server Name | s-computername | The name of the server on which the log file entry was generated. | N |
Server IP Address | s-ip | The IP address of the server on which the log file entry was generated. | Y |
Server Port | s-port | The server port number that is configured for the service. | Y |
Method | cs-method | The requested action, for example, a GET method. | Y |
URI Stem | cs-uri-stem | The target of the action, for example, Default.htm. | Y |
URI Query | cs-uri-query | The query, if any, that the client was trying to perform. A Universal Resource Identifier (URI) query is necessary only for dynamic pages. | Y |
HTTP Status | sc-status | The HTTP status code. | Y |
Win32 Status | sc-win32-status | The Windows status code. | N |
Bytes Sent | sc-bytes | The number of bytes that the server sent. | N |
Bytes Received | cs-bytes | The number of bytes that the server received. | N |
Time Taken | time-taken | The length of time that the action took, in milliseconds. | N |
Protocol Version | cs-version | The protocol version —HTTP or FTP —that the client used. | N |
Host | cs-host | The host header name, if any. | N |
User Agent | cs(User-Agent) | The browser type that the client used. | Y |
Cookie | cs(Cookie) | The content of the cookie sent or received, if any. | N |
Referrer | cs(Referrer) | The site that the user last visited. This site provided a link to the current site. | N |
Protocol Substatus | sc-substatus | The substatus error code. | Y |
Posted by
Adam Berlinger
at
3:08 PM
2
comments
Links to this post
Labels: Eric Peterson, IIS, Log File, W3C, Web Analytics Demystified
I was talking with a Google Account Manager when he asked me: "If you had a web site that sold shoes, which search key word would be more important...shoes or Nike Pegasus?" Interesting question, isn't it? While shoes is a more general term, Nike Pegasus focuses on a specific product a seasoned Googler (Yahoo'er, MSN'er) would enter. While Internet shoppers become more sophisticated and technology continues to evolve...the answer will most always depend on the ROI of each Ad word across a specified period of time, e.g. December 2006.
For our fictitious web site, let's assume we averaged 850,000 unique visitors per month. Out of those 850,000 visitors, 3% convert by buying purchasing shoes for at least $50 per pair, $1,275,000. Now let's apply the statistics for the key word "Shoes" during December 2006:
Results for "Nike Pegasus:"
Although "shoes" is a more generic keyword that "Nike Pegasus," its PPC is 20% greater due to its popular demand by the marketplace. "Shoes" drove more monthly unique visitors to our site than any other month for all of 2006 and earned $1,330,000 more in profit than "Nike Pegasus." Not bad, right? But check this out...The overall KPI conversion rates for Nike Pegasus is actually greater than the conversion rates for shoes. In other words, while "Nike Pegasus" drove less traffic and profit to our site than "shoes," its conversion rates as a percentage were actually higher! A greater amount of visitors per keyword spent more money per purchase and registered for new accounts.
I'd appreciate your feedback. What action can we take with this data? What should we tell our fictitious client to do next? Spend more on specific terms or generic terms? I know this depends on the business goals. I'm actually dealing with this in my real life job...generic terms driving more traffic but generating less conversion rates as a percentage. When I brought this up with my client, they mentioned that driving a visitor to the site was considered a KPI, not just converting. I hope I inspired creative thought.
Posted by
Adam Berlinger
at
1:31 PM
3
comments
Links to this post
Labels: conversion, google analytics, key words, ROI, search