Web Analytics Without Creepy Tracking: A Privacy-First Approach for Developers

For years, I used Google Analytics on every project by default. It was free, it tracked everything, and it felt responsible — like wearing a seatbelt. Then I actually looked at the data and realized: I was collecting hundreds of data points about my users and looking at maybe five metrics.

Worse, I was forcing cookie consent banners on EU users, slowing page loads with tracking scripts, and sending my users' browsing behavior to Google's advertising machine — all for data I barely used.

Here is the alternative approach I adopted that gives me the metrics I need without the privacy baggage.

What Metrics Actually Matter

For a developer tool directory (or any content-heavy site), the metrics that inform decisions are:

Page views per page: which content is popular? Which tools get the most views? This guides content creation and feature prioritization.

Referral sources: where do visitors come from? This tells me which marketing channels work (organic search, Twitter, newsletters, direct traffic).

Geographic distribution: where are my users located? This informs decisions about: CDN edge locations, content localization, and regional feature prioritization.

Device breakdown: desktop vs mobile vs tablet. This guides responsive design priorities. If 80% of traffic is desktop, mobile optimization is less urgent (but still important).

Bounce rate by page: are people finding what they expect? High bounce rate on a tool page might mean the SEO description does not match the content.

That is it. Five metrics. I do not need: user tracking across sessions, individual user behavior flows, personal demographics, interest profiles, or advertising data.

The Problem with Google Analytics

Google Analytics 4 (GA4) is: a complex tool designed for marketing teams at large companies that need to justify advertising spend.

For developers: GA4 is overkill. The interface is confusing. The data is sampled at higher volumes. The implementation requires cookie consent (GDPR, CCPA). The tracking script is 28KB and blocks rendering. And the data feeds Google's advertising platform — your users' browsing habits are the product.

Additionally: many users run ad blockers that block Google Analytics entirely. In tech audiences, this can be 30-40% of visitors. Your analytics data is fundamentally incomplete.

Privacy-Respecting Alternatives

Plausible Analytics: our choice. Open-source, lightweight (under 1KB script), no cookies (no consent banner needed), GDPR compliant by default, and shows exactly the metrics I listed above in a simple dashboard.

Cost: $9/month for up to 10K monthly pageviews. Self-hosting is free (we considered it but pay for the hosted version for convenience).

What Plausible does not do: track individual users across sessions, build user profiles, set cookies, slow down your page, or share data with advertisers.

Fathom Analytics: similar philosophy to Plausible. Cookie-free, privacy-respecting, simple dashboard. Slightly different pricing model. Both are excellent choices.

Umami: open-source and self-hostable. Free forever if you run your own instance. Good option if you want full control over your analytics data and do not mind the maintenance.

Implementation: Adding Plausible to Next.js

The implementation is a single script tag in your layout. No configuration, no initialization code, no consent management, no cookie banner. The script is async and does not block rendering.

Page views are tracked automatically. Custom events (button clicks, form submissions) require one line of JavaScript: plausible('signup') or plausible('tool-bookmarked', { props: { tool: toolSlug } }).

What We Track at AIDToolStack

Page views: every page, automatically tracked. We see which tools are popular, which blog posts get traffic, and which categories attract visitors.

Custom events: tool bookmarks, comparison additions, search queries, newsletter signups, and external link clicks (when a user clicks through to a tool's website). These events tell us which features are used and which tools get click-throughs.

Goals: conversion events we care about — newsletter signups, Pro plan upgrades, and tool submissions. Plausible shows conversion rates from different referral sources and pages.

What We Intentionally Do NOT Track

Individual user journeys: we do not track which pages a specific user visited in sequence. We do not need this. Aggregate page view data tells us what is popular.

Session duration: a vanity metric for content sites. A user who finds the answer in 10 seconds had a better experience than one who spent 5 minutes searching.

Scroll depth: if the content is useful, users read it. If it is not, they leave. Scroll depth adds no actionable insight.

Personal demographics: age, gender, interests — none of these are relevant for a developer tool directory. And collecting them requires invasive tracking.

The Cookie Consent Problem

If your analytics tool sets cookies, you need a consent banner for EU visitors (GDPR) and California visitors (CCPA). This means: building or integrating a consent management system, degraded UX for a large portion of your users (banner covering content), incomplete data (users who decline are invisible), and legal liability if your implementation is incorrect.

With cookie-free analytics: no consent banner needed. Every visitor is counted (unless they block JavaScript entirely). The UX is clean. And you are compliant by default.

This alone justifies switching from GA4. The engineering time saved on consent management pays for years of Plausible subscriptions.

Server-Side Analytics

For API-heavy applications, client-side analytics miss: API calls, bot traffic patterns, and server-rendered pages where JavaScript does not execute.

We supplement Plausible with server-side logging: request counts per endpoint (logged to our monitoring system), response time percentiles (logged to Sentry Performance), error rates (logged to Sentry), and bot traffic (identified by User-Agent, logged separately).

This gives us the operational metrics that client-side analytics cannot provide.

Making Decisions with Limited Data

Privacy-respecting analytics provides less data than Google Analytics. You do not know individual user journeys or personal demographics. Can you still make good product decisions?

Yes. Aggregate data is sufficient for almost every product decision:

"Which tools should we feature?" → sort by page views.

"Which blog topics should we write more of?" → sort by traffic.

"Which marketing channel should we invest in?" → sort referral sources by volume.

"Should we build a mobile app?" → check device breakdown.

Individual user tracking helps with: complex marketing attribution (multi-touch), personalized experiences (recommendations), and detailed funnel analysis. If you need these, privacy-respecting tools like PostHog offer them with appropriate consent flows.

But for most developer tools and content sites, aggregate metrics are sufficient and respect your users' privacy.

The Philosophical Position

We build tools for developers. Developers are among the most privacy-conscious users on the internet. They run ad blockers, VPNs, and privacy-focused browsers. Tracking them invasively while claiming to serve them is hypocritical.

Choosing privacy-respecting analytics is not just an ethical position — it is a business alignment. Our users value privacy. Our analytics approach respects that value. It builds trust rather than eroding it.

The data we need to make good product decisions does not require tracking individual humans across the internet. Aggregate, anonymized page views and events are sufficient. Everything beyond that is surveillance, not analytics.