GA4 Cookie Issues

[rotated8]

Some users that do not use ad blockers are seeing analytics cookies proliferate, causing requests to fail until cookies are cleared.

• [ ] Are we setting analytics cookies correctly?
• [ ] Are they scoped correctly to our site?
• [ ] Can we detect and clean up bad cookies?

[abelemlih]

@rotated8 the production instance is set up with an outdated Universal Analytics tag, which may be causing some of the issues with Google Analytics we have seen. I will update the production instance with the updated GA4 tag tomorrow. We will need to monitor whether the issues previously seen persist after this change.

[tclayton33]

I'll contact Jenny Vitti and ask her to monitor this and provide feedback.

[tclayton33]

Jenny has seen this problem reappear - here is her description: The Bad Request error has reappeared for Library Search for me, currently in Firefox (which is my default browser). This is the first I’ve seen of it since I cleared my cookies & cache on Nov 30, so it made it much longer than usual! Here’s the error message I’m seeing:

Bad Request Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit.

And although I think we’ve determined this part is irrelevant, here’s the URL where I first saw the error message: https://search.libraries.emory.edu/?utf8=%E2%9C%93&search_field=keyword&q=0730-0832 (of course now it’s happening across the board for wherever I go in Library Search).

I had my browser open to Library Search already, and also several/many other tabs, and I’d been using Library Search earlier today for other searches, most recently about 5 minutes before the error appeared.

If it’s relevant, I also started seeing the JSTOR errors two days ago in the same browser, which I also hadn’t seen since Nov 30. JSTOR has the most pervasive errors of all the tools we use on our team. When I go to unproxied JSTOR resources, they work properly (still), but when I apply Emory’s proxy to JSTOR, it’s been bricked for the last two days, even when I close and reopen my browser. A specific example is: https://www.jstor.org/stable/j.ctv11990hg vs. https://www-jstor-org.proxy.library.emory.edu/stable/j.ctv11990hg

I haven’t cleared anything in my browser yet (I’m just using private/incognito sessions, or switching to another browser). Is there anything you’d like to see from my settings before I clear things? @abelemlih and @rotated8

[rotated8]

Related to emory-libraries/librarysearch-enhance#38

[rotated8]

Some stats: Total request size: ~9Kb Total cookies size: ~8.5 Kb Max allowable header size: 8 Kb, by default.

Number of GA IDs: 28 Total GA ID cookies size: ~1.5 Kb Search Session cookie size: ~0.8 Kb Obvious PeopleSoft cookies size: ~ 1.0 Kb

Search session cookie is scoped to search.libraries.emory.edu, so should not be passed to other emory.edu sites.

[rotated8]

Three paths for further improvement: 1- Coordinate with our other GA properties to switch to one ID. Tough, takes a bunch of dev work, changes how each site gets analytics. 2- Reduce size of Search session cookie. Amount of work is unknown, maximum amount of savings may be small, does not help sites other than Search. 3- Increase acceptable total size of cookies. Does not fix problem, only delays it for Search alone.

[rotated8]

If we go the route of increasing the allowable total cookie size, we'll need to set this is in Nginx: https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers