My Carousel Use Stats

I started this post way back in March after reading Brad Frosts' bit on carousels. Then I let it sit unfinished. With the buzz around ShouldIUseACarousel.com this week, I figured I'd finish it up. The data is old, although I offer updated numbers at the bottom.

The Process

I looked at all the visits to my home page between February 1 and March 3 to get 30 days of data. Of those visits to the home page, 83% of the time the home page was the landing page. I figured if a smaller percentage of initial visits to our site came via the home page then I would not read too much into the value of these numbers as the user might have already been through enough of the site to get what he or she wanted, but 83% is a pretty big number.

The home page has many content areas, but by far the most prominent is our carousel. During the time frame tested, there were 5 different carousel images with accompanying text. Each one has its own Google Analytics event tracker so I can tell which carousel item has been clicked.

For those playing at home, and using Google Analytics, it's as simple as adding an onclick to your anchor: a href="/Products" onclick="_gaq.push(['_trackEvent', 'Slider', 'Columns']);". In this case I am tracking a custom event named "Slider" with the value of "Columns" (so I know which specific image/slide was chosen).

The Results

In the 30 days I tested, the carousel links were clicked less than 1% of the time the home page was visited — 0.8% to be slightly more precise.

Every other element on the home page received at least twice as much activity, with the tabs getting used nearly 10% of the time. Site-wide, the skip navigation link got clicked (tapped, followed) half again as much as the carousel at 1.2%.

To qualify this a bit, the carousel wasn't intended to serve as our only call to action on the home page. It's more about presenting a message to help brand the company as part of our new marketing push. Adding this tracking feature has allowed us to track how the carousel gets used, if at all, and which images/messages are more compelling.

The Latest Results

For this updated version of my draft post I looked at the last 30 days again (June 11 to July 11, 2013) to see what activity we've had on the carousel. The last 30 days are a good fit since we haven't been showing off the features of the slider to clients (which results in activity that is a function of people playing, not truly discovering and naturally using).

For the last 30 days, the number of clicks on the carousel is much lower. 0.2% of unique visitors clicked a carousel slide. For every 500 unique visits to the site, someone clicks on the carousel. Interestingly, this is the same number of people who print pages from our site and lower than the "skip navigation" activity in the same time period.

About the Carousel

Our site is a great place for us to experiment with the carousel since we can quickly refactor it, tweak it, replace it, and so on. Since its launch 7 months ago I have made a number of tweaks to the technology and we have played around with the messages to see what sticks.

We're revisiting the design of the carousel now to see how its relative size and different images and messages can affect its use. At some point it may go away, but not until I've had a chance to gather lots of data.

The carousel itself is both swipe-friendly and keyboard-friendly, uses a linear flow with a clear start and end, has indicators to show where a user is in the overall collection (also allowing a user to jump to a specific slide), and pauses when there is any action taken on the carousel (hover, click, tap, etc.). I built it to also serve images at appropriate sizes for appropriate devices, something which I am regularly tweaking. The base for this is the Royal Slider.

Related

• ShouldIUseACarousel.com


• Accessibility expert warns: stop using carousels, July 11, 2013.


• Carousels, January 23, 2013.


• Carousel Interaction Stats, January 22, 2013.


• Auto-Forwarding Carousels and Accordions Annoy Users and Reduce Visibility, January 19, 2013.


• Don’t Use Automatic Image Sliders or Carousels, Ignore the Fad, September 27, 2012.


• That big sliding banner? Yeah, it’s rubbish, September 6, 2012.


• 5 Big Usability Mistakes Designers Make on Carousels, August 2, 2011.

Read More

Tracking When Users Print Pages

A few months ago I had the pleasure of writing a piece for .net Magazine about print styles (Make your website printable with CSS). It was posted to .net's web site last month and received an overwhelming one comment. That comment, however, summed up something I hear all the time:

Would be interesting to see some statistics on how many people actually print websites.

For years I have argued that the best user statistics are those for the site you are building. In the absence of global numbers for how many users print web pages, in this post I'm going to show you how you can measure how many (and which) pages get printed from your site by using Google Analytics. I am also hoping those who know everything about Analytics can answer some of my questions.

The Concept

While looking around for existing solutions to track printed pages, I found this article: Use Google Analytics to Track When People Print your Web Pages (written exactly one year before I got my own code working). While there doesn't appear to be anything wrong with this approach (I did not try it), how it both produces the tracking code (JavaScript) and presents the data in Analytics (different than how I report on custom events), doesn't match my preferred approach.

I want to be able to call the Google Analytics tracking image (__utm.gif) only when the page is going to be printed, skipping unnecessary HTTP calls and the resulting image download (brief though it is). I rely on the CSS @media print declaration to call the image. I also don't want to write that image call to the page with yet more client-side script when I can assemble it all right on the server.

Since my post Calling QR in Print CSS Only When Needed already outlines the general flow (presuming I only want to support Internet Explorer 8 and greater), I can lean on the CSS syntax there.

To reiterate this technique will not work in versions of Internet Explorer 7 and earlier.

Constructing the Query String

I had a heck of a time finding information on how the Analytics query string needs to be constructed, and when I did find information it didn't always explain the values in much detail.

Google's developer site has information on all the query string parameters for the GIF request, but no information on what is required or what all the possible values might be. I did find a list of what may be the required parameters while searching among a thread on tracking emails with Analytics. Through a good deal of experimentation I came up with the following minimum list for my purpose:

Variable	Description
utmac	Account String. Appears on all requests. This is your UA-#######-# ID.
utmwv	Tracking code version. While my standard GA requests use 5.4.0, I opted to use 4.3 for reasons I no longer recall.
utmn	Unique ID generated for each GIF request to prevent caching of the GIF image. I just concatenate the current year, month, day, hour, minute and second.
utmhn	Host Name of your site, which is a URL-encoded string.
utmr	Referral, complete URL. In this case I just insert a dash so it is not blank.
utmp	Page request of the current page.
utmt	Indicates the type of request, which is one of: event, transaction, item, or a custom variable. If you leave it blank, it defaults to page. Because I am tracking events, I use event.
utme	Extensible parameter. This is where you write your event. I use 5(Print*{page address}). See below for why.
utmcc	Cookie values. This request parameter sends all the cookies requested from the page. It can get pretty long. It must be URL encoded. It must include __utma and __utmz values.

Because the whole point of this is exercise is to track the event in Google Analytics, it was important to understand how to construct the event for the query string. I struggled a bit.

Lazyweb: Can anyone point me to a reference that explains the "5" in Google Analytics query string event params? eg: utme:5(Print)(/Engage)

— Adrian Roselli (@aardrian) March 25, 2013

I still haven't figured out what the number 5 maps to, but it works. I also found that I need an asterisk as a separator, though I found no documentation explaining it. In the end, the only way a print event tracked as I wanted was when I constructed it as: 5(Print*/Accessibility). In this example, /Accessibility is the address of the page I am tracking.

The other tricky bit is pulling the cookie value and stuffing it into the string. Conveniently I can get to this within our content management system (QuantumCMS, which you should use) on the server side. Many others (if not most or all) have a similar ability. At the very least you have to include the __utma and __utmz values, passed as encoded parameters for utmcc. Without these, my tracking would not fire.

The Completed Query String

For ease of reading, I will break the string to a new line at each &. This represents what is generated when I visit the careers page on the Algonquin Studios site using Opera.

http://www.google-analytics.com/__utm.gif
?utmac=UA-1464893-3
&utmwv=4.3
&utmn=2013326124551
&utmhn=algonquinstudios.com
&utmr=-
&utmp=/Engage/Careers
&utmt=event
&utme=5%28Print*/Engage/Careers%29
&utmcc=__utma%3D267504222.1477743002.1364314722.1364314722.1364314722.1%3B%2B__utmb%3D267504222.17.7.1364314901604%3B%2B__utmz%3D267504222.1364314722.1.1.utmcsr%3D%28direct%29|utmccn%3D%28direct%29|utmcmd%3D%28none%29

Constructing the CSS

Now that you have the query string and the Google Analytics tracking image, you just need to call the image when the page is printed. All you need to do is embed a style block at the top of your page with the print media query, and call the image within it:

@media print {
 header::after
  { content: url(http://www.google-analytics.com/__utm.gif?utmac=UA-1464893-3&utmwv=4.3&utmn=2013326124551&utmhn=algonquinstudios.com&utmr=-&utmp=/Engage/Careers&utmt=event&utme=5%28Print*/Engage/Careers%29&utmcc=__utma%3D267504222.1477743002.1364314722.1364314722.1364314722.1%3B%2B__utmb%3D267504222.17.7.1364314901604%3B%2B__utmz%3D267504222.1364314722.1.1.utmcsr%3D%28direct%29|utmccn%3D%28direct%29|utmcmd%3D%28none%29); }

If you read my post on embedding QR codes, then this code will be familiar — I use header::before in that example. As such, I use header::after here so you can use them both keyed off the same element (header) without conflict.

If you look closely, you may have noticed that my event parameter looks like 5%28Print*/Engage/Careers%29 instead of 5(Print*/Accessibility). I URL encoded the parentheses on the entire string to make certain that they do not conflict with the parentheses in the CSS. If you don't do that, the browser will get confused and fail to load the image.

Once you have the CSS in place, I recommend going into HTTP Fox or the Chrome Developer Tools to make sure the image is called when you fire a print preview (save paper!), and then to make sure it has the parameters you expect — particularly the utme value:

Screen shot of Chrome Dev Tools showing the query string parameters for the tracking GIF.

Checking Your Google Analytics Report

Assuming you've verified all is working well, you just need to run a report for events in Google Analytics. Bear in mind that Analytics isn't up-to-the-minute, so you may need to give it some time to capture all the data.

Log into your Analytics account and make sure you set the report date to the time period where you rolled out these changes. Choose "Content" from the "Standard Reports" on the left side. From there, expand "Events" and then select "Top Events." You should see "Print" as one of the items in the "Event Category" column (you may need to show more rows).

After you click "Top Events," you will see all of the events you are tracking (if any other).

Click on the word "Print" in that grid and you will see all the pages that were tracked (ostensibly because you or a user printed the page).

The report is handy if you know the page addresses, but Analytics doesn't think of them as such. As a result, clicking the addresses will not take you to the page.

From here you can run a secondary dimension to cross-reference this with more information. In my example, I tested different pages in different browsers so I could quickly verify the cross-browser support. You can run screen resolution, landing page, or any other dimension that you think might be handy to compare.

An example comparing the printed pages with the browser as a secondary dimension of the report.

Conclusion

I am just adding this to my own site, so I don't have any numbers to offer as part of this post. However, if you implement this please feel free to let me (and everyone) know how many users you have who print and for what site. I don't expect the numbers to be high, but I do expect to see it happen here and there.

If you have any additions, corrections or suggestions, please let me know. I am still unclear how all the Google Analytics query string parameters come together and exactly what they all mean, so there may be some optimizations I can work into it.

Related

Related articles on print styles:

• Printing The Web by Hans Christian, March 25th, 2013.


• Tips And Tricks For Print Style Sheets at Smashing Magazine, March 8th, 2013.


• CSS Paged Media Module Level 3 at W3C.


• Use Google Analytics to Track When People Print your Web Pages, March 26, 2012.

Stuff I've Written

• Calling QR in Print CSS Only When Needed, March 8, 2013.


• Make your website printable with CSS from .net Magazine issue 231 (Summer 2012) and the web site as of March 5, 2013.


• Announcing PrintShame.com, April 9, 2012.


• More Evidence of the Need for Print Styles, April 6, 2012.


• Test in Lynx and Print, It's Your Job, December 12, 2011.


• More Samples of Responsive Web Design ≠ Print, October 13, 2011.


• Print Styles Forgotten by Responsive Web Developers, October 4, 2011.

Read More

My Viewport Sizes

Yes, that is my two monitor set-up — one display at 1,920 × 1,080 (with a browser at whatever size will fit my tabs) and one at 1,024 × 1,280 (with a browser always at 1,024 × 1,024). My browser reports two different screen resolutions depending which display the browser is using.

During the last rebuild of my site at least two years ago I started to track the viewport sizes of my visitors via Google Analytics. Since I don't care much about screen resolution (screen size), I don't bother to track it.

Yesterday I saw a post that tracks screen sizes between technical and not-so-technical visitors to the author's site. While the information is interesting, it doesn't include any viewport data, which happens to be what I care about.

This motivated me to jump into my Google Analytics and pull the viewport data that I have. The chart below represents what I found:

What I've done is grabbed the last 500 visits to my site for which I have data (even bad data) and plotted them in a scatter chart without regard to the frequency of a particular resolution. To be clear, this isn't scrubbed data and it's not from a site targeted at the general web user.

The block of code I use to get this data into Google Analytics does the job. I borrowed the code from the post Measuring browser viewport size with Google Analytics, though I make my viewport(); call at the end of the page, not in the body.

function viewport() {
  var myWidth = 0, myHeight = 0;
  if( typeof( window.innerWidth ) == 'number' ) {
  //Non-IE
  myWidth = window.innerWidth;
  myHeight = window.innerHeight;
  } else if( document.documentElement &&
 ( document.documentElement.clientWidth
 || document.documentElement.clientHeight ) ) {
  //IE 6+ in 'standards compliant mode'
  myWidth = document.documentElement.clientWidth;
  myHeight = document.documentElement.clientHeight;
  } else if( document.body &&
 ( document.body.clientWidth
 || document.body.clientHeight ) ) {
  //IE 4 compatible
  myWidth = document.body.clientWidth;
  myHeight = document.body.clientHeight;
  }
  _gaq.push(['_trackEvent',
   'Viewport',
   'Size',
   myWidth+'x'+myHeight]);
  _gaq.push(['_trackEvent',
   'Viewport',
   'Width',
   myWidth+'x'+myHeight,
   myWidth]);
  _gaq.push(['_trackEvent',
   'Viewport',
   'Height',
   myWidth+'x'+myHeight,
   myHeight]);
}

Hopefully that's enough to get your started on tracking viewport stats for visitors to your site. If you see ways I can improve it, then please do let me know. I can update this and we can all benefit.

If you are curious why I chose to skip tracking screen size and just focus on viewport size, I refer you to an article I wrote 13 years ago, along with more recent articles from me and others.

• Real-World Browser Size Stats, Part I, July 4, 2000.


• Real-World Browser Size Stats, Part II, July 4, 2000.


• Browser viewport statistics, November 10, 2009.


• Screen Resolution ≠ Browser Window, June 17, 2011.


• Browser screen resolution stats rile devs, April 13, 2012.


• Where's the Viewport Size Data? April 13, 2012.

Update: February 15, 2013

Welcome, visitors from the below tweet. Please post your own comments or even your own stats. I would love to see them.

What if we stopped measuring screen resolution and started measuring browser viewports instead? - bit.ly/149AFpk / cc: @ppk

— Smashing Magazine (@smashingmag) February 14, 2013

Update: November 13, 2013

To quote PPK, screen.width is useless. Devices don't consistently report device pixels or viewports in a consistent way. There is clearly still value in having some numbers, though the quality of those numbers is always suspect.

Read More

SEO Isn't Just Google

This past weekend I had the pleasure of participating in Buffalo's first WordCamp for WordPress users. Before my presentation I made it a point to sit in on the other sessions that were in the same track as mine.

When discussing SEO, all the sessions I saw mentioned only Google. The Google logo appeared throughout, Google's PageRank was discussed, Google search result screen captures were used, and so on.

The presenters for an SEO-specific session even went so far as to embed a video of Matt Cutts (from Google) in their presentation and declare that Matt Cutts stated that WordPress is the best platform for SEO.

For context, Matt Cutts appeared at a WordCamp in May, 2009 to discuss his search engine (Google) for an audience using a particular platform (WordPress). Matt even said, WordPress automatically solves a ton of SEO issues. Instead of doing it yourself, you selected WordPress (at about 3:15 in the video). He's pitching his product to a particular audience to validate their technical decision (he's just saying they don't need to manually code these tweaks).

If while watching that video you heard Matt Cutts declare that WordPress is the best platform for SEO, then you are engaging in selection bias.

This same selection bias is also happening when developers work so hard to target Google and not any other search engines. If you convince yourself that Google is the only search engine because you don't see other search engines in your logs, then perhaps you are the reason you don't see those other search engines.

To provide context, this table shows the ratio of searches performed by different search engines in August 2012 in the United States. These are from comScore's August 2012 U.S. Search Engine Rankings report.

Google Sites	66.4%
Microsoft Sites	15.9%
Yahoo! Sites	12.8%
Ask Network	3.2%
AOL, Inc.	1.7%

It's easy to dismiss 16% when you don't know how many searches that translates to.

More than 17 billion searches were performed in August 2012. Google ranked at the top (as expected) with 11.3 billion, followed by Microsoft sites (Bing) at 2.7 billion. The breakdown of individual searches per engine follows:

Google Sites	11,317,000,000
Microsoft Sites	2,710,000,000
Yahoo! Sites	2,177,000,000
Ask Network	550,000,000
AOL, Inc.	292,000,000

To put this another way, for every four (ok, just over) searches using Google, there is another search done in Bing. For every five searches using Google, there is another one done using Yahoo.

If your logs don't reflect those ratios in search engines feeding your site, then you need to consider if you are focusing too hard on Google to the detriment of other search engines.

Now let's take this out of the United States.

Considering Bing's partnership with the Chinese search engine Baidu, contrasted with Google's battles with the Chinese government, it might be a matter of time before Bing tops Google for Asian searches. Given the size of the Asian market (over half a billion users), if you do any business there it might warrant paying attention to both Baidu and Bing.

Related

• Selection Bias When Reviewing Browser Stats, March 13, 2011.

Update: May 15, 2013

Bing is now up to 17%, having taken almost all of that extra point from Google.

Read More

Selection Bias When Reviewing Browser Stats

A recurring problem I find is when web developers, their support teams and their managers try to evaluate who is using their site(s) by reviewing their web logs (or Google Analytics) in a vacuum. It is far too easy to simply look at statistics reporting what browsers use a site to determine what browsers should be supported as new work is done. Unfortunately, this rarely takes into account how well the current site works with current browsers.

If your site, for example, uses features that are unique to a particular browser, you can expect to see that browser rank higher in your reports. This isn't necessarily because the browser is the preferred browser of your audience, but because users on different browsers either don't or can't use the site and either go away (perhaps never to return) or return to the site in a different browser (which may not be their default/preferred browser).

This is essentially a selection bias when reviewing browser stats, effectively funneling a particular type of user (or browser) to the top of your reports, reinforcing a preset opinion or conclusion.

This is a mistake we all make for various reasons. For example, the 3rd Annual State of Web Development Survey was announced on March 10 by John Allsop. He's no slouch in the web development world, even having built a tool for editing CSS. But the survey site that gathers information from web developers has its own selection bias — it is unusable in Internet Explorer 8. The CSS for the site is trying so hard to use CSS3 features (that look pretty swell in, say, Chrome) that visiting the site in Internet Explorer 8 produces white text inside white form fields with white text on light gray buttons.

In Chrome, however, the CSS3 effects make for some nice highlighting that helps indicate where I am as I go from field to field:

src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhL1qhfXVCYbFKE9QQT9CtGYRQ6cSYfSD_91HgDfYx2-Nez9TbX5a5-YJVj5reNpiSJsePenvtEQM_QVzNPWu1v-SUldDrbzwb7-r4wskdVLUppbIPUpTx58z5MQK2lGRYapoJu8AH-LkFM/s320/StateOfWebDev2011_chrome.jpg" alt="Screen capture of Webdirections survey site in Chrome" title="Screen capture of Webdirections survey site in Chrome, showing a series of nice CSS3 features." />

The survey asks what my default browser is, but to even get to that question I had to drop out of Internet Explorer and re-open the survey in Chrome. Web developers on the whole may not use Internet Explorer as their default browser (I do because it's what my clients use and I want to see the web as they do), so Web Directions can expect a relatively low number of users to report IE. If Web Directions and John Allsop review the logs/reports to see what browsers people actually use, they can expect to see a far lower number of users filling out the survey in Internet Explorer 8 than claim to use it as their default browser (because they cannot complete the survey). I am hoping that they are all smart enough not to draw a conclusion from that disparity (perhaps that respondents are lying), although I have seen people make that mistake time and time again. To be safe, I did tweet them to let them know (no response yet).

Some developers, however, make a decision that blocks browsers without understanding the impact. It's one thing for a site to display a message telling users to upgrade (see the latest incarnation, Microsoft Promoting the Death of IE6), but it's a whole other issue when you actively block users of certain browsers (example images below). It's easy to justify to your client/employer that nobody uses that browser when you show the reports, especially if the client/employer does not use the browser and you have provided inaccurate data to bolster your points.

I've seen this many times in my career, but recently ran into it with a local not-for-profit whose web developers had convinced it that Internet Explorer 6 and 7 not only weren't widely used, but when faced with the fact that many users are restricted to those browsers at work, was told that end users shouldn't — and for the most part don't — surf from work due to corporate policies. Asking to back that assertion up with a report of activity on the site by time of day was met with silence.

This is a selection bias of the worst kind, one driven by personal goals and agendas and ignoring data to the contrary while refusing to acknowledge those who provide contrary data. As a web developer, the example of the Web Directions survey is unfortunate, but most likely just a mistake. In this latter example there is no excuse and it is your responsibility as a developer to provide a better level of service not only to your clients, but particularly to your users.

Examples

The site blocking Internet Explorer 6 and 7 users.

Yet the site works for users of Lynx.

Spoofing the IE6 user agent string to use the site.

Read More

Recent(ish) News on Google, Bing, SEO/SEM

I have written many times here about SEO/SEM and how so much of it is sold to organizations by scam artists (though I recoil at the thought of calling them "artists"). Too often it includes demonstrably false claims, like how meta keywords and descriptions will help your site and that you should invest in the SEO vendor to do just that.

I also try hard not to spend too much time addressing the ever-changing landscape of the search engines, let alone focusing on just one of them. However, sometimes it's worth wrapping up some of the more interesting developments because they can genuinely affect my clients who aren't trying to game the search engines.

Content Farms and Site Scrapers

If you've spent any time searching through Google you may notice that sometimes you get multiple results on your search phrase that look the same in the results, but when visiting the site you find they are just ad-laden monstrosities with no value. Sometimes one of these spam sites would appear higher in the Google search results than the site from which the content was stolen.

Google has now taken steps to not only push those sites back down to the bowels where they belong, but also to penalize those sites. These changes started in late January and went through some more revisions at the end of last month.

I think it's fair to expect Google to keep tweaking these rules. Given all the sites that offer RSS feeds of their content (along with other syndication methods), it's likely that many sites integrate content from external sites into their own. The trick here will be for Google to recognize a site that has a original content that also syndicates third-party content from a site that has nothing but content taken from elsewhere. If you do syndicate content, then you should be sure to what you site stats and your ranking in the search results to see if you are affected at all.

Additional reading:

• Finding more high-quality sites in search


• Google Changes Algorithm To Penalize Site Scrapers


• Do You Republish Other People's Content? You'll Want to Read This


• Google Declares War on Content Farms


• Google Announces Massive Algorithm Change, Declares War On Content Farms, Including Demand Media

Page Titles

Perhaps you have spent a great deal of time carefully crafting your page titles (specifically the text that appears in the title and which displays in your browser title bar). Perhaps you have noticed that in Google the title you entered is not what appears on the search results page. This isn't a bug, doesn't mean your site was indexed improperly, and doesn't necessarily mean your page title had some other affect on your page rank. This is done intentionally by Google.

This does imply, however, that your titles are unwieldy. Google does this when titles are too short, when they used repeatedly throughout a site, or when they are stuffed with keywords. If you find that your title is being cut off (implying it's too long) then you may want to limit your title to 66 characters, or at least put the most important information in those first 66 characters.

Additional reading:

• Dynamic Title Snippets on SERPs


• When Google Rewrites Your Title Tags


• When Google Titles Don't Match Page Title

Social Media

It wasn't that long ago that Google and Bing said that links in social media (think Facebook and Twitter) will affect a site's position in search results (PageRank for Google). Some people may even be tempted to run out and post links to every social media outlet they can find, hoping that the more inbound links, the better for their site. Thankfully it's not that simple.

Both Google and Bing look at the social standing of a user when calculating the value of an inbound link. This can include number of followers (fans/friends on Facebook), number followed, what other content is posted, how much a user gets retweeted or mentioned and a few other factors. In short, those Twitter accounts that come and go in a matter of hours that tweet a thousand links into the ether aren't doing any good. A good social media strategy that is garnering success, however, should also give a boost to the sites it links.

What is not clear, however, is how URL shorteners (and which ones) affect the weight of those links.

Additional reading:

• What Social Signals Do Google & Bing Really Count?


• The Straight Dope on Facebook, Twitter, and SEO


• Google + Bing Confirm that Twitter/Facebook Influence SEO

Random Bits

These are some random articles I collected for posts that never happened. I still think there's good stuff in these and warrant a few minutes to read.

Google: Bing Is Cheating, Copying Our Search Results and Bing: Why Google's Wrong In Its Accusations should be read together. The accusation from Google that Bing is stealing its search results is fascinating on its own, but reading Bing's response demonstrates a host of things Bing also does differently. For me it was an entertaining battle, but that's about it.

HuffPo's Achilles Heel discusses how Huffington Post relies on questionable SEO techniques, which I equate to spamming, and wonders how long the site will be viable if AOL isn't willing to keep up the SEO game as the rules change. It could be a great purchase for AOL, or a dead site full of brief article stubs.

Is SEO Dead? 1997 Prediction, Meet 2009 Reality is a two-year-old article dealing with a twelve-year-old argument. And still relevant.

When A Stranger Calls: The Effect Of Agency Pitches On In-House SEO Programs should be particularly interesting to people who are charged with some form of SEO within an organization. Too often the unsolicited call or email comes in making grandiose promises and citing questionable data and results. This article provides a good position from which to push back and make sure you and your employer aren't taken to the cleaners.

A 3-Step SEO Copywriting Confession almost sounds like an admission of wrongdoing, but instead talks about how to structure your content for SEO without completely destroying it.

Additional reading (that I wrote):

• Negative Reviews Can Now Affect Site Rank Downward


• Your Site Speed to Affect Its Google Rank


• Verified: Google Ignores Meta Keywords

Read More

Google Analytics Opt-Out Add-On Is Out

That title was more fun to write than I thought it would be.

Back in March I mentioned that Google had decided that it would let users opt out of being tracked by Google Analytics (Google to Let Users Opt Out of Analytics Tracking). That day is here. News sites all over the web lit up today with the news that the Google Analytics Opt-out Browser Add-on (BETA) is now available for download. And yes, that is its real name. It's still listed as a beta product, and it's only available for Internet Explorer (versions 7 and 8), Google Chrome (4.x and higher), and Mozilla Firefox (3.5 and higher).

There does seem to be a little something odd about adding more cruft to your browser to disable the cruft people have added to their sites to see how you surf their cruft. And this is assuming you believe that Google would release a free product to the end user that disables a free product targeted at site developers that also supports their paid Adwords product. Considering all the privacy flack Facebook has felt lately, however, it makes sense that Google wants to be able to say they are staying ahead of these issues. Google's download page explains... not much:

To provide website visitors with more choice about how their data is collected by Google Analytics, we have developed the Google Analytics Opt-out Browser Add-on. The add-on communicates with the Google Analytics JavaScript (ga.js) to indicate that information about the website visit should not be sent to Google Analytics.

To repeat myself from March, if you really want to surf anonymously, run Netscape Navigator 2 or version 3 with JavaScript disabled through an anonymous proxy. From a cave.

Google Opt Out Feature Lets Users Protect Privacy By Moving To Remote Village

Read More

Your Site Speed to Affect Its Google Rank

If you've been paying attention to the world of SEO and the intersection with Google, then you may have heard a few months back that Google was considering using the speed of a site to affect a site's rankings. Google has already factored in the speed of a site when considering its AdWords quality score.

On Friday, Google announced that it is now implementing site speed as a factor in organic search rankings. What this means is that if your site is an extremely heavy download or just takes too long to draw, then it may be penalized in the organic search listings.

While Google doesn't explicitly define site speed, it's safe to assume that it is a combination of overall page size (including files) and render time (including server response and time to draw the page). For those developers who seem incapable of posting anything smaller than a 1Mb image in the banner, or slimming down their HTML be removing all the extraneous cruft, this is motivation to start working on those optimization skills, even if their sites don't feel the wrath of the penalty.

Some things to keep in mind:

• Currently only 1% of search queries are affected by the site speed.
• There are over 200 hundred factors used in determining page rank, and this one isn't being weighted to high that it kicks out the major ones.
• It currently only applies to visitors searching in English (although you can expect to see them change that over time).
• It launched a few weeks back, so if your site hasn't changed in its search engine rankings, you are probably safe.
• Google links to a number of tools to test the speed if your site. Check out the links at code.google.com/speed/tools.html.
• Nealry four months old now, Google Site Performance is an experimental Google Webmaster Tools Labs feature that shows you latency information about your site.

Hopefully few of you are concerned by this. If you are following best practices, you are already striving to have your public-facing sites draw quickly. Not only does this do things like reduce the load on your servers, it also cuts down on your overall bandwidth costs. An additional advantage is that you don't have to rely on your end user having a fast computer, lots of RAM (or swap space on the drive), and a fast connection. Given how many people surf in corporate environments that aren't exactly cutting edge, this is just good practice.

Related Articles:

• Using site speed in web search ranking at the Google blog.
• Of Google and Page Speed at Zeldman.com
• Page Speed Factored into Google Search Rankings at WebSiteOptimization.com
• Site Speed Now a Factor in Google Rankings at LifeHacker.
• Google Search Rankings Now Consider Site Speed at Mashable.
• Site Speed May Soon Affect Google Page Ranking at Search Engine Journal.
• Site Speed, Google's Next Ranking Factor at Search Engine Land.

Read More

Google to Let Users Opt Out of Analytics Tracking

Given all the flak Google has taken recently (see my post yesterday, More Social Media Privacy News), I wasn't too surprised to see this headline come through from ReadWriteWeb: Google Will Soon Allow You to Opt Out of Google Analytics Tracking.

In a blog post from yesterday (More choice for users: browser-based opt-out for Google Analytics on the way), Google announced that it will be offering a browser plug-in to opt out of having their data tracked by Google Analytics. From the blog post:

...[W]e have been exploring ways to offer users more choice on how their data is collected by Google Analytics. We concluded that the best approach would be to develop a global browser based plug-in to allow users to opt out of being tracked by Google Analytics. Our engineers are now hard at work finalizing and testing this opt-out functionality.

I suspect this is more of a PR move than anything. Google Analytics is really just a method to track how anonymous users access your site — from what search terms or related site they came, what pages they visited, how long they spent, their click path, etc. None of this information exposes personal details and is even forbidden by their privacy policies. Check out the Google Analytics product tour for a quick overview.

What Google Analytics offers is not much different than what you get from a WebTrends report. And that data already exists in your own web server logs. In fact, Google Analytics cannot track anything if you don't have JavaScript enabled on your browser, making it impossible to track many mobile devices. Granted, you can get an overlay view of a page showing where users clicked in Google Analytics, which you cannot get in products that rely solely on the web server logs, but that isn't necessarily the key selling point. The fact that it is free is its strongest point. It also has swell reports.

The user who cares enough to download and install the plug-in may come from one of two camps:

1. He/she is already concerned about privacy and may even use anonymous proxy services to surf with an alternate IP address;
2. He/she has been told that Google is tracking his/her every move (again, recent press) and perhaps grabs this as a response (or has it installed by a friend or family member).

These users make up such a small portion of the surfing world that it probably won't impact the typical site. I doubt there will be a noticeable drop in data points in the Analytics reports of many sites. Others have posited that this move might make it easier to block internal users data from a company site (which can skew results) as opposed to blocking the IP range in the Analytics configuration screen. They fail to take into account how unpleasant it will be to administer (install and support) all those random plug-ins. No IT guy should be interested in that model at all.

The paranoid out there may feel that Google is tracking enough information about everybody, and while I don't disagree, trusting Google to release a plug-in to stop Google in Google's tracks seems like a flawed and circular argument. The truly paranoid shouldn't trust the plug-in to do what it says. I genuinely hope those conspiracy theorists aren't running Google Chrome, because the same argument applies.

If you really want to surf anonymously, run Netscape Navigator 2 or version 3 with JavaScript disabled through an anonymous proxy. From a cave. Perhaps Google will release a plug-in for those browsers?

ReadWriteWeb included this Onion parody in their story, and I just had to steal it to post here. It's too good to pass up (sorry about the scaling).

Google Opt Out Feature Lets Users Protect Privacy By Moving To Remote Village

Read More

New Google Analytics Features

In the article "Google Analytics Now More Powerful, Flexible and Intelligent" from last Tuesday (yes, I know I'm behind on this) on the Google Analytics Blog, the Analytics team has introduced some interesting new features. Some of the updates:

• Two new goal types allow you to set thresholds for Time on Site and Pages per Visit. You can also define up to 20 goals per profile.
  
• A server-side chunk of code is coming to allow tracking on moble sites (since mobile browsers may not be able to run the JavaScript Analytics code on a page).
• Advanced table filtering allows you to filter rows based on assorted conditions. In their sample video they show ho to filter keywords to identify just the keywords with a bounce rate less than 30% that referred at least 25 visits (it's much easier to understand with this video).
  
• You can now select unique visitors as a metric for custom reports.
• You can now have multiple custom variables so you can track visitors according to visitor attributes, session attributes and page attributes.
• You can now share custom reports and segments with other Analytics users.

There are two items over which the blog post is most excited:

Analytics Intelligence: We're launching the initial phase of an algorithmic driven Intelligence engine to Google Analytics. Analytics Intelligence will provide automatic alerts of significant changes in the data patterns of your site metrics and dimensions over daily, weekly and monthly periods. For instance, Intelligence could call out a 300% surge in visits from YouTube referrals last Tuesday or let you know bounce rates of visitors from Virginia dropped by 70% two weeks ago. Instead of you having to monitor reports and comb through data, Analytics Intelligence alerts you to the most significant information to pay attention to, saving you time and surfacing traffic insights that could affect your business. Now, you can spend your time actually taking action, instead of trying to figure out what needs to be done.

Custom Alerts make it possible for you to tell Google Analytics what to watch for. You can set daily, weekly, and monthly triggers on different dimensions & metrics, and be notified by email or right in the user interface when the changes actually occur. [....]

Read More

Three Good Site Search Articles

A List Apart has posted a triple threat today: three articles on site search and reporting.

1. Testing Search for Relevancy and Precision by John Ferrara discusses relevancy testing and precision testing for your search results based on what users have searched for within your web site. He even provides a spreadsheet to help you calculate relevanc, equations in place and ready to go.
2. Internal Site Search Analysis: Simple, Effective, Life Altering! by Avinash Kaushik presents methods to analyze your site search data to determine the intent of users. He uses Google Analytics in his examples, handy for so very many of us to see what is essentially a tutorial in practice.
3. Beyond Goals: Site Search Analytics from the Bottom Up by Lou Rosenfeld (who wrote up a case study on evolt.org in one of his books a few years back) addresses how a bottom-up analysis of site search data can provide valuable insight into user goals and behavior. He builds on the examples from the first two articles and ties them all together rather nicely.

Read More