Migrating to Plausible Analytics
Plausible is the landing pad for teams who want a working analytics stack on the next deploy, not a six-week implementation project. One JS tag, one dashboard, no cookie banner, EU residency by default, and a Goals UI that takes ten minutes to populate. This page is the cross-source map: where you are coming from determines which migration guide to follow, which auto-event mapper to use, and which reconciliation gotchas to expect. The destination is the same; the path is not. Read the source map first, then click into the matching pair page for the actual install.
From which source — pick your starting line
The five common origin points and their dedicated pair pages.
Coming from GA4
The most common path. Auto-event mapping covers around 87 of 120 typical GA4 events; the remainder become Plausible Goals via the dashboard UI or a Custom Events API call. Cookie banner removal is the largest behavioral change.
GA4 → Plausible →Coming from Universal Analytics
UA was sunset 2024-07-01, so this path is the historical-data export route, not a live cutover. Pull your UA export from BigQuery, shape it into Plausible's CSV import schema, and load. The live tracker step is a fresh install.
UA → Plausible (stub) →Coming from Mixpanel
The hard case. Mixpanel is event-first, Plausible is page-first; the model translation is lossy. Most teams end up keeping Mixpanel for product analytics and using Plausible for marketing-page analytics in parallel.
Mixpanel → Plausible (stub) →Coming from PostHog
Edge case. PostHog covers product analytics, session recording, and feature flags; Plausible covers none of those. The migration is rarely full replacement; usually it is "add Plausible for the marketing site, keep PostHog on the app."
PostHog → Plausible (stub) →Coming from Matomo
Rare and specific. Teams move from Matomo to Plausible to escape Matomo's surface area, not its data quality. Goals translate one-to-one; the harder lift is unlearning Matomo's funnel and segment tooling, neither of which Plausible has.
Matomo → Plausible (stub) →If your source is none of those — Adobe Analytics, Heap, Amplitude, Snowplow — file an issue on GitHub. The pair page roster is built by request; the next four are picked by reader email volume.
Plausible's structural choices
Three things Plausible does not do, by design, that confuse new arrivals. None of them are roadmap items; they are architectural commitments.
No cookies, ever. Plausible identifies a visitor by hashing IP + User-Agent + a daily-rotating salt. The hash expires every 24 hours. That means no client-id, no cross-day visitor identity, and no audience segmentation by behavior history. The trade is GDPR Article 6(1)(f) legitimate interest with no cookie banner — and the daily-rotating salt is what makes that legal opinion hold up. Re-introducing cookies would re-introduce the banner. They will not do it.
No multi-touch attribution model. Plausible captures source, medium, campaign, and referrer per pageview, but it does not stitch a multi-pageview journey into an attribution path. There is no "view the touchpoint sequence for users who converted" report, because there is no user-level identity to stitch on. If MTA is in your weekly workflow, the answer is Matomo, not Plausible.
No audiences or custom-dimension nesting. Goals can have a small number of custom properties (one or two key-value pairs). They cannot have nested user attributes, session-scoped dimensions, or computed cohorts. Goals are flat. The flatness is the privacy property; the moment you nest user attributes, you have a fingerprint.
These are not features that arrive in v3. They are commitments. The product is what it is on purpose. If you read the three constraints above and your gut response is "I need at least two of those," you are on the wrong destination page — go to Matomo or stay on GA4.
Hosted vs self-hosted Plausible
Plausible Cloud (hosted, EU-only servers, $9/mo at 100 K pageviews) and Plausible Community Edition (self-hosted, AGPL, free) are functionally similar but operationally very different.
| Dimension | Plausible Cloud | Plausible CE |
|---|---|---|
| Cost at 100 K pageviews | $9/mo | €20–40/mo VPS |
| EU residency | Frankfurt, ISO-27001 | your choice of provider |
| Operational overhead | none | ClickHouse + Postgres |
| Plugin compatibility | full | ~95 % (no SSO, no audit logs) |
| Suitable above 5 M pageviews | custom pricing only | needs dedicated DBA |
| Migration path between | bidirectional, well-documented | |
When CE makes sense. Three cases. (1) You have a strict no-third-party-cloud policy. (2) You operate at >10 M pageviews/mo where Cloud custom pricing exceeds the cost of running ClickHouse yourself. (3) You want to fork the dashboard and add a feature; the codebase is in Elixir, the frontend is React.
When Cloud makes sense. Everyone else. The operational cost of running ClickHouse — the schema migrations, the backup strategy, the on-call when a Linode goes down — is not visible in the €20/mo VPS line item.
Standard migration playbook from any source
The five steps generalize. Pair pages cover the source-specific traps.
- Map the destination footprint. Decide hosted vs CE. Decide single domain vs subdomains (Plausible has a "track subdomains" toggle in the dashboard; flip it on at install). Decide which Goals you need. List Goal names before you install.
- Install the JS tag. One line:
<script defer data-domain="example.com" src="https://plausible.io/js/script.js"></script>. Thedeferis non-negotiable; the script must not block render. Subdomain support, outbound-link tracking, and file-download tracking are opt-in via script variants — pick the variant that matches your event list. - Migrate Goals, then Custom Events. Goals first because they have a UI; create them by name in the dashboard, then fire
plausible('Goal Name')from your existing event handler code. Custom Events second; they need the events-API tag variant. From a GA4 source, the Event Mapping Wizard outputs the Goal-name list directly. - Run a two-week parallel period. Cookieless inflation is the headline reconciliation gap; expect Plausible to count 5–12 % more pageviews than GA4 on a site that ran a consent banner. Reconcile daily, document the gap, do not chase it.
- Cut over. Remove the source tracker. Plausible Cloud invoices monthly or annually; the annual prepay is 33 % off the monthly rate. Archive your source data — keep the BigQuery export of GA4 queryable for at least 12 months as the rollback path.
Engineering hours: 8–14 from a GA4 source, 14–20 from a Mixpanel source, 6–10 from a Fathom or simple-tracker source. Calendar time: two weeks of parallel run regardless of starting point. The methodology page documents the tolerance bands and reconciliation protocol; same numbers, every destination.
FAQ
Plausible Cloud or Community Edition — which should I pick?
Will Plausible work for an e-commerce site?
revenue and currency properties, and the dashboard has a revenue-by-Goal report. What it will not do is multi-touch attribution; revenue is credited last-click via UTM parameters only. If you run paid ads and need to credit assist channels, Plausible is the wrong tool — go to Matomo or keep GA4.Plausible pricing at scale?
Can I switch back to GA4 after migrating to Plausible?
gtag.js, the data resumes. What you lose is the Plausible-period data when you remove its tracker; export it via the Plausible API first if you want to keep it queryable. Switching back is uncommon; the more common pattern is realizing you needed Matomo all along, in which case the GA4 → Matomo guide applies, with Plausible as the intermediate step.