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 Analytics.
2. "I need custom events - clicks, downloads, signups." - Plausible Analytics, Umami Analytics, or Fathom Analytics.
3. "I need ad ROI and conversion funnels." - Fathom Analytics or Google Analytics.
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 Analytics 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

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 Analytics or Umami Analytics 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 Analytics/:LinkScript{slug="umamiAnalytics"} 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 Analytics. Engineers debugging sessions - use PostHog. Google Ads team - use Google Analytics.
2. What's your compliance situation? EU users with no cookie consent UI - use Plausible Analytics or Umami Analytics (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 Analytics Cloud is free. High-volume marketing site - Fathom Analytics's flat pricing avoids surprise bills.

For most Nuxt apps: start with Plausible Analytics 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.