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
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.
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 – our good friend Jason did a whole blog post on it. If you use ObservePoint, good new 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 AuthorLinkedIn More Content by Alan Feuerlein