Optimizing cookie domains and cleaning Google Tag Manager for a streamlined umn.edu experience
Introduction
Have you ever received the "431: Request Header Fields Too Large" error? At the heart of this issue is the domain level at which cookies are set. This situation arises when a cookie set by a subdomain, such as a.umn.edu, inadvertently gets included in every request to other umn.edu subdomains.
This collective accumulation of cookies can escalate quickly, resulting in an overly large request header. When a user's browser sends this bloated request to a server, it often leads to a server's refusal to respond, manifesting as the aforementioned 431 error.
While we can’t control every cookie set at every subdomain, there are ways we can help mitigate the 431 error using Google Tag Manager (GTM) and, at the same time, keep your GTM container clean and free of clutter.
All it takes are a couple housekeeping steps that not only ensure we are not overloading the umn.edu environment, but will also help eliminate old noisy tags, keep your Google Analytics (GA) account domain correctly targeted, and guarantee you use only tags associated with GA4.
Time For Some Pixels Winter Cleaning
Remember that one agency you worked with back in 2020? I sure don’t. But after all of the creative was placed, channels were identified, and results were reported back, chances are they never removed all of those fun social and retargeting pixels from your GTM account.
Do you have a three-year-old Facebook pixel still lingering in your property? Believe it or not, it’s probably still firing on the umn.edu domain. Moreover, all of these old pixels are creating noise in your account, making it more difficult for your team to identify what tags are important right now.
The good news is that these are easy to remove! All you need to do is log into your GTM account. In the left rail navigation, go to your tags. Once there, you’ll see to the far right a column titled “Last Edited”. This is where you can identify the last active edit date of your tags. See a tag last edited before a global pandemic? That’s a good identifier the tag needs review.
If it’s not being used, then simply click the square box left of the tag name. Then navigate to the trash can icon in the top right and delete it. All done! You’ve effectively created less noise for your GTM container.
UA to GA4 Migration: Don’t Forget to Remove Legacy Tags!
It's time to put wonderful Universal Analytics to rest. Yeah, I know, I miss it too. Most GTM accounts I come across still have the Universal Analytics tag still firing on websites. These do need to be removed.
Setting Your Gtag Cookie Domain: The Big Opportunity
(Updated on April 2nd, 2026)
This is one of the bigger 431 error issues we’ve identified. As noted in the introduction, our website domain is set up with a series of subdomains with the MAIN domain set as umn.edu.
This means, without the cookie properly configured to your specific unit’s subdomain, all GA accounts default to the root umn.edu domain instead of being correctly isolated to your specific environment. With so many subdomains across our digital ecosystem, these cookies blow up quickly.
Originally, we recommended hardcoding your unit's domain into the tag. However, many units manage multiple sub-subdomains. To make our tracking more flexible, dynamic, and scalable, we’ve updated our best practice to use a Custom JavaScript Variable.
This script looks at the page the user is visiting and dynamically assigns the correct cookie domain. If it detects a complex environment, it forces the cookie to the root of that specific unit (using a . before the domain so the cookie can be shared across its sub-subdomains). If not, it safely defaults to the exact hostname.
Here are the steps to implement this dynamic methodology:
Step 1: Create the Custom JavaScript Variable
- In your GTM account, click on Variables in the left navigation.
- Scroll down to "User-Defined Variables" and click New.
- Name the variable something clear, like CJS - Dynamic Cookie Domain.
- Click into the Variable Configuration and select Custom JavaScript.
- Paste the following code:
function() {
var hostname = {{Page Hostname}};
// Force cookie to the root of the Research office to allow cross-subdomain tracking
if (hostname.indexOf('research.umn.edu') > -1) {
return '.research.umn.edu';
}
// Fail-safe: Return the exact hostname for all other sites
return hostname;
} Save the variable.
Step 2: Update your Google Tag (GA4 Configuration)
- Navigate to your Tags and open your main Google Tag (formerly GA4 Configuration Tag) that fires on page views.
- Under “Configuration Settings”, look for the button labeled Add Parameter and click it.
- In the “Configuration Parameter” field, type exactly: cookie_domain.
- In the “Value” field, instead of typing a URL, click the Lego brick icon (variable selector) and select the {{CJS - Dynamic Cookie Domain}} variable you just created.
- Save and Publish: Once you have entered the correct information, hit Save and then Submit/Publish your GTM workspace.
And that’s it! Your tag is now smart enough to adapt its cookie domain dynamically based on the specific website it loads on, keeping our university data environment clean and secure.
Conclusion
By cleaning out outdated pixels, removing old Universal Analytics tags, and accurately and dynamically targeting your unit’s subdomain, you ensure a more efficient and user-friendly experience on our umn.edu site. Additionally, these steps help maintain a streamlined GTM property that scales with your measurement needs.
If you have any questions or need help with any of the above, don’t worry! The Measurement and Analytics team has your back. Feel free to reach out to me, Eric Meyer, at [email protected] for a quick consultation and help. Moreover, we’d love to hear from you in general! Always reach out and say hi. Happy analyzing!