Lies, Damned Lies...

Wading into the Google Secure Search fray

There’s been quite the hullabaloo since Google announced last week that it was going to send signed-in users to Google Secure Search by default. Back when Google first announced Secure Search in May, there was some commentary about how it would reduce the amount of data available to web analytics tools. This is because browsers do not make page referrer information available in the HTTP header or in the page Document Object Model (accessible via JavaScript) when a user clicks a link from an SSL-secured page through to a non-secure page. This in turn means that a web analytics tool pointed at the destination site is unable to see the referring URLs for any SSL-secured pages that visitors arrived from.

This is all desired behavior, of course, because if you’ve been doing something super-secret on a secure website, you don’t want to suddenly pass info about what you’ve been doing to any old non-secure site when you click an off-site link (though shame on the web developer who places sensitive information in the URL of a site, even if the URL is encrypted).

At the time, the web analytics industry’s concerns were mitigated by the expectation that relatively few users would proactively choose to search on Google’s secure site, and that consequently the data impact would be minimal. But the impact will jump significantly once the choice becomes a default.

One curious quirk of Google’s announcement is this sentence (my highlighting):

When you search from https://www.google.com, websites you visit from our organic search listings will still know that you came from Google, but won't receive information about each individual query.

This sentence caused me to waste my morning running tests of exactly what referrer information is made available by different browsers in a secure-to-insecure referral situation. The answer (as I expected) is absolutely nothing – no domain data, and certainly no URL parameter (keyword) data is available. So I am left wondering whether the sentence above is just an inaccuracy on Google’s part – when you click through from Google Secure Search, sites will not know that you came from Google. Am I missing something here? [Update: Seems I am. See bottom of the post for more details]

I should say that I generally applaud Google’s commitment to protecting privacy online in this way – despite the fact that it has been demonstrated many times that an individual’s keyword history is a valuable asset for online identity thieves, most users would not bother to secure their searches when left to their own devices. On the other hand, this move does come with a fair amount of collateral damage for anyone engaged in SEO work. Google’s hope seems to be that over time more and more sites will adopt SSL as the default, which would enable sites to capture the referring information again – but that seems like a long way off.

It seems like Google Analytics is as affected by this change as any other web analytics tool. Interestingly, though, if Google chose to, it could make the click-through information available to GA, since it captures this information via the redirect it uses on the outbound links from the Search Results page. But if it were to do this, I think there would be something of an outcry, unless Google provided a way of making that same data to other tools, perhaps via an API.

So for the time being the industry is going to have to adjust to incomplete referrer information from Google, and indeed from other search engines (such as Bing) that follow suit. Always seems to be two steps forward, one step back for the web analytics industry. Ah well, plus ca change…

Update, 10/25: Thanks to commenter Anthony below for pointing me to this post on Google+ (of course). In the comments, Eric Wu nails what is actually happening that enables Google to say that it will still be passing its domain over when users click to non-secure sites. It seems that Google will be using a non-secure redirect that has the query parameter value removed from the redirect URL. Because the redirect is non-secure, its URL will appear in the referrer logs of the destination site, but without the actual keyword. As Eric points out, this has the further unfortunate side-effect of ensuring that destination sites will not receive query information, even if they themselves set SSL as their default (though it’s not clear to me how one can force Google to link to the SSL version of a site by default). The plot thickens…

Nicely executed retargeting opt-out (for a change)

Retargeting (sometimes called remessaging or remarketing) has taken off in a big way, recently – Google introduced the feature into AdWords earlier this year, and a host of other players are in the game. Consequently, the interwebs now abound with commentary on the rather spooky nature of the technology, with people being “followed around” the Internet by ads for things they were either searching for, or were looking at on e-commerce websites.

It is true that most retargeting implementations are a bit clunky, and I have been on the receiving end of plenty of them myself. Their most irritating aspect seems to be that the time window for perceived relevance of the retargeted ads seem to be ridiculously long. It’s somehow almost more irritating to be deluged by ads for that miscellaneous widget site that you once visited a few weeks ago (even though you have since satisfied your need for widgets elsewhere) than it is to be served non-targeted (or more broadly targeted) ads.

Such ads are made more bearable by a robust opt-out capability; many ad networks have adopted the IAB’s self-regulatory program, which calls for the advertiser to make it possible to opt out of these kinds of ads, which is to say, stop receiving them; stopping the data collection is a more difficult matter.

So today I want to give a little love to TellApart, not because their retargeting implementation is especially subtle or innovative, but simply because they provide a nice opt-out implementation. Last week I spent a little time looking for a desk for my daughter (who currently occupies our dining table with her homework). So since then I have been served retargeted ads on behalf of the site I visited (www.childrensdesks.com) on various sites. Here’s one from Business Insider:

The nice thing about the ad is it has a little “x” icon in the top right (which actually makes a little more sense than the IAB’s suggested “Advertising Option Icon”, which is a bit cryptic). Clicking it gives me this:

The ability to opt out right in the ad unit is nice, and makes me feel more well-disposed to the advertiser and the site that the ad is running on. Clicking through the “Learn More About These Ads” link at the bottom takes me to TellApart’s website with a little more information and the same option to opt out – though no option to opt out of certain categories of ads, or groups of advertisers.If more retargeting networks provided simpler opt-out capabilities like these, it might help to make these ads seem like less of a scary proposition.