It was a spring morning in 2012 when I pulled open Google Analytics for a client to run a regular report only to see the worst: Sales dropped off a cliff. Not to zero, but way down. “What happened?!” I went through acquisition reports and saw declines across the board: organic search sales, paid search sales, affiliate sales, referrals, everything that reliably produced sales was 20-30% lower with no explanation. I reported the findings to the client, who was understandably distraught. Nothing significant changed on their end in messaging. It’s like someone flipped a switch and POOF!

I spent hours looking through pageview reports, conversion variances, but no clear sign as to why everything was down across the board. Then it hit me:

We’re not tracking every page. There is a critical page that had no tracking code on it whatsoever and therefore could never show in the reports: The 404 page.

When you have a link to a page that doesn’t exist, the site will return a 404 error that we’ve all seen before. However, by setting up a HTML page that acted as the 404 page we could include analytics code and see what page referred the 404. That’s where the error was. Ah ha!

It worked! After a couple days of data we saw a surge of 404 referrals from a specific page and knew that pesky page linking to the shopping cart was our culprit, but then something even more unusual happened: there was no error. We checked every link and all worked as intended. Why were sales still down?! Why is there a surge of 404s when the links all work?! That’s when I had my second Eureka moment: the error only happened during busy periods.

See, way back in 2012 websites live on actual servers instead of AWS, Azure farms, or other virtual machines, and if servers got too busy they’d crash. People would often daisy-chain several severs together that all had copies of the website to serve to users as traffic increased using various load balancing techniques. This company ran the website from one primary server, but at busy times a second server would jump in and take on some of the load. Realizing the errors occurred during busy periods is when we thought to check those links on the second server and voila! Dead link to shopping cart right where we expected. Fixing the link brought sales back to pre-error levels. The sales impact was higher than the server’s load because the backup server was getting more of the traffic during the busy times, blocking lots of people from completing their transaction.

What happened was an update pushed to the main server didn’t get pushed to the backup server, meaning the backup server was running an older version of the website. Although most sites today aren’t setup like they were in early 2010s, we have stuck to our practice of always putting analytics tracking on error pages and using it as a first-step in debugging possible issues.

Have you seen similar issues in your analytics? Schedule a call and we can assess your implementation to ensure you are tracking what you think you’re tracking, and help find any unseen gaps that could be hiding insights.