heartsWe just passed Feb­ru­ary and with it a Valentine’s Day hol­i­day. With love in the air I was reminded about one of Shakespeare’s plays, Much Ado About Noth­ing, where two sets of lovers face con­trast­ing sit­u­a­tions. One cou­ple is tricked into con­fess­ing their love, while another is tricked into rejec­tion at the altar. This got me think­ing about the two con­trast­ing ways ana­lysts are deal­ing with the love/hate rela­tion­ship they have using Google secure search results refer­rer data. Not fol­low­ing my anal­ogy? Well, let me explain.

In Octo­ber 2011 and again in March 2012, Google announced that they were rolling out changes to the way they pass the refer­rer when a vis­i­tor clicks through secure search results. These changes would strip the search terms and other per­sonal infor­ma­tion from the refer­rer before it is passed along to the result­ing site. To be clear, a secure search is one per­formed on https://​www​.google​.com (or equiv­a­lent inter­na­tional top-level domains). Either signed-in or unau­then­ti­cated users can access it, and it often becomes the default set­ting (but not always, as I’ll explain) when you are logged in to your Google account.

Fol­low­ing those announce­ments and their impli­ca­tions, there was a rip­ple of shock and dis­cus­sion through­out the ana­lyt­ics com­mu­nity.  That frus­tra­tion is well under­stood. Track­ing search terms and chan­nel data are very stan­dard tech­niques, and ana­lyz­ing those terms is one of the few oppor­tu­ni­ties to see what a vis­i­tor is actu­ally look­ing for, in their own words. Los­ing access to that data imme­di­ately became a top con­cern for ana­lysts every­where.  Fur­ther­more, many users unfa­mil­iar with Google’s changes sud­denly became wor­ried that their ana­lyt­ics imple­men­ta­tion was some­how bro­ken and no longer track­ing search terms cor­rectly. Oth­ers, becom­ing dis­il­lu­sioned with an incom­plete data set threw their hands in the air and dis­missed their search terms report as useless.

You might say that some felt tricked into reject­ing a data set they were pre­vi­ously in love with.

There are a sev­eral key ques­tions that need answer­ing in order to make sense of these changes and how they affect your data.

1. How is Google pass­ing the secure refer­rer along?

Up until cer­tain points in time (Octo­ber 2011 & April 2012), Google did not treat secure searches dif­fer­ently than non-secure. Start­ing on those dates, the changes were rolled out and would directly affect the avail­abil­ity of search terms to ana­lyt­ics and opti­miza­tion tools. Any data span­ning those date could pro­vide mixed results. It is also impor­tant to note that Google did not imple­ment the changes uni­ver­sally nor all at once. On top of all that, they could change again in the future, intro­duc­ing addi­tional tweaks and con­se­quently chang­ing the avail­abil­ity of search term data yet again.

2.  What is your browser’s cur­rent ver­sion doing with that secure referrer?

With any newly intro­duced fea­ture, there can be a lag from related and sup­port­ing tools as they “catch up” and respond to the change.  Such is the case for browsers and their abil­ity to inter­pret or respect Google’s secure search refer­rer.  In Google’s own words, “browsers with the appro­pri­ate sup­port” or “a mod­ern browser” will ben­e­fit from the changes. What this means in real­ity 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 refer­ring URL includ­ing the search term in the &q= query para­me­ter (I searched for “adobe” in this example):us-ff


Sim­i­larly, a typ­i­cal secure search in Safari, Fire­fox, and Inter­net Explorer will strip the search term ( &q= ) from the refer­ring URL (and oddly changes the pro­to­col 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 para­me­ters from the refer­ring URL. The result­ing URL will not con­tain an empty &q= or other para­me­ters at all, which could be prob­lem­atic as we’ll see in the next section.



Safari (desk­top & mobile) and mobile Chrome on iOS6, were the only browsers that allowed me to be both authen­ti­cated and unse­cure. The other browsers forced https while I was logged in to my Google account.


Finally, and maybe the most dif­fi­cult sce­nario to deal with of them all, secure search in Safari on iOS6 does not pass a refer­rer at all!! This clouds the sit­u­a­tion even fur­ther as this traf­fic will then be cat­e­go­rized as “direct/bookmarked” instead of “search engine”. There are sim­ply no indi­ca­tors in this sit­u­a­tion that track­ing tools like Site­Cat­a­lyst could use to deter­mine that the traf­fic was from Search.


3. What are you doing in your Site­Cat­a­lyst s_code, Mar­ket­ing Chan­nel, or pro­cess­ing rules with that secure refer­rer passed by the browser?

In response to the lack of search terms in the refer­ring URL, many rushed to write plu­g­ins, add pro­cess­ing rules, or take other mea­sures to account for this traf­fic appro­pri­ately. While these attempts should applauded, a mis­un­der­stand­ing of the answers to the ques­tions above could lead to mis­ap­pli­ca­tion of any categorization.


 4. And finally, how does Site­Cat­a­lyst process and inter­pret that data passed by your code?

Ben Gaines, one of the Adobe Ana­lyt­ics prod­uct man­agers, does a mas­ter­ful job explain­ing how Site­Cat­a­lyst is cur­rently han­dling the secure search sit­u­a­tion in this blog post from last April. Check that out and enjoy!