Marketers are starting to hear a new “giant sucking sound.” It’s the sound of vital iPhone and iPad search data being taken from their analytics with each new installation of iOS6.
This development was uncovered here and discussed at Search Engine Land. What’s happening affects iOS6 Safari browsers that have Google as the default toolbar search engine. Those toolbar queries are getting routed through Google’s SSL secure search site.
This strips the referring site URL (that being Google) and keyword data from all iOS6 search sessions before the mobile user ever hits the marketer’s site. Here is an example of what an iPhone / iOS6 Google searcher now looks like in site log files:
188.8.131.52 – – [28/Sep/2012:07:27:11 -0600] “GET / HTTP/1.1” 200 24826 “-” “Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25”
Notice the blanked out “-” field? This is the referring URL field. It usually contains the referring URL (like http://google.com) and the Google query string that contains the search terms used to find the site. This is what populates site analytics. Or used to. Not any more…
Google introduced a similar feature in September 2011 for securing desktop searchers who are logged into Google – to the consternation of all SEOs. (It’s the reason search analytics now show “not provided” search terms. Read more here and here.)
Shortly after, I noted that mobile queries were not being “secured” by Google, as evidenced by the fact that keyword data from Android and iPhone queries continues to stream into site analytics.
So when news hit this week that iOS6 search traffic gets stripped of referrer data, my first instinct was to conclude Google may be getting serious about securing mobile search privacy at last.
If that’s true, the impact will be swift, significant, and permanent: 100 million users have adopted iOS6 in the past week with 60% of iPhones are now running it. As iOS6 installations increase, mobile search traffic from Google will get reported as “direct” traffic without a “referrer” and without search terms.
Bottom line: This means iPhone and iPad searchers may be finding and clicking your search listings from Google. You just won’t know about it – because you can’t.
Here’s what’s puzzling: Why would Google’s first foray into mobile search privacy start with iOS6? Google owns Android. Most Android searchers are logged into Google when they search. Why isn’t Android search privacy “secured” to the same level iOS6 privacy is secured?
This typical log file shows what gets recorded when a non-logged-in Android user clicks on a Google listing:
184.108.40.206 – – [28/Sep/2012:06:52:31 -0600] “GET / HTTP/1.1” 200 24521 “http://www.google.com/search?hl=en&client=ms-android-verizon&source=android-home&sky=rndy&site=webhp&source=hp&q=pure+oxygen&oq=&gs_l=mobile-gws-hp.1.1.41l220.127.116.11.6218.104.22.168.3.1..0.0.les%3B..0.0…1ac.” “Mozilla/5.0 (Linux; U; Android 2.2.3; en-us; Droid Build/FRK76) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1”
The string “http:///www.google.com/” is still visible, as is the resulting query (“q=pure+oxygen”). It suggets Google is not stripping referrer data from anonymous Android searchers.
What about when logged-in to Google? Here’s a site log file showing a logged-in Android user clicking a Google listing:
22.214.171.124 – – [28/Sep/2012:06:55:18 -0600] “GET / HTTP/1.1” 200 24224 “http://www.google.com/search?hl=en&client=ms-android-verizon&sky=rndy&site=webhp&q=pure+oxygen&oq=pure+oxygen&gs_l=mobile-gws-serp.3…0.0.0.42126.96.36.199.0.0.6.0.0.0.les%3B..0.0…1ac.55rN76miudn0” “Mozilla/5.0 (Linux; U; Android 2.2.3; en-us; Droid Build/FRK76) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1”
Not very different. Even the history of the search query is preserved in the “q=” and “oq=” parameters. (The type of thing Google wanted to make private with the introduction of secure search.)
Clearly Google search privacy on Android is not “secured” (logged-in or not), let alone to the same degree iOS6 searches now are. So it hardly seems reasonable that Google would increase their commitment to search privacy – by securing their archrival’s platform first to the exclusion of their own.
According to new information, Google now claims Apple programmed the iOS6 Safari toolbar to send Google queries through Google’ secured SSL search. In that case, maybe we can expect this change to be reversed soon, and Google mobile search data to once again stream freely into our analytics.
Even so, I see a very limited future in that possibility. I think Google will (must?) eventually make mobile search data private. The result will look exactly like what’s being publicized today: more consumer privacy; less mobile search data.