GDPR-Compliant Analytics: Building Without Third-Party Cookies

You shipped a landing page redesign last month. Conversions seem to have improved—at least, your gut says so. But your Google Analytics dashboard shows a 35% consent rejection rate, and you are looking at data from less than two-thirds of your visitors. Did the redesign work? You genuinely cannot tell.

This is the state of analytics for European SaaS products in 2026. GDPR and the ePrivacy Directive have made the default third-party analytics stack—Google Analytics with cookie consent banners—both legally risky and practically unreliable. A consent rejection rate above 30% is typical for European audiences, which means you are making product and marketing decisions based on a systematically biased sample of your users.

The answer is not to find a cleverer way to track people without their knowledge. The answer is to build an analytics setup that does not require consent in the first place—because it does not use personal data in a legally meaningful sense. This post explains how.

Why Consent-Based Analytics Is a Broken Foundation

The consent-wall approach to analytics has two problems that compound each other.

The first is legal risk. Under GDPR, a consent banner is only valid if the "no" option is as easy to select as "yes," if consent is freely given without conditions, and if refusing does not degrade the user experience. Most consent implementations fail at least one of these requirements. Enforcement actions from European data protection authorities have increased significantly year over year—and regulators are now specifically targeting companies that use dark patterns in consent UI.

The second is data quality. Even with a perfectly compliant consent implementation, the users who reject analytics tracking are not a random sample of your audience. Privacy-conscious users tend to be more technically sophisticated, more likely to use ad blockers regardless of consent, and in some verticals (FinTech, healthcare, legal) more likely to be your most valuable customers. You are systematically blind to a non-random segment of your audience.

The clean alternative is to avoid the personal data threshold entirely. GDPR applies to processing of personal data, meaning information that can be used to identify a natural person. Analytics that aggregate behavior at the session level without storing IP addresses, without setting cookies that persist across sessions, and without linking behavior to identifiable user profiles fall outside this threshold. No personal data processed means no consent required.

Privacy-First Analytics Tools: What They Actually Offer

Three tools dominate the privacy-first analytics space, each with different tradeoffs worth understanding before you commit.

Plausible Analytics

Plausible is the simplest option and the easiest to justify to a DPO or legal team. It stores no personal data, uses no cookies, and is designed from the ground up for GDPR compliance. Traffic data is aggregated; there is no session-level user tracking. Plausible can be self-hosted on EU infrastructure, which matters for companies whose clients require data residency within Germany or the EU.

The tradeoff is intentional feature limitation. Plausible does not show you individual user journeys, does not support funnel analysis at the user level, and offers limited event filtering compared to GA4. For product analytics—understanding how specific users navigate your application—Plausible is not the right tool. For traffic analytics—understanding where your visitors come from, what pages they read, and which channels convert—it is excellent and fast to implement.

<!-- Plausible script: no cookie, no IP storage, no consent required -->
<script
  defer
  data-domain="yourapp.com"
  src="https://plausible.io/js/script.js">
</script>

One practical advantage: because Plausible's script does not set cookies, it is not blocked by most ad-blocking extensions that target tracking scripts. You get more complete traffic data than Google Analytics, not less.

Umami

Umami is an open-source alternative that you self-host, giving you complete data ownership. Like Plausible, it is cookieless and does not track personal data. The self-hosted model means your analytics data never leaves your infrastructure—a significant advantage if you have enterprise clients with data processing agreements that restrict third-party data sharing.

Umami's event tracking is slightly more powerful than Plausible's basic tier, and the self-hosted approach eliminates the per-pageview pricing model. For a Next.js application, the integration adds minimal overhead:

// utils/analytics.ts — Umami event tracking wrapper
export function trackEvent(eventName: string, eventData?: Record<string, string | number>) {
  if (typeof window !== 'undefined' && (window as any).umami) {
    (window as any).umami.track(eventName, eventData);
  }
}

// Usage in a component
import { trackEvent } from '@/utils/analytics';

function PricingPage() {
  const handlePlanSelect = (planId: string) => {
    trackEvent('plan_selected', { plan: planId });
    // ... rest of handler
  };
}

Because Umami is open source and self-hosted, you can audit exactly what data it stores. That auditability is worth something when a client's legal team asks questions.

Matomo (Self-Hosted)

Matomo occupies a different position: it is a full-featured analytics platform with capabilities that approach GA4, but can be configured for GDPR compliance through careful settings. The critical configuration choices are disabling cookie tracking entirely (disableCookies()), enabling IP anonymization, and setting short data retention periods.

Matomo's advantage is depth: funnel analysis, heatmaps, session recordings with privacy masking, and A/B testing—all features that privacy-first tools like Plausible sacrifice. If you need product analytics depth alongside GDPR compliance, Matomo self-hosted with proper configuration is the most viable path.

The caution is that Matomo can be configured in ways that are not GDPR-compliant. The default installation stores full IP addresses and uses persistent cookies. Deploying Matomo without explicit GDPR configuration defeats the purpose. Document your configuration choices and review them when Matomo releases updates that change defaults.

Server-Side Tracking: The More Reliable Alternative

Client-side analytics scripts face two structural problems that server-side tracking eliminates: ad blockers and consent rejection. Neither affects requests made from your server.

The approach is straightforward. Instead of relying on a JavaScript snippet in the browser, you send analytics events from your application server when meaningful actions occur. Your server already knows when users sign up, complete purchases, activate features, or hit errors—it does not need the browser to tell it.

For a Next.js application with a PHP/Symfony API backend, server-side event tracking can be as simple as a Plausible server-side API call:

// lib/server-analytics.ts (Next.js Server Action or API route)
export async function trackServerEvent(
  event: string,
  url: string,
  referrer?: string
): Promise<void> {
  if (process.env.PLAUSIBLE_API_KEY && process.env.PLAUSIBLE_DOMAIN) {
    await fetch('https://plausible.io/api/event', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'User-Agent': 'server-side-tracker',
        'X-Forwarded-For': '0.0.0.0', // Never forward real IPs
      },
      body: JSON.stringify({
        name: event,
        url: `https://${process.env.PLAUSIBLE_DOMAIN}${url}`,
        domain: process.env.PLAUSIBLE_DOMAIN,
        referrer: referrer ?? '',
      }),
    });
  }
}

In a Symfony backend, the same pattern applies for tracking conversion events:

// src/Service/AnalyticsService.php
class AnalyticsService
{
    public function __construct(
        private readonly HttpClientInterface $httpClient,
        private readonly string $plausibleDomain,
        private readonly string $plausibleApiKey,
    ) {}

    public function trackEvent(string $event, string $url): void
    {
        if (!$this->plausibleDomain) {
            return;
        }

        $this->httpClient->request('POST', 'https://plausible.io/api/event', [
            'headers' => [
                'Content-Type' => 'application/json',
                'User-Agent'   => 'server-side-tracker/1.0',
            ],
            'json' => [
                'name'   => $event,
                'url'    => 'https://' . $this->plausibleDomain . $url,
                'domain' => $this->plausibleDomain,
            ],
        ]);
    }
}

Server-side events capture 100% of meaningful conversions regardless of browser settings, consent choices, or ad blockers. The tradeoff is that you lose passive behavioral data—scroll depth, time on page, navigation paths—that client-side scripts capture automatically. For most SaaS products, the conversion events are what matter for decision-making anyway.

What You Can Measure Without Consent

Understanding the legal boundary helps you instrument your application correctly rather than over-cautiously.

Traffic-level analytics—page views, referrer sources, browser type, country-level location—are generally outside the personal data threshold when processed without cookies and with IP addresses either not stored or truncated to the network level. This covers most of what marketing teams need: channel attribution, content performance, and geographic distribution.

Authenticated user behavior within your application is a different category. When a logged-in user interacts with your product, you already have a lawful basis for processing their data (contract performance, legitimate interest) and do not need a separate consent mechanism for analytics of their in-product behavior. Tracking which features a paying customer uses, where they abandon onboarding flows, and which integrations they activate is legitimate first-party analytics that does not require a cookie consent popup.

The gray area is anonymous session tracking across pages—trying to understand a visitor's complete journey before they sign up. If you want this level of insight without consent, you need to be genuinely certain you cannot re-identify sessions: no IP storage, no persistent identifiers, no cross-device correlation. Cookieless session tracking that uses fingerprinting or probabilistic identification still constitutes personal data processing in most EU regulatory interpretations.

Instrumenting Your Next.js Application Correctly

A practical analytics setup for a Next.js SaaS product in 2026 typically combines three layers.

The first layer is a privacy-first script (Plausible or Umami) that captures passive traffic data—page views, referrers, device types—without cookies or personal data. This runs without a consent banner.

The second layer is server-side event tracking for conversion milestones: signups, trial activations, feature completions, and payment events. These fire from your backend regardless of browser behavior.

The third layer is first-party in-product analytics for authenticated users, where you have a contractual basis and are tracking behavior within the scope of service delivery. This can use richer instrumentation since consent is not the lawful basis—legitimate interest or contract performance is.

What this replaces is the third-party cookie stack: GA4, Facebook Pixel, Intercom tracking, and similar tools that set persistent cross-site cookies, require consent, and send your users' behavioral data to external platforms for aggregation. Removing these tools also improves your application's load performance—the consent banner and its supporting scripts are typically 50-150KB of JavaScript that slows your initial page load.

The Architecture Decision This Requires

Deciding to move to privacy-first analytics is also a tech stack strategy decision with downstream infrastructure implications. Where does your analytics data live? Who owns the database? How is it retained and deleted to meet GDPR's data minimization principle?

If you choose a self-hosted tool like Umami or Matomo, you are adding a database and a service to your infrastructure. That service needs backups, monitoring, and security patching. For most teams this is manageable, but it should be a deliberate choice rather than an afterthought.

The data residency question matters for products sold to German Mittelstand companies or enterprise clients with data processing agreements. Storing analytics on EU infrastructure—whether self-hosted or through an EU-based analytics provider—avoids the Schrems II complications that come with US-based analytics platforms.

If you are rebuilding your analytics architecture as part of a broader technical overhaul, a web application development or digital transformation engagement is the right context to do it properly rather than bolt it on later.

Practical First Steps

The fastest path to a compliant, complete analytics setup for a European SaaS product:

Remove Google Analytics or replace it with Plausible or Umami. Add the script tag, verify it is receiving traffic without a consent banner, and remove the consent management platform if the only tool requiring consent was the analytics script. This alone simplifies your legal compliance posture considerably.

Add server-side event tracking for your most important conversion events. Identify the five to ten moments in your user journey that actually inform product decisions—activation events, payment completion, feature adoption milestones—and emit server-side events for each.

Establish a data retention policy for your analytics data. Configure automatic deletion of data older than 12 months, document the policy, and include it in your privacy policy. This satisfies GDPR's data minimization and storage limitation principles without requiring manual intervention.

Finally, review what other third-party scripts you have added over time. Marketing pixels, session recording tools, and chatbots frequently collect personal data without the development team realizing it. A content security policy audit surfaces these quickly.

Conclusion

GDPR-compliant analytics is not a constraint to work around—it is an architecture choice that produces better data. Consent rejection removes a non-random slice of your audience from your analytics picture, and third-party tracking scripts give external platforms data about your users that you do not control. Privacy-first analytics—Plausible, Umami, or Matomo self-hosted with proper configuration—plus server-side event tracking for conversions gives you complete, reliable data that you own and your users never have to consent to.

The implementation work is modest for a new application and a contained migration for an existing one. The legal and data quality benefits compound over time.

Wolf-Tech builds Next.js and PHP/Symfony applications with privacy-first instrumentation from the ground up, and helps existing European SaaS teams migrate away from consent-dependent analytics stacks. Contact us at hello@wolf-tech.io or visit wolf-tech.io for a free consultation.