Statnive WordPress Plugin vs Statnive Live: Which One Is Right for Your Site?

Two products, one privacy contract

Most analytics vendors ship one product and stretch it to fit every customer. We ended up with two on purpose.

The Statnive WordPress plugin is what you install from WordPress.org, activate, and forget about — it lives inside your WordPress install and writes analytics straight to your site’s database. Statnive Live is a separate, standalone analytics platform: a single Go binary plus ClickHouse, designed for sites that don’t fit on WordPress (or that have grown past what shared hosting can comfortably push). Both products are cookieless, cookie-banner-free by default, and respect DNT and Sec-GPC out of the box. Same privacy contract, two deployment shapes.

This guide is the honest version of the question every Statnive plugin user eventually asks: should I move to Live, or keep using the plugin? We’d rather you stay on the free plugin than buy something you don’t need, so the decision matrix below leans on concrete signals — traffic, hosting, stack, audit posture — instead of pricing-page pressure.

What’s the same on both products

The privacy invariants are identical because they are the product. Both the plugin and Live:

ship no cookies, no localStorage, and no sessionStorage — you can verify this by opening DevTools → Application on any site running either tracker
use daily rotating salts so the same visitor produces a different hash each day; cross-day tracking is impossible by construction
never persist raw IP addresses — the IP enters the pipeline only for the GeoIP lookup, then is discarded before any row is written
do no fingerprinting — no canvas, WebGL, font enumeration, or navigator.plugins probing
honour DNT and Sec-GPC by default
use SHA-256 / BLAKE3 only in any privacy or identity path — no MD5, no SHA-1
enforce a CI-level tracker-size budget so the script you ship to your visitors never bloats unnoticed

If those are your reasons for picking Statnive in the first place, neither product is a downgrade. The choice below is about deployment shape and scale, not principles.

The decision matrix

	Statnive WordPress plugin	Statnive Live
Deployment	WordPress plugin from WP.org. Activate, done.	Single Go binary + ClickHouse. Self-host on any Linux box, or use the managed SaaS.
Traffic ceiling	Bounded by your WordPress host’s MySQL / MariaDB. Comfortable on shared hosting up to a few thousand daily visitors; degrades on contention without page caching.	Designed ceiling 200 M events/day per node on an 8-core / 32 GB box; SaaS floor is a Hetzner AX42 (8c / 64 GB).
Ops complexity	Zero — your WP host already runs PHP and MySQL.	You (or we) run a server: ClickHouse, TLS, backups, periodic GeoIP database drops.
Ecosystem fit	WordPress only. PHP 8.0+, WordPress 6.2+.	Any stack. The tracker is a first-party `<script>` snippet — Astro, Rails, Django, mobile webviews, anywhere a browser can fetch a script.
Multi-site	One plugin install per WordPress site.	Multi-tenant from day one — every event carries a `site_id`; one Live deployment can serve many sites.
Pricing model	Flat annual: Free (includes WooCommerce Revenue Report since v1.0.0), Growth ($99/yr — planned 2026) for anomaly alerts, Slack/Telegram, ad-spend MER, AI executive summary, Meta CAPI. Agency ($199/yr — planned 2026) for heatmaps + white-label. 14-day money-back on paid plans.	Traffic-based: Starter / Growth / Business scaling with monthly pageviews from $9/mo at 10k PV up to $339/mo at 10M, plus a contact-us Enterprise tier. Annual billing = 2 months free. 30-day free trial, no credit card.
Dashboard	React 18 + TanStack Router/Query/Table inside `/wp-admin`.	Preact + `@preact/signals` + uPlot, served by the binary at `/dashboard`; 16 KB gzipped initial JS budget enforced in CI by `size-limit`.
DPA posture	You self-host, so you’re the controller and we’re not your processor. No Statnive ↔ you DPA needed.	Customer is controller, Statnive Live SaaS is the processor. Art. 28(3) DPA on every plan, signed 2026-04-24.

Two cells in that table are the decision-makers for most readers: traffic ceiling and ecosystem fit. The rest are consequences.

The Statnive WordPress plugin is right for you if…

The plugin is built for WordPress sites that fit comfortably inside their hosting plan. You should stay on (or start with) the plugin if any of these are true:

You run a WordPress site and your stack ends there. You don’t have a separate Astro front, a mobile app, or a Rails admin to instrument.
Your traffic is bounded — small business sites, content blogs, B2B marketing sites, niche publishers. Anything where a few thousand daily visitors is “a good day”.
You don’t run dedicated infrastructure. Your WordPress is on shared hosting, a managed WP host, or a small VPS. Standing up a separate ClickHouse process is more ops than the analytics will return.
You want WooCommerce revenue tracking. As of v1.0.0, the Free plugin ships a dedicated Revenue Report (5 KPIs + Revenue by Channel + Top Products + Cart-to-Purchase Funnel). Form integrations (Contact Form 7, Gravity, WPForms) and WPML/Polylang multilingual support are scoped for the Growth tier — planned for 2026.
You want everything to live in your existing database. All analytics data stays in your site’s MySQL/MariaDB, alongside posts and orders, and exits with the same backups.

The plugin is GPL-2.0-or-later, free on WordPress.org, and the Free tier ships the dashboard, real-time view, channel grouping (8 channels including a dedicated AI Assistants channel covering 14 hosts), REST API, custom events, configurable retention up to 10 years, and (since v1.0.0) the full WooCommerce Revenue Report. If that fits, you’re done.

Statnive Live is right for you if…

Live is built for sites where the plugin’s “WordPress + MySQL” shape stops fitting. You should look at Live if any of these are true:

Your traffic spikes hard. A million page views in a minute is a real load profile for high-traffic publishers, streaming pages, and event-driven landing pages — and “your WordPress MySQL” is not where you want that ingest path.
You run more than WordPress. A single Live deployment can ingest from any stack — drop a 1.4 KB script tag onto an Astro site, an Express app, a static landing page, a mobile webview. The tracker doesn’t know what served the HTML.
You have multiple sites. Multi-tenant site_id is in every Live table from day one. One Live binary can serve a portfolio of brands or a network of sites without per-site installs.
You’re in a regulated industry that needs a signed processor agreement. Live SaaS ships an Art. 28(3) DPA on every plan, signed 2026-04-24, with a sub-processor list updated within 7 days of any upstream change. EU/EEA-only data processing on Netcup VPS in Nuremberg, Germany — no Chapter V transfer.
You have an ops team (or want one in the loop). Running a Go binary alongside ClickHouse is one server’s worth of work — TLS, backups, GeoIP drops. If you’d rather skip the ops, the managed SaaS in Nuremberg does it for you.

The Live tracker is 1,394 bytes minified / 687 bytes gzipped as of writing — measured, not aspirational, and asserted in CI by a Go test that fails the build if the embedded bytes exceed a 1,500 B / 700 B budget. The dashboard shell sits inside a 16 KB gzipped initial-JS budget on size-limit. The full binary embeds the dashboard SPA, the tracker JS, and all migrations via go:embed, so deploying Live is “copy a binary, run it” — no CDN, no external assets to load.

This isn’t unique posturing. Matomo’s official documentation has long given the same advice for its own product — “if you have a high traffic website or manage multiple sites with WordPress MultiSite, we recommend installing Matomo On-Premise or signing up to Matomo Cloud and installing the Connect Matomo plugin instead of the standard WordPress plugin” — and Slimstat, BlogVault, and TeamUpdraft all frame the same architectural inflection point: in-WordPress analytics adds server load to every page, which becomes the bottleneck before the plugin itself does. The Statnive plugin is engineered to defer most of its work, but physics is physics: at high concurrency without caching, your WordPress MySQL becomes the analytics database whether you want it to or not.

Can I run both at the same time?

Yes — and for some readers it’s the right move during a migration.

The two products share the privacy invariants and the wire schema, but their stores are separate by construction: the plugin writes to your WordPress MySQL/MariaDB; Live writes to a ClickHouse process running alongside its Go binary. They don’t share globals, don’t import each other, and don’t compete for storage. You can drop both <script> tags onto a page and watch them work in parallel. Both stay cookieless, so neither side adds a cookie banner to the other’s life.

When that pattern is useful:

Sanity-checking a migration. Run both for a week before flipping the canonical dashboard from the plugin to Live; verify the numbers line up.
Splitting concerns. Keep the plugin as the WP-admin-side dashboard for marketers, run Live as the central pipe for an Astro front-end and a mobile app — same privacy contract, different consumers.
Holding onto historical data. The plugin’s history lives in your WP database; adding Live alongside it doesn’t move that data. It’s still there next year if you need it.

A migration path that doesn’t lose data

The plugin is not going away when Live launches. The pricing page is explicit: “Two products, one privacy contract. Free + paid tiers for the WordPress plugin. Traffic-based plans for statnive.live SaaS.” Both ship and stay maintained.

If you do want to graduate from the plugin to Live, the path looks like:

Pick a deployment shape. Self-host the binary on a server you control, or use the managed Nuremberg SaaS. The same binary supports both modes, with the same Go tracker.js embedded.
Drop the Live <script> tag alongside the plugin’s tracker. Run them in parallel for as long as you want.
When the numbers reconcile, point your team at Live’s dashboard and stop linking to /wp-admin/admin.php?page=statnive. The plugin’s data stays in your WordPress database — no migration of historical rows, no risk of losing what’s there.
(Optional) Deactivate the plugin once the marketing team is happy with Live’s dashboard. Or leave it active as a backup ingest path.

There is no “plugin sunset”, no forced migration, no data lock-in.

Common questions

Is the WordPress plugin going away?

No. The plugin is a first-class product with its own roadmap and its own Free tier on WordPress.org. Both products share the privacy contract; neither is the “real” Statnive.

Will the plugin get all of Live’s features?

Some features are architectural — they only make sense when there’s a ClickHouse process behind the dashboard. Funnels, Looker Studio, scheduled raw event exports, the Stats API at 600 req/h are Live-only because they need columnar storage to be honest. Other features (real-time, channel grouping, custom events, REST API) ship in both.

Pricing comparison?

The plugin is flat annual: $0 Free (includes the v1.0.0 WooCommerce Revenue Report), $99/yr Growth (planned 2026 — anomaly alerts, Slack/Telegram, ad-spend MER, AI executive summary), $199/yr Agency (planned 2026 — heatmaps, white-label). Live is traffic-based, $9–$339/mo across Starter/Growth/Business at 10k → 10M pageviews, with Enterprise above. Annual billing on Live is 2 months free; every paid Live tier ships with a 30-day free trial, no credit card.

Can I keep my historical data?

Yes. The plugin stores its history in your own MySQL/MariaDB — adding Live alongside it doesn’t move or delete those rows. Inspect wp_statnive_* tables before and after; they’re untouched.

Do I need a DPA on the plugin?

No DPA between you and us, because the plugin is fully self-hosted — Statnive isn’t a processor of your visitors’ data. You still need your own visitor-facing privacy notice (the standard “we operate this site” notice), but there is no third-party analytics relationship to contract.

For Live SaaS, the customer is the controller and Statnive Live is the processor; an Art. 28(3) DPA is signed at signup. A self-hosted Live deployment is, again, controller-only — same posture as the plugin.

What happens if I outgrow the plugin?

Read the decision matrix above. Most plugins users won’t outgrow it; the ones who do tend to know it months before the analytics start hurting (a publisher hitting six-figure DAU, a SaaS spinning up a marketing-only Astro site, a regulated company asking for a signed DPA). When that happens, Statnive Live is built for the next stage.

The bottom line

Two products, same privacy posture. The Statnive WordPress plugin is the right answer for most WordPress sites — small ops surface, free tier, lives inside the database you already manage. Statnive Live is for the cases where the plugin’s “WordPress + MySQL” shape becomes the bottleneck: high-traffic publishers, multi-stack teams, multi-site portfolios, regulated industries that need a signed processor contract.

Don’t switch unless one of the Statnive Live is right for you if… signals matches you. If they don’t, the plugin is the cheaper, simpler answer — and it stays on the same privacy contract Live ships on.

If they do, Statnive Live is coming soon at statnive.com/live. Until then, the Statnive WordPress plugin is on WordPress.org for free, the features page walks through what the plugin ships, and the pricing page lays out both products side by side.

Read the rest of the series

This is the first of four pieces introducing Statnive Live. Each can be read on its own; together they cover the decision, the legal posture, the deployment shape, and the engineering:

Statnive WordPress plugin vs Statnive Live — this post. Decision matrix, “right for you if…” signals on each side, migration path.
GDPR-Compliant Web Analytics in 2026: A Practical Guide for European Site Owners — what GDPR, DSGVO, and Schrems II actually require from a 2026 analytics stack, with case-IDs and dates.
Own Your Analytics Data: Self-Hosted vs Private EU SaaS in 2026 — threat model on each side, decision framework, migration path between self-hosted and private EU SaaS.
A Million Page Views a Minute, on a Single Server — the engineering deep-dive: 687-byte tracker, WAL-first ingest, three AggregatingMergeTree rollups + HyperLogLog, and the 1-hour-delay trade-off named openly.