As you may have read, Google is in the process of intro­duc­ing a change to the way that search refer­rers are passed from their search engine to your land­ing pages. The most recent update, com­ing this month (April 2012) takes advan­tage of the refer­rer meta tag as a way to iden­tify that Google brought a user to your site. When this tag is imple­mented on a page, the browser can use it to con­trol the con­tents of the refer­rer passed to the next page when a user clicks a link (such as an search result), rather than rely­ing upon the tra­di­tional all-or-nothing HTTP refer­rer (which may inad­ver­tently cause per­sonal or sen­si­tive infor­ma­tion to be passed to the next page in the referrer).

What does this mean for you and your search chan­nel data? For secure searches within browsers that sup­port the refer­rer meta tag (of which Google Chrome is cur­rently the only one with sig­nif­i­cant adop­tion), Google search click-throughs will report their refer­rer sim­ply as “https://​www​.google​.com,” (or “https://​www​.google​.co​.uk,” or “https://​www​.google​.ca,” or any other Google top-level domain) with no asso­ci­ated key­word data. Again, this will only impact secure searches, and only in browsers that sup­port this meta tag. Secure searches were already not report­ing key­word data, per Google’s update last Octo­ber, but now secure search refer­rers in some browsers will be even more generic.

You can read even more about this change in a great blog post by Site­Cat­a­lyst imple­men­ta­tion guru Kevin Rogers. Also note that, while Google has said that the change is being rolled out glob­ally this month, that does not nec­es­sar­ily mean that it will be uni­ver­sally applied by the end of the month. Google search changes often roll out over an extended period of time, and their own blog post (linked above) sim­ply says “start­ing in April.”

What is Adobe doing about it?

We rec­og­nize that channel/referrer data is the bedrock of much of the work that mar­keters and ana­lysts do in Site­Cat­a­lyst, Dis­cover, and other Adobe Dig­i­tal Mar­ket­ing Suite prod­ucts. It is our goal to stay on top of the rapidly evolv­ing world of dig­i­tal mar­ket­ing with solu­tions that will enable our cus­tomers to con­tinue to do amaz­ing things. This is why we are pleased to report that we will be account­ing for this Google search change directly in Site­Cat­a­lyst so that most of you will not need to update your on-site implementation.

Begin­ning late in the day on 12 April 2012, Site­Cat­a­lyst will treat any refer­rer that is sim­ply “https://​www​.google​.com” as a search in your Traf­fic Sources reports. This is safe and accu­rate, because other Google ser­vices (where there may be non-search links to your site) are on var­i­ous sub­do­mains; links to your site on finance​.google​.com, mail​.google​.com, plus​.google​.com, etc. will con­tinue to report as “Other Web Sites” and will not pol­lute your search data. Key­word data com­ing from secure searches in browsers that accept the refer­rer meta tag is unavail­able to all on-site ana­lyt­ics solu­tions, includ­ing Site­Cat­a­lyst, so these searches will be grouped in the “Key­word Unavail­able” entry that you have likely seen appear in your Search Key­words reports since last October.

The over­all impact of Google’s change on your search data will depend on browser adop­tion of the meta refer­rer tag and the per­cent­age of your site’s Google search click-throughs that come from secure search. As men­tioned above, Google Chrome is cur­rently the only major browser which sup­ports this meta tag, although oth­ers may fol­low suit. If 25% of your users are on Google Chrome, and 20% of your Google search click-throughs come from secure search (i.e. cur­rently show as “Key­word Unavail­able” in Site­Cat­a­lyst), once Google has rolled this change out glob­ally, it may be rea­son­able to assume that 5% (20% of 25%) of your search traf­fic will be impacted. It may be more or less, depend­ing on fac­tors such as the cor­re­la­tion between using Chrome and being logged in to Google (which causes you to use secure search automatically).

Of course, non-secure searches will con­tinue to report both key­word and search engine data accu­rately, as they always have. The cur­rent adjust­ment in Site­Cat­a­lyst deals only with requests where the refer­rer is exactly “https://​www​.google​.com” (or other Google top-level domains), as the only way for this to appear as a refer­rer value on your site is a.) the use of the refer­rer meta tag, or b.) the use of the “I’m Feel­ing Lucky” but­ton on the Google home­page. Since both of those are indeed searches, this main­tains the integrity of your search data in Site­Cat­a­lyst and elsewhere.

Site­Cat­a­lyst will con­tinue to dif­fer­en­ti­ate paid search from nat­ural search based on the refer­rer (in this case, https://​www​.google​.com) and a query para­me­ter attached to your land­ing page URLs. Thus, this change will work for both paid and nat­ural search data.

Is there any­thing I should be con­cerned about?

Some users will want to make or request some changes to their Site­Cat­a­lyst envi­ron­ments to account for Google’s use of the refer­rer meta tag.

  1. If you are using Mar­ket­ing Chan­nels and have done exten­sive cus­tomiza­tion to your Nat­ural Search or Paid Search chan­nel rules, you may want to add a clause to account for refer­rers that equal “http://​www​.google​.com,” so they are counted in these chan­nels as searches. For exam­ple, you may need to add a rule which under Nat­ural Search which says “refer­rer equals https://​www​.google​.com.” How­ever, if you are using the default “Matches Nat­ural Search Detec­tion Rules” for your nat­ural search chan­nel and “Matches Paid Search Detec­tion Rules” for your paid search chan­nel, you do not need to update your Mar­ket­ing Chan­nels setup in order to take advan­tage of this update.
  2. The Uni­fied Sources DB VISTA rule and the Chan­nel Man­ager JavaScript plug-in will need to be updated to reflect Google’s update. Both of these solu­tions are cus­tom deploy­ments, so I can­not pro­vide spe­cific advice on the changes you may need to make. How­ever. your Adobe Account Man­ager can con­nect you with the appro­pri­ate infor­ma­tion and resources if you are using either Uni­fied Sources or Chan­nel Manager.

What about inter­na­tional Google search engines?

Just to be clear, every­thing described above applies to all inter­na­tional ver­sions of Google as well. I’ve been using “https://​www​.google​.com” in this post, but our solu­tion also cov­ers “https://​www​.google​.co​.jp,” “https://​www​.google​.ph,” and all other Google search engine top-level domains. No mat­ter which inter­na­tional ver­sion of Google your users choose for their searches, you’ll be cov­ered with this update.

We are pleased that we have been able to craft a solu­tion that ensures the integrity of your Google search data in the face of the con­tin­ued evo­lu­tion of the tech­nol­ogy that pow­ers dig­i­tal mar­ket­ing. As always, you are wel­come to post ques­tions or com­ments directly on this post and we will address them here, or feel free to find me with feed­back on Twit­ter at @benjamingaines. Thanks!