heartsWe just passed February and with it a Valentine’s Day holiday. With love in the air I was reminded about one of Shakespeare’s plays, Much Ado About Nothing, where two sets of lovers face contrasting situations. One couple is tricked into confessing their love, while another is tricked into rejection at the altar. This got me thinking about the two contrasting ways analysts are dealing with the love/hate relationship they have using Google secure search results referrer data. Not following my analogy? Well, let me explain.

In October 2011 and again in March 2012, Google announced that they were rolling out changes to the way they pass the referrer when a visitor clicks through secure search results. These changes would strip the search terms and other personal information from the referrer before it is passed along to the resulting site. To be clear, a secure search is one performed on https://www.google.com (or equivalent international top-level domains). Either signed-in or unauthenticated users can access it, and it often becomes the default setting (but not always, as I’ll explain) when you are logged in to your Google account.

Following those announcements and their implications, there was a ripple of shock and discussion throughout the analytics community.  That frustration is well understood. Tracking search terms and channel data are very standard techniques, and analyzing those terms is one of the few opportunities to see what a visitor is actually looking for, in their own words. Losing access to that data immediately became a top concern for analysts everywhere.  Furthermore, many users unfamiliar with Google’s changes suddenly became worried that their analytics implementation was somehow broken and no longer tracking search terms correctly. Others, becoming disillusioned with an incomplete data set threw their hands in the air and dismissed their search terms report as useless.

You might say that some felt tricked into rejecting a data set they were previously in love with.

There are a several key questions that need answering in order to make sense of these changes and how they affect your data.

1. How is Google passing the secure referrer along?

Up until certain points in time (October 2011 & April 2012), Google did not treat secure searches differently than non-secure. Starting on those dates, the changes were rolled out and would directly affect the availability of search terms to analytics and optimization tools. Any data spanning those date could provide mixed results. It is also important to note that Google did not implement the changes universally nor all at once. On top of all that, they could change again in the future, introducing additional tweaks and consequently changing the availability of search term data yet again.

2.  What is your browser’s current version doing with that secure referrer?

With any newly introduced feature, there can be a lag from related and supporting tools as they “catch up” and respond to the change.  Such is the case for browsers and their ability to interpret or respect Google’s secure search referrer.  In Google’s own words, “browsers with the appropriate support” or “a modern browser” will benefit from the changes. What this means in reality is a pretty mixed bag as I will demonstrate.

A click-through on a non-secure search result in most major browsers will pass a referring URL including the search term in the &q= query parameter (I searched for “adobe” in this example):us-ff

 

Similarly, a typical secure search in Safari, Firefox, and Internet Explorer will strip the search term ( &q= ) from the referring URL (and oddly changes the protocol to http):ss-ff

 

But not every browser reacts in the same way, and this is where things get interesting.

A secure search using Google Chrome will strip all query parameters from the referring URL. The resulting URL will not contain an empty &q= or other parameters at all, which could be problematic as we’ll see in the next section.

ss-chrome

 

Safari (desktop & mobile) and mobile Chrome on iOS6, were the only browsers that allowed me to be both authenticated and unsecure. The other browsers forced https while I was logged in to my Google account.

ss-safari

Finally, and maybe the most difficult scenario to deal with of them all, secure search in Safari on iOS6 does not pass a referrer at all!! This clouds the situation even further as this traffic will then be categorized as “direct/bookmarked” instead of “search engine”. There are simply no indicators in this situation that tracking tools like SiteCatalyst could use to determine that the traffic was from Search.

 

3. What are you doing in your SiteCatalyst s_code, Marketing Channel, or processing rules with that secure referrer passed by the browser?

In response to the lack of search terms in the referring URL, many rushed to write plugins, add processing rules, or take other measures to account for this traffic appropriately. While these attempts should applauded, a misunderstanding of the answers to the questions above could lead to misapplication of any categorization.

 

 4. And finally, how does SiteCatalyst process and interpret that data passed by your code?

Ben Gaines, one of the Adobe Analytics product managers, does a masterful job explaining how SiteCatalyst is currently handling the secure search situation in this blog post from last April. Check that out and enjoy!

 

 

 

0 comments