The Case of the Tags That Said Too Much

June 26, 2014 Alan Feuerlein

Our favorite thing to do here is solve challenging problems. This is a story of one particularly prickly problem with a not-so-obvious solution. This case started out like many do—an inbound support inquiry about why our audit report indicates that tags are missing on pages, but manual checking with a browser-based tools, like TagDebugger™, clearly show the network request and tag.

There are lots of good reasons why this might happen. But to give you the tl;dr early, the issue turned out to be that the tag request size on many of the site’s pages, including the home page, was too large. It didn’t happen every time, but in certain end-client/network environments, it caused complete data loss.

Internet-based data collection isn’t a perfect science, and we’ve known for a long time that the mysterious land of servers and IT infrastructure we call the cloud can be a minefield of problems. What a great name—cloud. Sometimes it’s white and puffy, sometimes it’s dark and dense, but other times it’s nowhere to be found and sometimes it’s dark and mean. Seems appropriate. But I digress.

The bottom line is, the cloud falls outside the realm of digital marketers’ normal testing and integration responsibilities, so diagnosing problems can be a real quandary.

Byte Length Matters

If you’re of the technical persuasion, you’re familiar with image request length. Simply put, this is the size of the server request that your browser forms from JavaScript code, measured in bytes. When your browser makes a request, somewhere on the other side of the internet, a server responds to this request by receiving data and/or sending data back. If everything goes like it’s supposed to, the server reports with a status code and a response body.

But there are some things that can cause this simple back-and-forth to go awry; and one of them is the size of the request.

When your browser sends too much data in a request, the server eventually stops listening. In one port and out the other. What happened in this case is something like that.

A few specific combinations of browsers and network connections caused the HTTP requests to be dropped. HTTP requests are measured in bytes, and there are limits that, when surpassed, cause bad things to happen to precious digital marketing data.

Trouble Ahead

Problems creep in when byte length passes certain thresholds. The safe zone is under 2048 bytes. Here’s what happens when you start to bust through that limit.

Under 2048 bytes > 2048 bytes > 4096 bytes > 8192 bytes > 16384 bytes
Safe zone! IE8 and earlier have a hard limit of 2048 bytes for the address bar as well as GET/POST requests.

Above 2048 bytes, IE8 and earlier abort requests.

Newer versions of Internet Explorer drop requests. This is the size class that caused our support ticket. It’s rare, but it’s serious. At this size, the request is dropped a whole plethora of places, including IIS and Apache Server, as well as the most popular web proxy servers, such as Squid (relevant source code).

Furthermore, if a corporate network operates on a web proxy, then most likely these requests are killed. How’d you like for all your clickstream data over a corporate proxy to be lost?

Think of this as the neighborhood chatty Cathy.

At this stage, vendors such as Adobe, are just dropping the request completely, and most likely other technologies are not handling them appropriately. Some such as Google Analytics convert to a POST request to help handle the issue but still can cause any of the above problems.

Basically what’s going on here is that any request over 2048 bytes, since it lives in the wilds of the internet jungle, is at risk of unpredictable dropping.

Yeah but how often does that happen, really?

You’d better sit down for this. I took a look at our current tag database, which currently has comprehensive profiling data for some 211 million tags, actually deployed across the web.

Some of these percentages look small, but every tag counts—if it’s not, it shouldn’t be on your site! Our support case was regarding the .006% of pages in our system with a huge request size that a proxy dropped, and guess what pages had these tags? The home page and many of the top-level site section pages. Small chance, perhaps, but are you willing to risk losing data from everyone connecting through a company VPN as well as anyone using IE? I think mom-in-law has overstayed her welcome.

What can I do about it?

Find large requests and reconfigure them so they make multiple server calls or just stop trying to collect so much data.

Collecting this data used to be kind of tricky. If you use ObservePoint, good news for you – we automatically collect byte length on every single tag request, and it’s easy to find in a report.

Several other tools, including TagDebugger™, will allow you to see the request size as well. Hunting down these issues can be a huge headache, but worth it in the end.

What sort of problems plague your tags? Find out today with a free mini-audit.

About the Authors

Alan Feuerlein, Lead Applications Engineer

Raised in Cincinnati, Ohio, Alan is ObservePoint’s lead web applications engineer. With a strong background in mathematics and scalable applications development, Alan is determined to keep systems stable and trustworthy. He enjoys learning and progressing in his craft while finding interesting and helpful information to improve ObservePoint.

In his free time, Alan likes to run marathons, play video games, and golf. He also has an affinity for cooking and has recently mastered the art of brining. Alan holds Bachelor of Science degrees in Philosophy and Mathematics from Brigham Young University, where he taught introductory philosophy courses.

Matthew Miller, Director of Marketing

A native of San Diego, California, Matthew joined ObservePoint in 2008. He believes his calling is to help digital marketers do more of what they love. A natural leader, he loves to bring people together to achieve cooperative greatness.

In his free time, he can be found volunteering at the American Marketing Association, and the Digital Analytics Association.


About the Author

Alan Feuerlein

Alan is an innovative software developer and leader who is passionate about Big Data and digital marketing. Originally from Cincinnati, Ohio, Alan now lives in Orem, Utah and has worked in developing software since 2009. He's spent 6+ years in the web analytics industry in data verification and has worked aggressively to resolve poor data quality. Because of the many issues he has encountered in the digital world, he often refers to the internet as “The Wild West.”

LinkedIn More Content by Alan Feuerlein
Previous Article
Measure Twice, Cut Once: Debunked
Measure Twice, Cut Once: Debunked

This article explains why having more than one web analytics tool can compromise overall data quality, caus...

Next Article
How Often Should I Perform a Tag Audit?
How Often Should I Perform a Tag Audit?

This article reveals the frequency at which your site should be audited for various circumstances. Whether ...

Get a free 14-day trial with ObservePoint

Start Your Trial