I had a lot of trouble waking up Google Analytics because I use Safari. Claude AI told me to use Chrome instead and that woke up Analytics for me.
This is what Claude told me:
This is Safari’s built-in Intelligent Tracking Prevention (ITP), doing exactly what it’s designed to do — it maintains a list of known tracker domains and blocks connections to them at the browser level, before the script even loads. That’s why nothing shows in Network and why GA4 never receives data: Safari is silently killing the request, and no amount of fixing your HTML would ever change that, because your code was never broken in the first place. This has been the actual problem the whole time.
Important implication: this doesn’t just affect your testing — it affects a meaningful slice of your real visitors too. Safari and iOS have this on by default for everyone, and Firefox has similar tracking protection. So even once everything’s confirmed working, your GA4 numbers will always undercount by however many of your visitors use Safari/Firefox with default privacy settings. That’s normal and universal for GA4 — not a bug specific to you.
To actually verify the tag works (rather than test around Safari’s blocking):
- Test in Chrome instead (regular Chrome, not incognito with extra blocking) — Chrome doesn’t block by default. Load the site, check Network for the
collectrequest, and check GA4 Realtime. - If you want to test in Safari specifically, you can temporarily disable tracking prevention for this one site: Safari → Settings for This Website (or the “aA” icon in the address bar) → turn off “Hide IP Address”/tracking prevention for that page — though this is just for testing, not something to ask visitors to do.
Try Chrome next — that should finally show the collect request firing and give you a clean Realtime hit in GA4.
That’s completely expected, not an error to worry about on its own has no homepage; it only serves specific script files at specific paths (like the one your site requests: /gtag/js?id=G-9WQZMVHCHQ). Visiting the bare domain with nothing after it correctly returns a 404, same as it would for anyone.
This step isn’t actually part of what you need to do — my earlier instructions were about testing your own site in Chrome, not visiting Google Tag Manager’s domain directly. Here’s the actual sequence:
- In Chrome’s address bar, go to your own site:
- Open DevTools: View → Developer → Developer Tools (or ⌥⌘I on Mac)
- Click the Network tab inside DevTools
- Reload the page (⌘R) while DevTools is open
- In the filter box at the top of the Network panel, type
collect - You’re looking for a request to something like
hat’s exactly what you want to see — two collect?v=2&tid=G-9WQZMVHCHQ requests, both returning status 204 (which means “received successfully, no content to send back” — that’s the normal, correct response for GA4 hits). The tag is firing correctly, sending the right measurement ID, and Google’s servers are acknowledging receipt.
This confirms the whole chain is working: DNS → hosting → cached HTML → the gtag script → Chrome not blocking it → the hit reaching Google. The Safari ITP blocking was indeed the entire issue with your earlier testing.
Now go check GA4 → Reports → Realtime overview in this same browser — you should see “1” active user right now. If it shows up there, you’re done: the tag is fully working and it’s just a matter of waiting a day or two for the standard reports to start populating with historical data.
I hope this may help others if they run into the same problem.