Of course this could be read another way: How Google's poorly thought out Analytics code cost a company $500k/year.
Whenever you plug somebody else's code into your site, you're taking a risk. Try browsing the web with your browser set to pop up warnings on every javascript error, and you'll see how bad most of the scripts people plug into their site really are.
You can also spin it as the customer not keeping updated with the latest code that fixes known issues. How much can you really blame Google on customers using years-old code?
Indeed. That's the point I was trying to make. It's not an issue of whether it's Google's fault that the company didn't update their tracking code. It's the fact that when you start integrating 3rd party stuff into your codebase, it suddenly becomes your job to keep on top of every one of those plugins to make sure they stay working.
I don't see any reason why Google couldn't add to their javascript tracking code the ability to detect if a non-SSL script sits on an SSL page. They would then flag it in the analytics control panel. Whoever is monitoring analytics could spot it right away rather than waiting for their consultant to point it out months later.
Pretty amazing that sites with such high daily revenue (close to UK 7000/day, just for IE) either weren't testing their checkout process in IE or didn't ever wonder "gee why am I getting this 'insecure content' popup and how can it be fixed?".
As mentioned at the bottom of the article -- if you click "yes" on the popup -- then you only got the secure data -- and didn't get the analytics code. And that quite possible 70% of the users did just that.
Ensuring that Google analytics downloads the js script using https on websites that are themselves https served in order to prevent IE8 visitors from getting a security warning.
Discusses segmentation in GA and some other issues too along with the general concept of checking conversion rates for different classes of visitor.
Probably their QA got fired after this event. Who knows? Seriously though I am amazed how can such companies remain to exist. I am amazed at how trivial this error is.
On another note. The payment processor we use (2checkout) have an error in their checkout page where they ask PIN code but explicitly point out _Only required for US customers_ but in reality it is needed for ALL customers. Raised this bug two months ago, they acknowledged it and it is still not fixed. I'm furious at this but based outside US I have little or no option to switch.
I doubt it. I have seen many QA staff at a variety of companies get so used to IE's various oddities that over time they will simply stop opening some kinds of bugs against the site on IE, even perfectly legitimate bugs like that in the article. All it takes is for product management to punt mixed content warning bugs during a few releases before QA also stops reporting them. If someone does later bring one up, over time it evolves into "Oh, that's an IE thing we can't fix." These are smart people doing generally diligent work, but they do tend to get worn down around IE.
I can't say for sure why this happens but I've seen it most with IE mixed content warnings.
Isn't it just as likely that people were still ordering but clicking "Yes" to the remove insecure content option? This would mean the orders still came through but Google Analytics wasn't getting called and recording them.
I mean, that's pretty much what I inferred given the nature of the title. Since you usually only tell part of a story with a title, I felt that this one was sufficiently genuine. They could have deflated it a bit by saying "How I increased a client's revenue by X% with one change."
Whenever you plug somebody else's code into your site, you're taking a risk. Try browsing the web with your browser set to pop up warnings on every javascript error, and you'll see how bad most of the scripts people plug into their site really are.