Google's New SSL Search

With SEO and Web Analytics, clearing up issues of "clear" vs. "secure," i.e. best practices for handling serving over HTTP vs. HTTPS protocols, has always been a touchy area. These are conditional matters with regard to not just correctly implementing Web Analytics software and serving web pages, but also handling sitemaps.xml and robots.txt files properly.

It just got more complicated. In case you haven't noticed, right now Google and Facebook are in a scrap over the issue of which one can position itself to appear less untrustworthy in the marketplace when it comes to matters of handling users' privacy. Off on the sidelines, other brands like Apple, Amazon and others are getting to watch and learn from whatever mistakes they might make, as they continue to grow their businesses online.

Google's latest move, within the past 48-72 hours roughly, has been the unveiling of SSL Search as available at It's in Beta, which I suppose helps excuse the glaring canonical issue of how doesn't redirect to it as of this writing. Also at the moment, their SSL Search is now coming to Chrome as an option.

The Guardian recently published a bit on how this "casts shadow on web analytics," also Danny Sullivan published an article examining how it might be the "Death of Web Analytics" wherein he admits that like many of us in this business, myself included, he blocks his own referrers from going outbound anyway.

in the wake of that and catching up with a bit of associated chirping in the Twittersphere, I spent a little time this morning digging into this. My take is basically that the sky isn't falling, but it sure is getting more cloudy. I ran a few tests using a super-simple criteria of trying to determine if, when users visit sites from Google, referrers would get stripped all of the time or just some of the time.

My checks worked like this (though I didn't test every combination as that wouldn't be applicable much):

  1. Secure (search) to Secure (URL)
  2. Secure (search) to Clear (URL)
  3. Clear (search) to Secure (URL)
  4. Clear (search) to Clear (URL)

I hit a few different sites using FireFox with WASP enabled, visiting some of my favorite local peeps (South Beach posse in da hooouuusssee!) to see how various publishers' installations of packages like Google Analytics, Omniture and Webtrends responded. Being that I know offhand that they're among a number of sites that currently use a mix of HTTP and HTTPS on their domain, I also added in Lending Club's site to this morning's survey.

Understanding the responses:

  • In OMTR, when a referrer is passed it'll appear as "referrer (r)" under "Traffic Source" whereas if it's not passed it won't appear.
  • In GA, the referrer variable is "Referrer (utmr)" under "Content". When a referrer is not passed, it will appear but its value will show as "-".
  • In WebTrends, the referrer variable is "dcsref" under "SDC-Parameter Override." When a referrer is not passed, it won't appear.

Some screen captures, wherein when possible, I've highlighted captured referrers as well as their keyword portions:

Test A:

Subject: AKQA; Clear (search) to Clear (URL)

Test B:

Subject: AKQA; Secure (search) to Clear (URL)

Test C:

Subject:; Secure (search) to Clear (URL)

Test D:

Subject: Expensify; Secure (search) to Secure (URL)

Test E:

Subject: Lending Club; Secure (search) to Secure (URL)


So there you have it. As you can see, sites who are already serving all their pages on HTTPS don't have anything new to worry about, seemingly. If you're in this situation, you should still be able to pick up Search visitors' referring engines and keywords details as you always have.

If you're not in this camp though, think about how all this might take a chunk of visibility away from your Web Analytics. For companies whose business relies significantly on referrers hand-off, i.e. market analysis providers, this looks like a can of worms. For publishers and webmasters whose direct concerns are more just on the sites they own and manage, there are some more controllable things they can do to minimize how disruptive this change needs to be.

Up until this point I held the position that defaulting to HTTP, and using HTTPS only if/as really needed in select areas of a given site, was the best thing to do. I'm not so sure I do anymore. Back then that was at least partly on behalf of avoiding potential impairment of select 3rd-party services, e.g. Alexa etc. ... but if SSL Search starts to get wired into more and more places and starts to look increasingly pervasive... well, forget that. Situations where everyone needs to focus on retooling their own stuff to roll as much as possible with disruptive change, they are what they are.

I also think all this stuff about the potential demise of the referrer... the whole idea of it does spoil some of the fun, as far as occasionally pushing snarky fake stuff into competitors' logs like "" goes.

Ha ha, I kid you! I'm a kidder...

Spread His Word

    About this entry