---
title: "Choosing Analytics for Your Nuxt App: A Data-Backed Guide"
description: "Stop choosing analytics by brand. We measured transfer size, execution cost, and privacy profiles of every major provider to help you pick the right one for your Nuxt app."
canonical_url: "https://scripts.nuxt.com/learn/choosing-analytics-nuxt"
last_updated: "2026-03-18"
---

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."** - <link-script slug="cloudflareWebAnalytics">



</link-script>

 or <link-script slug="plausibleAnalytics">



</link-script>

.
2. **"I need custom events - clicks, downloads, signups."** - <link-script slug="plausibleAnalytics">



</link-script>

, <link-script slug="umamiAnalytics">



</link-script>

, or <link-script slug="fathomAnalytics">



</link-script>

.
3. **"I need ad ROI and conversion funnels."** - <link-script slug="fathomAnalytics">



</link-script>

 or <link-script slug="googleAnalytics">



</link-script>

.
4. **"I need session replays and user identity."** - <link-script slug="posthog">



</link-script>

 or LogRocket.
5. **"I need to route data to 20 tools and a data warehouse."** - <link-script slug="segment">



</link-script>

.

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)

<recommendation-table>



</recommendation-table>

**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, <link-script slug="plausibleAnalytics">



</link-script>

 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](https://scripts.nuxt.com/docs/guides/unhead))

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.

<warning>

Both issues affect every analytics provider. Don't assume your current setup is tracking correctly without verifying against server-side logs.

</warning>

## Setup: 1 Line vs. ~40 Lines

<code-group>

```ts [Nuxt Scripts (Recommended)]
// nuxt.config.ts
export default defineNuxtConfig({
  scripts: {
    registry: {
      plausibleAnalytics: { domain: 'example.com' }
    }
  }
})
```

```ts [Manual plugin]
// 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 })
  })
})
```

</code-group>

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

<pricing-table>



</pricing-table>

<chart-pricing>



</chart-pricing>

GA4's "free" tier comes with tradeoffs: no raw data access without BigQuery ([Vemetric Analytics Review, 2026](https://vemetric.com/blog/analytics-comparison-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](https://matomo.org/docs/google-analytics-importer/) and Plausible support importing your historical GA data.

## The Ad-Blocker Problem

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

<chart-consent-impact>



</chart-consent-impact>

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](https://scripts.nuxt.com/benchmarks)):

```ts [nuxt.config.ts]
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'.

<note>

First-party mode supports Google Analytics, GTM, Meta Pixel, Plausible, Fathom, Segment, Clarity, Hotjar, and more.

</note>

## The Hybrid Stack

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

- ** or ** 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."
- **** 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. <link-script slug="plausibleAnalytics">



</link-script>

/:LinkScript{slug="umamiAnalytics"} covers the marketing and content team's questions. <link-script slug="posthog">



</link-script>

 covers the product team's.

```ts [nuxt.config.ts]
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 <link-script slug="plausibleAnalytics">



</link-script>

. Engineers debugging sessions - use <link-script slug="posthog">



</link-script>

. Google Ads team - use <link-script slug="googleAnalytics">



</link-script>

.
2. **What's your compliance situation?** EU users with no cookie consent UI - use <link-script slug="plausibleAnalytics">



</link-script>

 or <link-script slug="umamiAnalytics">



</link-script>

 (cookie-free). GDPR consent required - all providers work, Plausible and Umami need the least configuration.
3. **What's your scale?** Under 1M events/month - <link-script slug="posthog">



</link-script>

 is free. Under 100k events/month - <link-script slug="umamiAnalytics">



</link-script>

 Cloud is free. High-volume marketing site - <link-script slug="fathomAnalytics">



</link-script>

's flat pricing avoids surprise bills.

For most Nuxt apps: start with <link-script slug="plausibleAnalytics">



</link-script>

 for traffic stats. Add <link-script slug="posthog">



</link-script>

 when you need product analytics. Use Nuxt Scripts for both - router integration, SSR safety, and first-party proxying with no glue code required.