GA4 without gtag: a first-party collector

Why not just add gtag.js?

Because this site's CSP forbids third-party requests outright — script-src 'self', connect-src 'self' — and gtag.js would need both loosened, plus a permanent seat on the performance budget. Rather than weaken the policy to fit the tool, the tool was rebuilt to fit the policy. That's server-side tagging in its smallest possible form: no tagging server, just a route.

How does the collector work end to end?

Three pieces, all first-party. A tiny inline snippet in the layout runs before anything else, captures first-touch UTM and click-id parameters before client-side routing can rewrite the URL, and queues early events on window.tk.q. A deferred same-origin script (/tk-collect.js, plain JavaScript, no dependencies) boots, drains the queue, and starts observing. And one API route, /api/collect, receives batches and forwards the survivors to Google's Measurement Protocol:

POST https://www.google-analytics.com/mp/collect
     ?measurement_id=G-XXXXXXXXXX&api_secret=•••

{
  "client_id": "1712345678.1724800000",
  "timestamp_micros": 1724800000000000,
  "non_personalized_ads": true,
  "events": [
    { "name": "page_view",
      "params": { "page_location": "https://…", "session_id": "…" } }
  ]
}

Delivery uses navigator.sendBeacon() with a fetch(…, { keepalive: true }) fallback, so events fired during navigation still leave the page. The script tracks what gtag would: page_view on real navigations (by patching pushState/replaceState and listening to popstate), scroll depth at 25/50/75/90 percent, CTA and outbound clicks, and user_engagement on visibilitychange and pagehide.

How do you keep sessions and attribution without cookies?

GA4 doesn't require cookies — it requires a stable client_id. The collector keeps all state in web storage:

Attribution capture covers utm_* plus the paid click ids: gclid, gbraid, wbraid, msclkid, fbclid, li_fat_id. First-touch is written once and defended for 90 days; last-touch updates per session. That distinction is what lets a lead be traced to the campaign that first introduced the visitor, not just the one that closed them.

What does the server refuse to forward?

The route is the checkpoint that a client-side setup never gets. Everything is deny-by-default:

const EVENT_ALLOW = new Set([
  "page_view", "scroll", "cta_click", "outbound_click",
  "user_engagement", "session_start", /* … */
])
const PII_PATTERN = /email|e-mail|name|phone|tel|company|address|user_id/i

// generate_lead is deliberately NOT in EVENT_ALLOW.
// Only the server-side form handler may emit it.

• An event allowlist (10 names) and a parameter allowlist (~25 keys). Unknown events and params are silently dropped, so a typo can't pollute the property and a malicious client can't inject junk dimensions.
• A PII pattern check — any parameter whose name looks like an email, name, phone, or address field is stripped before the payload leaves the origin.
• Rate limiting: 60 requests per minute per IP, at most 10 events per request.
• generate_lead is rejected from the public route entirely. Only the server-side form handler that actually received an inquiry may emit it — so the one number that gets treated as money can't be spoofed by anything that runs in a browser.
• Every forwarded payload sets non_personalized_ads: true and stamps timestamp_micros server-side.

How do you debug Measurement Protocol events?

Blind is the default failure mode here: the Measurement Protocol returns 204 whether or not GA4 understood the payload. Three steps make it observable:

1. In development, mirror every payload to /debug/mp/collect — Google's validation endpoint — and log the validationMessages it returns. This collector does that automatically outside production and behind a ?debug=1 flag.
2. Watch GA4's DebugView while sending test events to confirm params arrive under the names you expect.
3. Keep a "send test hit" button in your admin tooling that fires one real page_view through the full path — the fastest possible answer to "is the pipeline up?".

What did it cost, and what would change at scale?

The collector is ~250 lines of dependency-free JavaScript served from the site's own origin; the route is one file. Nothing was added to the client bundle's framework path, the CSP kept default-src 'self', and the site's Lighthouse profile stayed exactly where it was. The honest limitation: this is a one-destination design. The day a second vendor needs the event stream is the day the route grows into a real tagging server — and that trade-off is covered in the server-side tagging overview. Reading the data back out again is its own topic: pulling GA4 reports with the Data API.

Questions