How to: Finding Google Secure Search Data in Different Web Analytics Platforms
–Skip this section if you are aware of Google Secure Search change–
Google forcing logged-in users to use secure search should not be news to you, but here is the link anyways – Making search more secure. Additionally by now you should have read about how Google Analytics is going to be treating secure searches, but here is the link anayways – Making search more secure: Accessing search query data in Google Analytics
— Start here if you are aware of Google Secure Search change —
Bummer, now what?
As SEOs we just happen to work in an environment that forces us to adapt on a fairly consistent basis. Google has delivered another stiff left jab that we HAVE TO roll with because it is just outside of our control. Now that you have come to terms with the change (hopefully) and know that it is not going anywhere, what are you going to do about it? Well, the only thing you can do… dig into your analytics, find out where you can find secure search data, monitor it and account for it.
So, below you will find a variety of popular analytics platforms and how you will (or will not) be able to account for this new segment of search traffic.
The good news is Google Analytics was prepared for this change (shocker! I wonder why?). So, if you are using Google Analytics you can easily find all the traffic coming from logged-in users through secure search neatly rolled up into a new universal token in the Organic Search Traffic report called “(not provided)”. It cleanly allows you to see the impact of secure search starting October 18th and when you filter the Organic Search Traffic report by (not provided) you should see something like this –
Now for the other analytics platforms that don’t start with Google…
Adobe – Omniture
If you are using Omniture as your web analytics platform the good new is you will be able to find secure search data but you have to math and dig a bit deeper. Even better, Omniture has put together instructions on how to find the data so here you go:
1. Run the Traffic Sources > Referrers report using the Instance metric
2. Select the current day in the date selector
3. Filter the report to show referrers from major search engines by adding this to the search box: google.com/search OR google.com/url OR search.yahoo.com OR bing.com.
– Add non-US domain endings, like google.co.uk, where appropriate
– Don’t forget to capitalize the OR operator
– In SiteCatalyst 14, this search may take a few minutes
4. Note the total in the bottom-right corner of the page (I drop it into Excel, but your memory may be better than mine)
5. Filter the report to encrypted search referrers by searching for google.com/url AND q=& (again, capitalization matters for the AND operator)
6. Divide the second total by the first to estimate the change to total search traffic caused by encrypted search.
Find these instructions on the Omniture blog here – The Impact of Google Encrypted Search
Also, the update will impact a few of the standard reports in Omniture like:
– Referrer Types: Search Engine traffic will decrease in favor of traffic for “Other Web Sites”
– Search Keywords (All, Paid and Natural): Metrics associated with keywords will decrease in favor of “None.”
– Search Engines (All, Paid and Natural): Metrics associated with Google search engines will decrease in favor of “None.”
The teams over at IBM also took the time to put together a blog post about the change, you can read it here – Google Making Search More Secure. But, let me summarize it for you…
1: “We applaud Google for wanting to make the user experience safer.” – direct quote (I almost threw up, no wait… I did)
2: “Unfortunately, no work around has been provided by Google; therefore, this is a matter that will impact all vendors that leverage this traditionally vital information.” – direct quote (Bummer. Again.)
3: “They totally just f**ked us!” – direct quote (j/k, but I wish they had said this, right?)
Looks like the Coremetrics and Unica teams are under the gun a bit to figure out how their analytics platform is going handle this source of traffic (or ever will) and display in a meaningful manner. For the time being it looks like Coremetrics users might be SOL with IBM saying, “you will likely see a substantial increase in no search results or “None.””
Webtrends, also on top of the analytics game, prepared a blog post on the secure search change, you can read it here – Our Response to Google’s Query String Security Announcement. However, their post is even less helpful than Coremetrics’ for the users of their analytics platform with only telling users that, “Webtrends products will continue to operate as expected, with affected traffic appearing as Google referred but without any search results”. They also go on to say that they “will provide an update in the near term that will clearly identify those searches that had the terms stripped out”.
Webtrends also did a bit of brown-nosing by saying, “We applaud the importance Google places on security and privacy”.
So hold tight Webtrends users something will eventually be coming down the pipeline from the sounds of it.
Yahoo! Web Analytics
No blog post from the Yahoo! Web Analytics team on the impact of the secure search change in Google on data in their platform. If anyone is using Yahoo! or someone from the Yahoo! team is reading this contact me.
Since there was no publicly available comments from Clicky on the topic, I took the initiative and emailed them about how their platform would handle the change and here is what I heard back:
“When Google started doing the Ajax thing about 2 years ago, this had a similar effect although on a much smaller scale. We could still detect they were coming from Google, so that was reported – the search term would just be blank for that visitor because we couldn’t access it. This new change is just like that, but times a billion. It will affect the majority of searches, I’m guessing (but not all, since it only applies to logged in users).
There is no workaround.”
So, sounds like business as usual at Clicky where the new Google secure search data will be recorded that same way as Ajax data.
No blog post from the Woopra team on the impact of the secure search change in Google on data in their platform. If anyone is using Woopra or someone from the Woopra team is reading this contact me.
Again, taking the initiative here – I emailed some of the team at Piwik to see how they were going to handle the change by Google. I got a response stating that there would be a fix in the next release, check out the ticket – Google search SSL by default for default users cause keyword not to be tracked
So, for Piwik users keep eye out for the next release as you will start seeing Google secure search traffic showing up as “keyword not provided” in your reports.
Great job Piwik!