At some stage during May this changed and some older syntax will not work in certain query combinations.

Until recently, the following combinations would all work fine and produce the same results:

1. source==google&&medium==cpc
2. ga:source==cpc&&ga:medium==cpc
3. source==google;medium==cpc
4. ga:source==google;medium==cpc

However, recently support for && was dropped so you now must use ;.

!Now here's the fun part:

ga: is no longer optional in combined queries, it is required. So (3) will not work. However, it is still optional in single parameter queries. Thus:

source==google will work exactly the same as ga:source==google, but if you combine parameters, ga: becomes required.

This humble post is offered to those of you who, like me, have old code still in use. I hope to save you the three hours of debugging it took me to work out what was wrong with code which had worked perfectly till now.

My thanks to Steve Whittle of Displaysense (www.displaysense.com) who helped me with this when I got stuck in a blind alley. Sometimes you can get your head too close to the code...

END OF TECHIE STUFF, START OF RANT:

I guess someone in Google Analytics is tinkering with the code for processing multiple parameters, and has removed the old code for handling older syntax. While I have immense respect for the work Google do in bringing great products to us for nothing, I have to say this is typically shoddy development management. We now have different components of the same product with competing syntax rules, and no version history or similar documentation to help poor developers like me who write applications which use the API.

I've strongly suspected for many years no one in Google is supervising Google Analytics development properly, that each coder can pretty much do their own thing, because the product is riddled with processing inconsistencies. This is exactly the sort of instance which proves it. I'm not blaming the person who made this change, they simply followed the spec as it is now. I'm blaming their management, who have obviously either failed to document the code and development procedures properly, or don't bother to ensure their coders follow such documentation (if it exists). If you're a technical manager at Google, please go read up on something called version control - you obviously skipped or slept through those lectures in Computer Science 101.

If you want to build applications which people use, and if you want developers to build systems which interact with these applications, you can't make changes at any time and without documentation and prior warning. You need to make changes by the version. That means you roll out one version of the product and leave it alone. You then roll all improvements into the next version. You warn people in advance the next version is coming at a specified date, and you tell them what the changes will be. Ideally, you also maintain backward compatibility for a specified period of time or run both versions in parrallel for a while. This means developers can plan/budget updates to their systems, make those changes in a controlled fashion, and generally walk in parrallel with you.

Google may have just broken a large number of commercial applications which plug into the Google Analytics API. The first thing anyone knows about the change is when their systems fail or their clients start screaming at them because they can't compile their monthly reports.

If Google were just dumping freeware into the marketplace, this would still be shoddy work, but less of an issue. However, they encourage commercial development on the Google Analytics API platform, they even promote companies which do so. People who do this become their partners in a joint business, even if there's no contract in place. This gives Google a moral obligation to communicate to their partners, and a commercial incentive to do so. How can you expect people to partner with you if you ignore them and break their systems. Saying the product is free is no justification for sub-standard work.

In my experience, Google are filled with bright minds doing amazing things. They're certainly one of the leading developers of web apps today. But time and time again, they demonstrate they know almost nothing about being part of a development ecosystem - about technical communication or how to support development partners. There's really no excuse for it, this isn't rocket science. You only have to look at how other companies which are embedded into development ecosystems work to see what needs to be done. Can you imagine Oracle changing the syntax in their databases without warning people in advance or documenting the change? Or Sun making undocumented changes inside Java without warning, or even so much as changing a sub-version number? Even self-organised open source development runs through version releases, with change documentation. It looks like everyone can get it right except Google. What's wrong with the people at Google? What wierd cult of corporate introspection makes it so hard for Google employees to recognise they exist in a world which is bigger than them, and that they need to interact with?

Corporate arrogance seems to be a feature of dominating IT companies. IBM were famous in the 1970's and 1980's for pushing people around and poor corporate relations. They could get away with it because there were few alternatives. Netscape were the same in the early years of the web, and Facebook look like they may have a similar problem. On the few occassions I've met with people from IBM/Netscape/Google etc I've found that they seem to think their dominating position is due to the fact they're all special (superior) human beings, and that their future is therefore assured. In reality they have domination because they had the right products at the right time, and their future is only assured while the market needs remain the same and while there are no alternatives. There's no such thing as loyalty here. The instant there's an alternative which offers better relations, people will grab it. Getting to the top is much, much easier than staying there.

Long term survival in business is not about products, it's about relationships.