Google Analytics Blog

I found this reference from Google's analytics blog (which documents the change in Referer:s that people should expect), which seems to argue that ot is right: this behavior has been in place since 2009.

http://analytics.blogspot.com/2009/04/upcoming-change-to-googlecom-search.html

(edit:) One of the comments from "Brett Crosby, Sr. Manager, Google Analytics" looks interesting:

"""Sorry for the delay in responding (especially Andre), I was seeking clarification from the search team. A lot of the comments were directed to them and I think it is best to let that team handle those questions. I do want to answer some of the Analytics questions though. Phil's comment above is correct. I posted this because a couple months ago Google tested some search results that added a # into the URL. This created a big problem for people interested in seeing which keywords were driving traffic to their site (anything in the URL after a # doesn't get passed in the referrer... this is particularly a problem for web analytics products), so we worked with the search team to stop that test until they could find a better solution. The announcement above is the answer to that. It allows them to test new search results without the negative side effects (if it introduced others, that was not the intent). Some of the other comments had interesting theories about why we did this (grassy knolls not included), but the goal was to allow new tests of search without making it difficult for analytics…

It's under Standard Reporting -> Content -> Site Speed

The GA code will track client side page load time (DOM fully loaded) across your site. You'll get site-wide averages and you'll also get to drill in on slow pages. This doesn't work for every single browser (last I checked it only worked for browsers that support HTML5), but it still provides a good sample size.

It's also important to do this as Google Webmaster tools dropped support of the Site Speed lab which shows you how fast Google thinks your site is ( <1.5 seconds user DOM load is considered faster, >= 1.5 seconds is "slow"). If you're trying to improve your Google ranking you need to be tracking how fast Google thinks your site is. (Also, fast websites are great for lots of reasons, not just Google ranking.)

See also: http://analytics.blogspot.com/2011/05/measure-page-load-time-with-site-speed.html

Can you actually point to a new part or dropped clause of the new policies that you're objecting to? Or did you just read the blog post and decide to share? Wariness is good, but innuendo does no one any favors (sorry, this sort of post really bugs me).

The analytics team continually repeats exactly out what they do with user data[1], and a two second search found the +1 button privacy policy[2]. Yes, they might be lying, but they probably wouldn't update the privacy policy then, would they?

There are no doubt concerns, but be specific.

Disclosure: I use Analytics on my site and pick apart every morsel of data in there that I can. Sorry.

[1] (they did it again today!) http://analytics.blogspot.com/2012/01/googles-updated-privacy-policy-what-it.html

[2] http://support.google.com/plus/bin/answer.py?hl=en&answer=1319578

Not for signed in users: http://analytics.blogspot.com/2011/10/making-search-more-secure-accessing.html

To help you better identify the signed in user organic
search visits, we created the token “(not provided)”
within Organic Search Traffic Keyword reporting. You
will continue to see referrals without any change; only
the queries for signed in user visits will be affected.
Note that “cpc” paid search data is not affected.

This will make it much more difficult to measure organic search marketing efforts, but for Google, this should encourage more investment in paid marketing campaigns to measure keyword effectiveness.

It's already difficult enough for humans to understand humans, so I wouldn't worry too much about this. What I do expect is that the least sophisticated parts of jobs like conversion optimisation will eventually become largely automated. Humans would still input the constraints, but the machine generates the inputs for a multivariate test, measures results, decides which variant performs best and rolls it out to all users.

Think The Grid [1] mashed up with Multi-armed Bandid Experiments [2]

[1] https://thegrid.io

[2] http://analytics.blogspot.nl/2013/01/multi-armed-bandit-experiments.html

I really liked the idea behind a product called Trendly (unfortunately it got shut down because Twitter bought the team).

They had some clever algorithms that simplified time series data from google analytics so that you could see at what points real changes occurred.

Some screenshots here:
http://analytics.blogspot.com.au/2009/08/api-integration-to-measure-significant.html

You can see how it's able to take something noisy like time series data and turn it into a stream of discrete events. It's really quite clever.