Why Your Analytics Data Is Going Into A Black Hole
And how to prevent it
You’ve just implemented a new analytics solution, and you’re super excited to see the results. But then…nothing. No data comes in for hours, days, or weeks. What gives? Is your implementation wrong? Is your data just taking its time to come in? Or is there some other explanation?
The answer, lies not in your implementation but in where your analytics are going, or more precisely, not going. We often use third-party providers like Google Analytics (or even Google Tag Manager) to collect and process data so that’s where all that data would reside right?
The script tag we inject into our websites listens to events and sends that data to the API server of those providers, a well-known domain that can easily be blocked by ad blockers or other privacy software.
Depending on the user base, we can lose any amount of valuable user data. If the given service targets developers, we can expect tremendous losses since many of us use Brave Browser or Ad Block-like extensions.
When we use such privacy protection tools, we think we are defending our personal data from being sold by big corporations with ill-intent, but that’s not always the case. Analytics data can be used to record performance and reiterate certain features or user-experience upgrades.
Take, for example, user heatmaps, a common view of analytics data that’s used to see where users click the most, or how they scroll through a page. If we know where our users are struggling, we can improve the design and user-experience of our products.
But how could we trick those pesky ad blockers into allowing transmission of analytics data, and where does the barrier between ethical usage of such methods come in?
Privacy is not something that I’m merely entitled to, it’s an absolute prerequisite.” — Marlon Brando, Actor
I’ve made a rather grotesque diagram of what the normal flow of data looks like below.
My most primitive explanation is that the ad blocker recognizes certain domains (maybe through a blacklist) and shreds the data (blocks the request) before it leaves the browser.
A “simple” fix is to create your own data analytics solution, host it on your own domain, wait a couple months to get your unicorn status, and validate it by being added to that very blacklist.
If this huge code overhead and unwise architectural decisions don’t satisfy your needs, let’s talk about middlemen. No, not the evil kind.
Instead of self-hosting an entire analytics service ourselves, we could simply forward the request from our domain to the 3rd party provider with an ordinary URL rewrite. This acts as a proxy sitting on the same domain, which is unlikely to be hindered by most ad blockers.
To continue my hideous diagram spree, here’s how a simple proxy would work for our website. The problem and core solution in this article were already marvelously outlined by Theo.
As always, enough chit-chat and let’s get our hands dirty with some code, I’ll showcase how we’d implement such a proxy solution in Next.JS with Splitbee and Plausible. I’m not covering a Google Analytics implementation since there are already several articles covering it.
Splitbee Analytics
When analytics don’t have to be hard
To set up Splitbee we simply create a new project and give the subdomain we want to extract analytics data from.
If we didn’t worry about ad blockers we could proceed to embedding the script directly in the _app folder through a Next script component as indicated in the dashboard.
Next.JS makes it insanely easy to add rewrites directly in next.config.js, every rewrite needs a source and a destination, but deciding that on our own leads to decision fatigue, luckily we can find the exact lines we need in the docs. Copy pasting begins. (code here)
One deploy later we can see analytics starting to show up in the dashboard. After a closer look we can see the proxy requests in the Network Requests tab.
Plausible
When data protection is a plausible must
Plausible is rather similar in the data and implementation aspects but brings a rather unknown feature at least to US only companies. Since it’s entirely made and hosted in EU cloud-infrastructure it becomes fully compliant with GDPR, CCPA and PECR.
What do all those weird acronyms stand for? In a nutshell there are several laws that restrict storage and transfer of data outside the European Union without requiring user consent (usually through cookie popups). Check my article How Google Fonts Became Illegal In Europe for more info.
Instead of struggling with implementing cookie consent or other legal bypasses through Terms & Conditions / Privacy Policies we can add Plausible and start recording data within minutes.
Integrating Plausible to Next.JS is remarkably simple as well, with next-plausible package we wrap the _app.js contents with the PlausibleProvider, add your domain name and it’s ready to go. (code here)
Regarding adding the proxy, next-plausible exposes a “with” decorator including all the needed proxy setup hiding a more advanced setup under the hood.
And that’s it! We’ve successfully added two analytics solutions to our Next.JS app without having to worry about Ad Blockers or data privacy laws. To benchmark both solutions I’ll be running them in parallel on my upcoming side-project Interviewor, a free, web development interview trainer.
Do you have any questions or suggestions? Feel free to reach out! 🚀.
That’s it for now, thank you for reading and leaving analytics data (pun intended)! If you want to stay updated on my future writings follow me on Medium or Twitter.
