TL;DR — GA4's gtag.js snippet was installed correctly, the page loaded with no visible JavaScript error, and GA4's real-time report still showed zero activity. The CMS's default Content-Security-Policy had no allowance for analytics domains and no config option to add one — so every request to Google's tracking endpoints was blocked at the browser level before it could fail loudly.

Diagnostic

Check the browser's dedicated CSP violation reporting, not the regular console error list — CSP blocks are reported through their own channel, not thrown as normal script errors, so "no console errors" doesn't mean nothing was blocked.

Root cause

The CSP's script-src and connect-src directives had no entry for googletagmanager.com or google-analytics.com, and the CMS exposed no configuration surface to add one — the only way in was patching the CSP directives directly.

// patch-package: add analytics domains to the existing CSP directives
scriptSrc.push("https://www.googletagmanager.com");
connectSrc.push("https://www.google-analytics.com", "https://www.googletagmanager.com");

Lessons learned

• "No console errors" is not proof nothing was blocked — CSP violations live in their own reporting surface and are easy to miss if you're only scanning for red error text.
• Before adding any third-party script tag to a site with a CSP already in place, check the CSP's directives first rather than assuming a silently-empty analytics dashboard means a snippet-installation mistake.

TL;DR — Deploying to shared hosting failed during npm install while a native addon (better-sqlite3) tried to compile via node-gyp, tripping over the host's old glibc/Python toolchain — neither of which can be upgraded on shared hosting. The actual fix was realizing the native module wasn't even needed at runtime anymore, and skipping its build step entirely.

Symptom

Install fails specifically inside the native module's own postinstall build step — a node-gyp/compiler error tied to the host's old system Python/glibc versions, not a normal dependency-resolution failure.

Root cause

Shared hosting gives no control over the system Python/compiler toolchain node-gyp needs to compile a native addon. In this project, the database adapter had already moved to a different backend (Turso/libsql, then Postgres) at runtime — so the native SQLite binding wasn't actually load-bearing anymore, just still listed as a dependency whose build script fires on every install.

Fix

.npmrc
ignore-scripts=true

This skips all install-time build scripts, including the native compile step — safe here specifically because nothing at runtime still depends on that native binary.

Lessons learned

• ignore-scripts=true skips every package's install scripts, not just the offending one — audit what's actually installed and confirm nothing else's postinstall step is load-bearing before reaching for this.
• When migrating a database adapter, remember to also drop (or at least stop needing) the old adapter's native dependency — it can keep silently causing deploy failures long after the code stopped using it.