Choosing Analytics for Your Nuxt App: A Data-Backed Guide

Most teams pick analytics based on name recognition. GA4 because everyone uses it. Plausible because a tweet said it was good. PostHog because the free tier looked generous.

That's backwards. The right analytics tool depends on what you need to track - and in Nuxt, on how well it handles SSR hydration and SPA navigation. We measured the transfer size, execution cost, and privacy profiles of every major provider. Here's what the data says.

What Do You Need?

Answer this before looking at any provider. Each step up adds complexity, weight, and cost.

1. "I want visitor counts." - Cloudflare Web Analytics or Plausible.
2. "I need custom events - clicks, downloads, signups." - Plausible, Umami, or Fathom.
3. "I need ad ROI and conversion funnels." - Fathom or GA4.
4. "I need session replays and user identity." - PostHog or LogRocket.
5. "I need to route data to 20 tools and a data warehouse." - Segment.

Most sites need tier 1 or 2. The temptation to jump to tier 5 because "we might need it" is expensive and usually wrong.

The Nuxt Analytics Matrix (2026)

Practical advice: If you're building a SaaS product, the hybrid stack in section 7 beats any single tool. If you're building a marketing site, Plausible is the right default.

Nuxt-Specific Gotchas

Nuxt's hybrid SSR/SPA architecture breaks standard analytics snippets in two ways.

SSR Hydration Double-Counting

Place a tracking snippet in app.html or useHead and it fires twice: once when the browser parses the server-rendered HTML, again when Vue hydrates. Your pageview counts inflate by up to 2x for initial loads. (Nuxt Scripts docs)

Nuxt Scripts loads analytics onNuxtReady by default. The script only runs once the app is fully interactive on the client.

SPA Navigation Tracking

Standard scripts listen for window.load. In a Nuxt SPA, the page never reloads as you navigate between routes. Without router integration, you're tracking one pageview per session regardless of how many pages the user visits.

Nuxt Scripts' registry composables (like useScriptPlausible) automatically hook into the Nuxt router and send virtual pageviews on every navigation.

Setup: 1 Line vs. ~40 Lines

// nuxt.config.ts
export default defineNuxtConfig({
  scripts: {
    registry: {
      plausibleAnalytics: { domain: 'example.com' }
    }
  }
})

// plugins/analytics.client.ts
import { defineNuxtPlugin, useRouter } from '#app'

export default defineNuxtPlugin(() => {
  // Must guard against SSR
  if (!process.client)
    return

  const script = document.createElement('script')
  script.src = 'https://plausible.io/js/script.js'
  script.setAttribute('data-domain', 'example.com')
  script.defer = true
  document.head.appendChild(script)

  // Must manually watch route changes
  const router = useRouter()
  router.afterEach((to) => {
    window.plausible?.('pageview', { u: to.fullPath })
  })
})

The manual approach also misses the hydration fix. You'd need to delay the script manually - and that's before handling consent, first-party proxying, or TypeScript types.

2026 Pricing at 100k Pageviews/Month

*PostHog stays free through 1M monthly events (PostHog Pricing), which covers most products until significant scale. Plausible Pricing · Fathom Pricing · Umami Pricing

GA4's "free" tier comes with tradeoffs: no raw data access without BigQuery (Vemetric Analytics Review, 2026), sampling at high volumes, and data retention limits. For teams that need SQL access to their own data, Umami (self-hosted) or Plausible are cheaper in the long run. Migrating off GA4 is also easier than it looks - both Matomo and Plausible support importing your historical GA data.

The Ad-Blocker Problem

25-45% of users block trackers (Blockthrough Ad-Block Report 2026). Scripts hosted on google-analytics.com, plausible.io, or any known tracker domain get blocked at the DNS or network level.

Nuxt Scripts' first-party mode proxies all analytics traffic through your own domain, saving 200-500ms in addition to recovering blocked data (Nuxt Scripts benchmarks):

export default defineNuxtConfig({
  scripts: {
    firstParty: true,
    registry: {
      plausibleAnalytics: { domain: 'example.com' }
    }
  }
})

Requests go to yoursite.com/_scripts/... instead of plausible.io. To a browser or DNS blocker, they're indistinguishable from regular site traffic. Data accuracy returns to near 100%.

This also has a privacy benefit: third parties see your server's IP instead of your users'.

The Hybrid Stack

You don't have to pick one tool. High-performing Nuxt teams typically run two:

• Plausible or Umami for traffic stats. Fast, readable dashboard that anyone on the team can use without training. Answers "how many people visited, from where, and which pages."
• PostHog for product and engineering. Session replay, feature flags, A/B tests, and funnel analysis. Answers "what did users do and where did they drop off."

The two tools don't overlap. Plausible/Umami covers the marketing and content team's questions. PostHog covers the product team's.

export default defineNuxtConfig({
  scripts: {
    firstParty: true,
    registry: {
      plausibleAnalytics: { domain: 'example.com' },
      posthog: { apiKey: 'phc_XXXXXX' }
    }
  }
})

Both load deferred, both get first-party proxying, and neither requires a manual router hook.

Making the Call

Three questions narrow it down:

1. Who reads the data? Marketing team - use Plausible. Engineers debugging sessions - use PostHog. Google Ads team - use GA4.
2. What's your compliance situation? EU users with no cookie consent UI - use Plausible or Umami (cookie-free). GDPR consent required - all providers work, Plausible and Umami need the least configuration.
3. What's your scale? Under 1M events/month - PostHog is free. Under 100k events/month - Umami Cloud is free. High-volume marketing site - Fathom's flat pricing avoids surprise bills.

For most Nuxt apps: start with Plausible for traffic stats. Add PostHog when you need product analytics. Use Nuxt Scripts for both - router integration, SSR safety, and first-party proxying with no glue code required.