Migrate from Google Analytics to Plausible

Migrate from Google Analytics to Plausible: what the move involves

Most teams arrive here because of a GA4 renewal or cost question, a data residency or consent concern, or a wish for a simpler traffic dashboard. The move is mainly a self-hosting, tag replacement and expectations exercise: you stand up Plausible Community Edition, swap the Google tag for the Plausible script, and optionally import a short, aggregated slice of GA4 history. Raw GA4 hits do not come across, so plan for a new baseline rather than a continuous series of data. The work usually falls to the web or platform team, who run the containers, DNS, TLS and the script rollout, together with the marketing owner of GA4, who decides which reports, goals and campaign tags must still be answered. Effort and risk rise with the number of GA4 properties (the import supports up to 5 per site), the number of goals and conversion events, and any integrations that read GA4 today, such as Google Ads audiences, Looker Studio dashboards or BigQuery exports. Inventory these before you start, and confirm the Google OAuth setup your team needs for the import with the Plausible Community Edition wiki.

Plausible Community Edition is community supported only. Your team owns installation, upgrades, capacity planning, uptime, backups and security patches, and security fixes reach you only when you apply a release. The project publishes a long-term release twice a year, so schedule a recurring upgrade window and assign an owner for release notes, the database backup and restore test, and monitoring of the containers. Plausible Cloud, by contrast, ships updates several times a week, and it also lacks none of the Community Edition gaps only in the sense that funnels, user journeys, ecommerce revenue goals, single sign-on and the Sites API are not in the self-hosted build. Before cutover, ask the marketing owner to sign off a written list of reports that will be lost or changed, and confirm with the vendor or your own testing which of your goals can be recreated as custom events. Run both tools in parallel for long enough to compare traffic totals, and agree in advance how far apart the numbers may be before anyone changes a campaign report.

Which GA4 capabilities map to Plausible and which need rework

This table maps common GA4 reporting to Plausible Community Edition and marks each item as clean, needs rework or gap. Read the gap rows first, since they show what history and reports will not carry over and what Cloud-only features you would lose by self-hosting.

GA4 capability	Plausible Community Edition	Status
Traffic and pageview reporting	Built-in dashboard for visitors, pageviews and bounce rate, with no cookies and no consent banner needed	Clean
Traffic sources and referrers	Source and referrer reports are available, but UTM source detail from GA4 history is not imported	Needs rework
Top pages and entry pages	Page reports work for new data; exit pages from GA4 history are not imported	Needs rework
Goals and conversions	Goals are recreated by hand in Plausible after cutover, using custom event names that match your site tracking	Needs rework
GA4 historical data	Imported as daily aggregates up to the first native Plausible visitor, within GA's own retention range, for up to 5 properties per site	Needs rework
Search Console keyword data	Available through the Google integration in the Community Edition wiki once GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET are set	Clean
Ecommerce revenue	Not imported from GA4 history, and ecommerce revenue goals are Cloud-only	Gap
UTM sources in imported history	Not imported; check whether new campaign tagging reports meet your needs after cutover	Gap
Scroll depth and browser versions	Not imported from GA4 history; confirm current Community Edition support before relying on it	Gap
Unique visitors over long ranges	Imported uniques are approximated by summing daily uniques, so multi-month totals can differ from GA4	Needs rework
Funnels, user journeys and Sites API	Cloud-only features, not in Community Edition; plan other tools or Plausible Cloud if you rely on them	Gap
Looker Studio connector	Cloud-only, so Community Edition needs another export path to reach Looker Studio dashboards	Gap

How the migration sequence runs from inventory to decommission

The sequence moves analytics from GA4 to a self-hosted Plausible Community Edition in controlled stages, so each stage leaves a verified output before the next one starts. Teams keep Google Analytics running until the Plausible numbers are checked and the historical import is in place.

Inventory GA4 properties, goals and integrations
The analytics owner lists every GA4 property, data stream, conversion event, custom event, audience and linked service such as Google Ads, Search Console and BigQuery, then notes which teams use each report. Confirm with the marketing and product owners which goals they rely on, since Plausible goals are rebuilt by hand and ecommerce revenue does not import. The output is a signed-off inventory that marks each item as carried over, rebuilt, dropped or kept in GA4.
Run a pilot Community Edition install
An infrastructure engineer deploys the Plausible community-edition repository on a test host using Docker and Docker Compose. Check the host against the stated requirements first: a CPU that supports SSE 4.2 or NEON, which ClickHouse requires, and at least 2 GB of RAM. Confirm the install by logging in, adding one test site and sending a page view from a staging page. The output is a working instance with a documented version, configuration file and backup plan, since the operator also owns upgrades, uptime and security patches.
Configure the Google OAuth client
A Google Cloud administrator registers an OAuth client for the Plausible instance, then sets GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET in the deployment configuration. Enable the Google Analytics, Analytics Reporting, Analytics Admin and Analytics Data APIs in the same project. Restart the stack and confirm the Google integration appears in the site's Imports and Exports settings. The output is a Google connection that can read the GA4 properties in scope, and a record of which Google account and project own it.
Import GA4 history as daily aggregates
A Plausible site owner runs the GA4 import from the site settings for each property in scope, up to the five properties the import supports per site. The import covers the period from the first GA visitor up to the first native Plausible visitor and is limited by the range GA's own data retention allows. Compare imported totals for a sample month against the GA4 standard reports, and record that unique visitors over longer periods are approximated by summing daily uniques. The output is imported history with a reconciliation note listing the known gaps.
Run GA and Plausible in parallel
The team keeps the existing GA tag live and adds the Plausible script to the same pages, usually through the tag manager or the template that already loads analytics. For a defined period, analysts compare daily visits, top pages, sources and goal counts between the two tools and explain each difference, such as bot filtering or consent-related blocking. Confirm that goals fire on the same user actions in both tools. The output is a parallel-run log that signs off the numbers for the reports the business depends on.
Cut over the tag to Plausible
A web engineer removes the gtag snippet from the site template and tag manager container after the parallel-run sign-off, leaving the Plausible script as the only analytics tag. Check that no page still loads the GA snippet by crawling key templates and checking the browser network requests. Confirm that dashboards, alerts and exports now point to the Plausible site. The output is a release record showing the tag change, the pages checked and the rollback path if a template was missed.
Decommission Google Analytics and keep an export
After a period of stable Plausible reporting, the analytics owner exports the reports the business still needs from GA4 and archives them with the import reconciliation. Remove remaining GA properties, linked Google Ads and BigQuery links where no team depends on them, and revoke the OAuth access once the historical import is complete. Confirm with Google's documentation that the data you need is exported, since unexported Universal Analytics data was permanently deleted after the retention window. The output is an archived GA export, a decommission record and a scheduled review of the Plausible upgrade cadence.

How the move differs for a single site, several properties or a regulated estate

A single website with one GA4 property is the simplest case. The import path is direct: you register a Google OAuth client for your Community Edition instance, set the Google client configuration, enable the required Google APIs and connect the GA4 property from the site's Imports and Exports settings. The GA4 history then arrives as daily aggregates, starting from the first GA visitor and stopping at the first native Plausible visitor, so the cutover date is the point where you should confirm the overlap is clean.

Import scope: one GA4 property fits well within the documented limit of up to 5 GA properties per site, so no consolidation step is needed.
History window: the import is bounded by the range GA's own data retention allows, so confirm how far back your property still holds data before you plan the cutover.
Tag swap: replace the gtag snippet with the Plausible script on every template that loads it, then verify pageviews in both tools for a short overlap.
Lost detail: ecommerce revenue, UTM sources, browser versions, exit pages and scroll depth do not come across, so export any reports you still need first.

Before cutover, ask your operator to confirm the Google integration is working and that the imported daily totals match GA for a sample of recent days.

Which data moves, which integrations to rebuild and which exports to use

Plausible Community Edition moves less history than most teams expect, and the rest is rebuilt by hand. The cards below separate what the Google integration imports, what it leaves behind, and the one documented route for moving data later.

GA4 history as daily aggregates

The GA4 import copies historical stats from the first GA visitor up to the first native Plausible visitor, stored as daily aggregates rather than individual visits. Check the start and end dates against your own cutover plan, since the overlap window is set by when the Plausible site begins collecting. Expect report totals to line up with GA4 by day, but do not expect per-visit drill-downs for the imported period. Confirm the exact import window in the Plausible docs before scheduling the cutover.

Five-property limit and retention bounds

A single Plausible site can import from up to 5 GA properties, so consolidate any multi-property setup before you start. The import is also capped by the range that GA's own data retention allows, which means older history may already be gone from Google. Map each GA property to a Plausible site, list the date range you need for year-over-year reports, and confirm retention in the GA admin settings before you assume the history exists.

Search Console keyword data

The same Google OAuth client that powers the GA4 import also enables Search Console keyword data in Plausible, configured from the site's Imports and Exports settings. This is a separate data source from GA, so it does not depend on GA4 history being present. Verify that the Google account used for the OAuth consent has access to the right Search Console property, and that the API projects are enabled before you rely on keyword reports for SEO decisions.

Goals recreated by hand

Goals and custom events do not arrive with the GA4 import, so each conversion must be defined again in Plausible and matched to the events your site already sends. Start from a list of the GA events your marketing team actually reports on, then name each goal to match its GA counterpart so historical comparisons stay readable. Ecommerce revenue cannot be imported at all, so any revenue goal will need a separate plan.

GA tag replaced by the Plausible script

The gtag snippet is removed from every template and replaced with the Plausible script, which is the step that starts new data collection on your self-hosted instance. Remove the GA tag from your tag manager as well, or both tools will record duplicate visits. Check that the script loads on every page type, including single-page app routes, and that your consent banner no longer lists GA as an active processor if Plausible is the only analytics tool left.

Community Edition export as the only documented path

Plausible's self-hosted page documents one data movement path: Community Edition operators can export data to Plausible Cloud and import it back. Treat this as the only route the vendor describes, and test it on a copy of your data before relying on it for a move in either direction. Ask Plausible to confirm current limits, file formats and any gaps for your data volume, since the documented path does not cover moving history into other open-source tools.

What the GA4 import does to your historical numbers

Plausible's GA4 import does not copy your raw GA4 events into Plausible. It brings historical stats in as daily aggregates, running from the first GA visitor up to the first native Plausible visitor, so the imported history is a set of per-day totals rather than individual sessions. Anything that needs event-level detail, such as drill-downs into a single visit or custom segments built on raw hits, will not exist for the imported period. Plan for that before stakeholders ask for it. Ecommerce revenue, UTM sources, browser versions, exit pages and scroll depth are also missing from the imported history, so any report that depended on them needs a separate reference source for the old period.

Unique visitors need particular care. Plausible approximates unique visitors over longer ranges by summing the daily unique counts, so a visitor who arrives on several days is counted once per day rather than once for the whole period. Over a month or a quarter, that approximation will usually produce a higher unique figure than GA4 reports for the same range, and the gap widens for audiences that return often. Pageviews and daily totals are a more direct comparison. Expect differences in bot filtering, consent-dependent collection and session logic as well, because the two tools count visits by different rules.

Before cutover, export the GA4 figures you rely on for the same date ranges, then run the same reports in Plausible and record each difference with its cause. Confirm with your GA4 administrator how far back the export can reach under your property's data retention settings, since the import is limited by that range. Then agree a written reporting baseline with finance, marketing and the executives who read these numbers: which tool is the system of record for each period, which metrics are compared across the boundary, and how year-on-year trends will be presented. A baseline agreed in advance prevents a discrepancy from being read as a traffic drop.

What usually goes wrong and how to prevent it

Most Plausible migrations from GA4 stall in the same few places: the import scope, the Google setup, the release process, the host size, the tag cutover and the goal definitions. Each card below names one of these failure points and the check that catches it before traffic data is lost or double counted.

Assuming revenue and UTM detail will carry over

The GA4 import brings in daily aggregates of traffic, but it cannot import ecommerce revenue, UTM sources, browser versions, exit pages or scroll depth. If marketing reports depend on any of these, the imported history will look incomplete from day one. Before the cutover, list every GA report your stakeholders use and mark which ones the import covers. Keep the GA4 property readable and exported for the rest, and confirm with the Plausible docs which fields are supported at the time you migrate.

Skipping the Google API setup

The historical import only runs after you register a Google OAuth client, set GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET in the configuration, and enable the Google Analytics, Analytics Reporting, Analytics Admin and Analytics Data APIs. Teams often configure the Plausible container, see no import option, and assume the feature is missing. Check the Google Cloud project, the OAuth consent screen and the API enablement first, and confirm the account used has access to the GA4 property.

Treating security fixes as automatic

Community Edition is a long-term release published twice per year, is supported by the community only, and receives security fixes only when the operator applies the release. The v3.2.1 security release was published on May 15, 2026, after v3.2.0 on January 26, 2026. A host that stays on an older tag keeps the exposure, even though Plausible Cloud has already moved on. Assign an owner for watching the releases page, schedule a test upgrade on a staging copy, and record the version each environment runs.

Undersizing the host

The Community Edition repository requires Docker, Docker Compose, a CPU with SSE 4.2 or NEON support because ClickHouse needs it, and at least 2 GB of RAM. Two gigabytes is the stated minimum, not a sizing guide for a busy site. Teams that deploy on the smallest virtual machine often see the analytics stack compete with the website for memory. Ask your platform team to size the host against your own monthly pageview volume and to watch memory and disk growth for the first weeks after cutover.

Running the GA tag and Plausible script together

If the gtag snippet stays in the templates after the Plausible script goes live, every visit is counted twice, once in each tool, and the two dashboards drift apart with no visible error. This is common when the script is added through a tag manager and the old tag is never removed. Run a single release that removes the GA tag and adds the Plausible script, then compare pageviews for a few days on one browser and one page. Check the tag manager container for leftover GA configuration tags as well.

Losing goal definitions in translation

GA4 conversions, events and their parameters do not map one to one onto Plausible goals. Custom events must be recreated in Plausible and the tracking calls in the site code must fire the same event names. Ecommerce revenue goals are not available in Community Edition, so purchase tracking needs a different plan. Export the list of GA4 conversions, write down the trigger for each, and test every recreated goal in a staging environment before you rely on it for reporting.

Questions buyers ask before moving from GA4 to Plausible

What does a GA4 to Plausible migration cost, and what drives it?

The cost is mostly labor plus hosting, and the facts you need to size it are in your own environment. Plausible Community Edition is AGPLv3 and carries no license fee, so you pay for the server that runs it (the repository requires Docker, Docker Compose, a CPU with SSE 4.2 or NEON, and at least 2 GB of RAM), operator time for installation, upgrades, backups and monitoring, and implementation work. Implementation covers the Google project setup, goal rebuilding, replacing the GA tag and a parallel run. The main cost drivers are the number of sites and GA4 properties (up to 5 properties per site are supported for import), how many goals and events you rebuild, and how much your team wants to keep both tools running. Ask any quote to itemize these components separately and to state which costs recur each year.

How long does a migration take, and what sets the duration?

Duration depends on the number of sites, the number of GA4 properties to import, the goal and event inventory, and how many approvals sit in the path. The historical import itself is a background job bounded by the range GA's own data retention allows, so the setting you control is how much history you want and whether the parallel run is long enough to compare traffic. Plausible's GA4 import works from the first GA visitor up to the first native Plausible visitor, which means the Plausible install date defines where the import stops. Agree on a timeline in writing before work starts, and confirm with the implementer how the Google project setup and the DNS change will be scheduled.

What does the migration need from our team?

Plan for four roles to be named before work starts. A DNS and hosting owner must point a subdomain at the server and manage TLS. A Google Cloud project owner must create the OAuth client, set GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET, and enable the Google Analytics, Analytics Reporting, Analytics Admin and Analytics Data APIs. A web or tag owner must replace the gtag snippet and any tag manager triggers. A marketing lead must sign off on which goals, reports and historical gaps are acceptable, since some GA4 data will not carry over. Confirm access and who holds the credentials before the first sprint.

Can our own team run the migration without outside help?

A technical team with Linux, Docker and DNS experience can install Plausible Community Edition from its repository and follow the Google integration wiki. The harder parts are the operating work and the decisions: sizing the server, setting up backups, applying each twice-yearly release promptly, and mapping goals and events so the reports still answer the questions marketing asks. Community Edition is community supported only, and security fixes arrive only when the operator applies the release. If your team lacks capacity for that ongoing work, a fixed-scope implementation can cover setup, goal rebuilding, the import and handover documentation, with retainers available for upgrades and support. Decide which part you own before you ask for a quote.

Does our GA4 history carry over completely to Plausible?

No. Plausible's GA4 import brings history in as daily aggregates, not raw events, and it cannot import ecommerce revenue, UTM sources, browser versions, exit pages or scroll depth. Unique visitors over longer periods are approximated by summing daily uniques, so totals will differ from GA4's own figures. Plan to keep the GA4 property readable for reference, export any reports you need to keep before the switch, and tell stakeholders which dashboards will show a gap. Confirm each report you depend on against the import limits before cutover.

Can we move from Community Edition to Plausible Cloud later?

Yes, the Community Edition documentation says operators can export and import data to and from Plausible Cloud. Confirm the current export format, the scope of what moves (aggregates, goals and sites), and any features you depend on, because some are available only in Cloud, including marketing funnels, user journeys, ecommerce revenue goals, single sign-on, the Sites API and the Looker Studio connector. Ask for a written test export of one site before you commit to a move in either direction, and check the release notes for the Community Edition version you run.

Does the import keep the same unique visitor counts and tracking setup?

Not exactly. Because unique visitors are approximated from daily uniques, historical totals for longer ranges will not match GA4 exactly, and the Plausible script works without cookies, so the figures reflect a different measurement method from GA4. Keep the old and new numbers side by side during the parallel run, document the expected variance for each report, and confirm the agreed method in writing. Compliance teams should also review how the cookieless approach fits their consent position with their own legal counsel.

What to confirm with Plausible and your environment before you commit

Start with the release you will actually run. Plausible Community Edition is published as a long-term release twice per year, is supported by the community only, and receives security fixes only when the operator applies the release. Confirm the current release and its upgrade procedure in the Plausible Community Edition wiki and the plausible/analytics releases page before you deploy, and write down who in your team owns the upgrade calendar. The releases page lists v3.2.1 as a security release published on May 15, 2026, after v3.2.0 on January 26, 2026, so a deployment built from an older tag should be checked against that list. Plan for the upgrade as recurring work, because the cloud service ships updates several times per week and your instance will not.

Next, confirm the Google side in your own Google Cloud project. The GA4 import needs a Google OAuth client, the GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET settings, and the Google Analytics, Analytics Reporting, Analytics Admin and Analytics Data APIs enabled. Check the OAuth consent configuration and the account that will grant access, since it must hold read access to every GA4 property you plan to import, and remember that a single site can import up to 5 properties. Also confirm the historical range you need against your GA4 property's own data retention setting, because the import cannot reach back further than GA keeps data. Test one property end to end on a staging site and compare totals for a short window before you commit to the full import.

Then decide your consent position and size the host. Ask your legal or privacy team whether analytics on your sites needs a banner, because Plausible states that it uses no cookies and therefore requires no cookie banner, but whether that holds for your use case under your national rules is a question for your counsel and your supervisory authority, not for a vendor page. For sizing, the repository requires Docker, Docker Compose, a CPU with SSE 4.2 or NEON support for ClickHouse, and at least 2 GB of RAM, but those are minimums. Measure your monthly pageviews and peak traffic, load-test the instance on the hardware you intend to use, and set alerts for disk, memory and ClickHouse health, since capacity, uptime, backups and security are all yours to run.

How DeployOpen scopes, runs and supports the Plausible migration

DeployOpen plans and implements self-hosted Plausible Community Edition inside your own infrastructure, then configures the GA4 history import, the replacement script and the handover. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every GA4 property, site and goal that the Plausible site must replace before any work starts
Confirm which GA4 data the import cannot carry, such as ecommerce revenue, UTM sources and exit pages, and record the decisions in writing
Agree the hosting location, Docker and Compose host sizing, and whether the Google OAuth client is set up by your team or ours

How we build

Deploy Plausible Community Edition with Docker Compose on infrastructure you control, meeting the CPU and 2 GB RAM requirements
Register the Google OAuth client, set the GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET settings, and enable the four Google APIs
Replace the GA tag with the Plausible script, then test pageviews, goals and the daily aggregate import on staging before cutover

How we hand over

Provide written documentation of the configuration, the import range, the goals rebuilt and the features that did not carry over
Walk your operators through upgrades to new Community Edition releases, since security fixes arrive only when the release is applied
Deliver backup, restore and access procedures so your team can run the instance without DeployOpen involvement

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainers can cover applying each twice-yearly Community Edition release and checking security advisories on your schedule
Ask for a written quote that separates one-time setup from recurring support, hosting and any Plausible Cloud comparison work

Migrate from Google Analytics to Plausible