Why We Built Our Own Web Tracker
When we started building d8a, the goal was straightforward: fix everything broken about GA4 and give companies back ownership of their data. In the beginning, we handled tracking by duplicating GA4 tracking 1:1 so teams could move fast without rewriting their entire instrumentation. It worked, but we knew it wouldn’t be enough for everyone.
If you want to truly own your analytics, there’s still one piece that ties you to Google: the tracker itself. You can build the most sovereign data platform in the world, but if your website needs the Google tag just to collect events, you’re not really free. For many companies, especially those in regulated industries, that single dependency is a dealbreaker.
So we built our own web tracker. And we made it better.
Compatible by Design, Better by Choice
According to W3Techs, Google Analytics runs on roughly 80% of all websites that use a known analytics tool. That’s a staggering amount of existing implementation work - tag management configurations, data layer setups, custom event structures - all built around the gtag protocol.
We had no interest in throwing all of that away. Time is the most valuable currency in any organization, and forcing companies to redo their entire tracking implementation just to switch platforms is wasteful and unnecessary. So we built the d8a web tracker to be fully compatible with the Google tag. Your existing data layer, your existing event structure, your existing tag management setup - it all works out of the box.
But compatibility doesn’t mean blind mimicry.
What We Dropped (On Purpose)
We deliberately chose not to support built-in form tracking, scroll tracking, and video tracking. Before you raise an eyebrow, hear us out.
We’re not removing features. We’re removing frustration.
Anyone who has worked with Google’s enhanced measurement knows the pain. These auto-tracked events are rigid, inaccurate, and almost always need to be overridden with custom implementations anyway. Form tracking fires on interactions that aren’t actual submissions. Scroll tracking gives you a single threshold that tells you almost nothing. Video tracking barely works outside of YouTube embeds.
We believe these interactions are far more flexible and accurate when implemented directly in your tag management system, where you have full control over triggers, thresholds, and event parameters. That’s not a limitation - it’s a design philosophy.
Sessions Done Right
Here’s one we’re particularly proud of: d8a doesn’t send a session_start event. At all.
Why? Because d8a handles session logic entirely on the backend, which is the only reliable way to do it.
We still can’t quite explain why Google decided to calculate something as fundamental as sessions in the browser. Browsers are unreliable. They get closed, they crash, they lose network connectivity, they run in background tabs that get throttled. Basing session computation on client-side signals is fragile by design. And let’s not even get started on whoever decided that session_id should be derived from a timestamp with one-second accuracy. One second. In a world where users can open multiple tabs in the same second.
d8a computes sessions server-side with full context: request timing, event sequences, and reliable timeout logic. No guesswork, no client-side hacks. Sessions that actually mean something.
Everything Else? Yes, We Support It
You might be wondering what happens to the features you actually rely on. The answer is simple: they all work.
- Cookie settings customization - full control over cookie names, domains, and expiration
- User ID - set and persist user identifiers across sessions
- Cross-domain linking - seamless tracking across multiple domains
- Custom data layer name - use whatever variable name your setup requires
- Multi-property tracking - send data to multiple d8a endpoints simultaneously
- User engagement tracking - accurate engagement signals without the guesswork
- Site search - capture internal search queries and results
- Outbound clicks - track when users leave your site
- File downloads - monitor document and asset downloads
No compromises. Everything your implementation team expects from a production-grade tracker.
Consent Without Compromise
Privacy compliance isn’t an afterthought - it’s built into the core of the d8a tracker.
Our tracker reads the consent configuration directly from the data layer. If a consent management platform is already pushing consent state to the data layer, d8a picks it up automatically. If you prefer a programmatic approach, you can also set consent using the d8a function directly.
The behavior is straightforward and predictable: if consent for analytics is not granted, no cookies are stored. Period. Thanks to our privacy-friendly session stamp feature, we’re still able to stitch events within the session even when cookies aren’t available. When consent is eventually granted, the tracker immediately fires a user_engagement event to inform the backend, ensuring that the session is correctly attributed from that point forward.
Switching Is Simpler Than You Think
So, is it really easy to migrate an advanced data layer implementation from gtag to d8a? We could write a long, reassuring paragraph about how smooth the process is. Instead, we’ll just point you to the guide:
It’s one page. A short one.
That’s not because we cut corners on the documentation. It’s because the migration is genuinely that simple: same data layer, same event structure, same parameters. Replace the script, update the endpoint, and you’re done.
Your data team gets clean, queryable data. Your marketing team keeps their familiar setup. And Google never sees another byte of your users’ data.
Ready to cut the last thread tying you to Google? The tracker is open source. Deploy it today.