Open-source alternative to Google Analytics 360

Open-source alternative to Google Analytics 360: the short answer

Self-hosted Matomo covers web analytics, and PostHog covers product analytics and session replay, but neither replaces what an Analytics 360 contract buys on paper: a Google-backed SLA, a managed export pipeline and vendor-run data handling. If your renewal is driven by data residency, lock-in or a wish to own raw events, open source can address those concerns. It will not give you a vendor who answers for uptime or delivers a 20-billion-event daily BigQuery export on your behalf. Before you compare anything, list what your current contract actually provides: the SLA terms, the unsampled report scope, the retention you rely on and the BigQuery export volume your downstream teams consume.

Matomo On-Premise Community is free, licensed under GPLv3, with unlimited users and hits and forum support only. PostHog's self-hosted deployment is officially unsupported, and PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. The support you would otherwise buy from Google, or from a commercial vendor on a self-managed edition, becomes an internal staffing decision or a separate contract with a partner. Confirm with each vendor which support tiers, if any, they sell for your deployment model before you put either option on a comparison sheet.

The practical decision is therefore about who operates the stack. Ask the vendors and your own platform team to confirm where raw events will be stored, who holds the database and backup keys, how uptime will be monitored and who is on call when ingestion stops. The rest of this page works through those questions topic by topic, starting with what each open-source option can and cannot reproduce from Analytics 360.

Which Analytics 360 capabilities map to Matomo and PostHog

This table maps the main Analytics 360 capabilities to self-hosted Matomo and self-hosted PostHog, with the coverage and the gap for each. Read each row as a question to put to the vendor and to your own team, since several gaps are operational rather than feature-based. The main takeaway is that self-hosting replaces Google's SLA, retention and export terms with work your organization must own.

Capability	Matomo (self-hosted)	PostHog (self-hosted)
Unsampled reporting	Matomo On-Premise processes and reports every hit it receives, with no sampling layer in the Community edition. Confirm query behavior at your traffic level with Matomo.	Event-level storage supports unsampled queries. The hobby deployment is only sized for roughly 100k events a month, so confirm capacity before relying on it.
Data retention	Retention is set by your own storage and backup policy, so history lasts as long as you keep the database. Plan disk growth and archiving in advance.	You control retention on your own database. PostHog Cloud's 7-year option on the Pay-as-you-go plan is a cloud feature, not a self-hosted one, so confirm what your deployment supports.
Raw event export	Raw visit and action data sits in your MySQL or MariaDB database. The Google Analytics Importer brings only aggregated reports, so Visitor Log and segments do not work on imported history.	Events live in your ClickHouse and Postgres stores and can be queried directly. Confirm the export format and tooling for your version with PostHog's documentation.
BigQuery or equivalent export	No native BigQuery export. Teams build their own pipeline from the database into a warehouse, which is a project you fund and maintain.	No native BigQuery export. Data pipelines and warehouse connectors exist in the product, but their self-hosted coverage must be confirmed with PostHog before purchase.
SLA and support	Community edition has forum support only. Any uptime target, incident response or patching commitment comes from your own team or a retained partner.	PostHog states self-hosted deployments are unsupported and it offers no customer support for product or infrastructure questions. Google's SLA has no direct equivalent without your own operating model.
Consent handling	Matomo can be configured to the CNIL exemption conditions for audience measurement, but features such as User ID, heatmaps or session recordings remove that exemption. Verify with counsel or your authority.	Consent and cookie configuration is your responsibility. Session and identity features may need consent, so confirm the legal basis for each feature you enable.
Session replay and heatmaps	Heatmap and Session Recording is a paid premium plugin under the InnoCraft EULA, sold per number of users, with a 30-day free trial. It is not part of the GPL core.	Session replay is part of the product under the MIT-licensed core, but premium features in the ee directory need a PostHog license on self-hosted instances. Confirm which features your license covers.
Product analytics	Matomo focuses on web analytics. Funnels and some advanced reports are not imported from Google Analytics, so product analytics needs custom build work.	Product analytics, funnels, feature flags and experiments are part of the platform. Historical imports from Mixpanel or Amplitude are paid-plan features, so confirm import terms before migrating.

When Matomo or PostHog fits an enterprise Analytics 360 estate

Matomo On-Premise is the closest match to Analytics 360 for website reporting. It is licensed under GPLv3, the Community edition is free with unlimited users and hits, and it runs in your own cloud account or data center. Your team takes on the work Google's SLA covered today, including uptime, upgrades, backups and database tuning.

License: GPLv3 covers the core, so there is no license fee for the software itself. Premium plugins such as Heatmap and Session Recording are sold separately under the InnoCraft EULA and priced per number of users.
Hosting: Matomo 6.0.0 needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer. Matomo 4.16 and 5 run on PHP 8 with MySQL 5.5 or later or MariaDB, behind a web server such as Apache, Nginx, IIS or LiteSpeed.
Sizing: The requirements FAQ sizes one server at 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month. It recommends separate app and database servers with 8 CPUs and 16 GB of RAM each for up to 10 million pageviews a month.
Trade-off: The Google Analytics Importer brings in aggregated reports only. The Visitor Log, segmentation and some reports such as Funnels do not work on the imported history.
Consent: Matomo's configuration determines whether a consent banner is needed in France, and adding User ID, heatmaps or session recordings removes that exemption.

Before you size hardware, confirm your monthly pageview volume and the Matomo branch you intend to deploy. Then check which plugins your teams need against the requirements FAQ, which is listed in the Matomo requirements FAQ.

Where your raw analytics data lives after you leave Analytics 360

Raw hits have to land in infrastructure you control before you cancel Analytics 360. That means a database for event and visit records and object storage for exports, both sized by the volume you actually send. Matomo On-Premise is sized by pageviews: the requirements FAQ describes a single server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month, and separate app and database servers with 8 CPUs and 16 GB of RAM each for up to 10 million pageviews a month. Confirm your peak month, not your average, before you pick a tier, because the database grows with every stored visit and Matomo's own sizing is the figure to plan against.

PostHog's self-hosted hobby deployment is a poor place to hold raw data at enterprise volume. The README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that, and the self-host documentation adds that the deployment is officially unsupported with no PostHog customer support. The hobby install recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, which is a starting point, not a sizing for an enterprise event stream. If PostHog is the target, decide early between a paid self-hosted product with its license terms and PostHog Cloud in the EU (Frankfurt) region, and check the retention you need against the plans: the Free plan includes 1-year data retention and Pay-as-you-go includes 7-year retention.

The BigQuery export you rely on today has no drop-in replacement, so the warehouse is a separate design decision. Analytics 360's daily export lands raw events in your Google Cloud project, where your own SQL, joins and retention already run. Matomo and PostHog do not reproduce that table, so you need to choose where analysts will query: a column store such as ClickHouse, a lakehouse on open table formats, or the analytics tool's own database. Each option changes the storage bill, the query skills required and who patches it. Ask your team to list the BigQuery datasets and scheduled queries that depend on the export, then assign each one a new home before cutover.

The operating work that replaces Google's SLA

Google's SLA covers the hosted service. With self-hosted Matomo or PostHog, the equivalent work moves to your team or to your implementation partner, and it must be named, staffed and tested before cutover. The six areas below cover what keeps analytics running, recoverable and compliant after go-live.

Uptime monitoring and alerting

Analytics is a background dependency, so outages often go unnoticed until someone questions a dashboard. Monitor the tracking endpoint, the web application, the database and the queue or ingestion path separately, and alert on missing event volume as well as HTTP errors. Confirm who receives alerts, during which hours, and what counts as an incident. Your team owns these thresholds, and DeployOpen can configure and document them under a retainer.

Patching and version upgrades

Matomo 6.0.0 requires PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, so an upgrade can also mean moving the runtime and database. Plan a staging environment, a tested upgrade path and a rollback point before each release. Check the Matomo changelog before scheduling, because beta and stable versions differ. Confirm the upgrade calendar and who signs off on production changes in your own change process.

Backups and restore tests

A backup that has never been restored is a hope, not a control. Back up the database and the Matomo configuration and file store on a schedule that matches your retention commitments, and keep copies outside the primary server. Test a full restore into an isolated environment at a set interval and record the time it took and what was missing. Ask your partner to show the restore runbook and the most recent test result.

Security hardening and access control

Self-hosting moves the attack surface to your servers. Restrict administrative access, enforce single sign-on where the platform supports it, keep the database off public networks, and terminate TLS at a managed reverse proxy. Review plugin installs and third-party code before they reach production, since plugins extend the attack surface. Record who holds admin rights and review that list on a fixed cycle.

Tracker and consent configuration

Tracking configuration changes what data is collected and whether consent is needed. Document every tag, event and custom dimension, and keep IP truncation and cookie settings under change control. Adding User ID, heatmaps or session recordings can remove the CNIL consent exemption, so every new feature needs a privacy review first. Confirm the configuration with your legal and privacy owners before each release.

On-call response and incident runbooks

Google handled incidents on its side, so your team must now detect, triage and communicate them. Write runbooks for the common failures, such as a stalled tracker, a database full condition or a failed upgrade, and name a primary and backup responder. Agree response expectations internally, since no external SLA figure applies to a self-hosted deployment. DeployOpen can plan, document and support this process under a retainer, but the internal rota and decision rights stay with your organization.

How an enterprise migration off Analytics 360 is sequenced

The sequence moves reporting, history and tracking to a self-hosted platform in your environment in an order that keeps current measurement intact until the new stack is verified and the Google export jobs can be retired.

Inventory reports, segments, goals and BigQuery datasets
Your analytics owner and the data team list every standard and custom report, saved segment, goal, conversion, custom dimension and ecommerce view in use, along with each BigQuery export dataset and the downstream jobs and dashboards that read from it. Mark which items must be reproduced, which can be retired and which need a different data source. The step is done when the inventory has an owner and a sign-off for every row, and when you have confirmed with Google and your contract what SLA, support and export terms apply, so you know what the replacement must cover.
Stand up the self-hosted platform in your environment
Your platform engineers or DeployOpen deploy Matomo On-Premise or PostHog into your own cloud account, data center or air-gapped network, with the web tier, database, backups, monitoring and access controls defined in writing. Confirm the version and requirements against the current Matomo requirements and PostHog self-host documentation, because open-source deployments carry no vendor support and the sizing depends on your monthly volume. The step is done when the platform passes a restore test and the team can show who operates it, who patches it and who responds to incidents.
Import aggregated history through the scripted route
For Matomo, the Google Analytics Importer brings across aggregated report data into a new site. For PostHog, the documented route runs through the GA4 BigQuery export. Both produce summary history, not raw hits, so the Visitor Log, segmentation and Matomo Custom Reports do not work on imported periods, and some reports such as funnels are not imported. PostHog's managed migrations cover Mixpanel and Amplitude sources at most one year per import job, with no deduplication and no selective deletion once imported, so test each job on a copy first. The step is done when the imported totals reconcile with Google's figures for an agreed set of reports and date ranges, and the gaps are documented.
Deploy trackers and Tag Manager changes
Developers replace the gtag or GA4 tags with the chosen tracker or Tag Manager configuration, add the event names and custom dimensions from the inventory, and remove Google-specific consent and ad tags that no longer apply. If you rely on the consent exemption in France or another EU market, the tracker configuration must match the CNIL conditions, and any feature such as heatmaps or session recording must be assessed separately. The step is done when staging and production tags fire on the agreed page set, a test plan covers each event, and a release record shows the change.
Run both tools in parallel
The existing Analytics 360 property and the new platform collect data side by side for a period agreed with business owners and the data team. Compare traffic, conversions and key events by day and channel, and record each variance with its cause, such as bot filtering, consent behavior or tracking differences. Keep the Google export jobs running during this period, since they are your only copy of recent raw data until the new platform holds an equivalent. The step is done when the business has signed off the variance report and the reports that matter reconcile within the tolerance you set.
Cut over and retire the export jobs
Point dashboards, reporting tools and downstream consumers at the self-hosted platform, switch the production tags, and move the executive and compliance reports to the new source. Only after the retention and archive requirements are met should you disable the BigQuery export and Analytics 360 integrations, and confirm with Google how any exported data should be handled under your contract. Document where raw data lives, who can access it and how long it is kept. The step is done when the export jobs are disabled, the archive location and access policy are recorded, and the handover runbook has been accepted by operations.

Questions enterprises ask before replacing Analytics 360

What does it cost to run Matomo or PostHog ourselves?

The software itself carries no license fee for Matomo On-Premise or the MIT-licensed core of PostHog, so the cost is infrastructure, staff time and any paid add-ons. Infrastructure scales with monthly pageviews or events: Matomo's requirements FAQ sizes one server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month, and separate app and database servers with 8 CPUs and 16 GB of RAM each for up to 10 million. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its hobby deployment. Other recurring costs include backups, upgrades, monitoring, storage growth and paid plugins such as Matomo's Heatmap and Session Recording. Ask any partner for a written quote that separates one-time setup from recurring operations, names the hosting assumptions and lists every plugin or license you would need.

How long does a migration off Analytics 360 take?

The duration depends on the number of properties, sites and apps, the volume of custom events, how much history you need to carry over, the number of dashboards and reports to rebuild, and how long you plan to run both tools in parallel. Historical import is the variable most teams underestimate: Matomo's Google Analytics Importer and Plausible's GA4 import bring over aggregated reports, not raw hits, so Visitor Log and segmentation do not work on imported history. PostHog's scripted route from Google Analytics runs through the BigQuery export. Plan the timeline from a written scope that lists each property, tracking change and report, and ask for the parallel-run period and the cutover criteria in the proposal.

Can our internal team run Matomo or PostHog without outside help?

Many organizations can run Matomo or PostHog with an internal platform or DevOps team, but the work is continuous, not a one-time install. The team must own the server or Kubernetes layer, database maintenance, backups, TLS, upgrades, capacity planning and monitoring. Matomo's current stable line requires PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer for the 6.x branch, so upgrades carry real testing effort. PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for infrastructure questions on self-hosted instances, so vendor help is not part of the package. Estimate your team's skills and on-call coverage honestly before deciding.

What should a partner scope include for this kind of project?

A written scope should name each deliverable and its acceptance test. For a replacement of this kind, it should cover:

Infrastructure design and hardening in your own cloud account, data center or air-gapped network, with backup and restore tests
Tracker implementation, consent configuration and tag management for each site and app
Historical import plan, with a clear statement of which reports, segments and raw-event views will not carry over
Dashboard and report rebuild, user access setup and integration with your data warehouse or BI tools
Parallel-run period, cutover checklist and a documented runbook for upgrades and incident response
Optional retainer for ongoing support, upgrades and continuous testing

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in your environment, and most engagements are fixed-scope with the scope agreed in writing before work starts.

Does a self-hosted analytics tool meet EU consent rules?

It can, but only if the configuration meets the conditions your data protection authority sets. France's CNIL lists conditions for analytics trackers to be exempt from consent, including limiting purposes to audience measurement and A/B testing, a single publisher scope, no cross-checking with other processing, truncating the last byte of the IP address and a tracker lifetime of at most 13 months. CNIL also states that most large audience measurement offerings do not qualify regardless of configuration, and it suggests open-source software such as Matomo that the publisher configures itself. Matomo's FAQ notes that adding User ID, heatmaps or session recordings removes the exemption. Ask your legal and privacy team to confirm the position with your national authority before go-live.

Can a self-hosted tool match Google's SLA?

A self-hosted tool does not come with a Google-style SLA from its maker, because the open-source project and its commercial vendors do not sell a contractual uptime commitment for your self-managed deployment. Instead, the matching outcome comes from your own operating model: redundant infrastructure, monitored availability targets, tested backups, a defined incident process and a support contract with named response times if you need one. Matomo sells premium plugins and a hosted Cloud service separately, and PostHog's support for self-hosted instances is limited, so check each vendor's terms in writing. Ask any partner for the availability target they will commit to in their own contract, the hours of coverage, and how they will document recovery objectives for your environment.

What do we lose when we leave Analytics 360 history behind?

Historical data loss is the main risk, and it depends on what you exported before the switch. Imported history from Matomo's importer or Plausible's GA4 import arrives as aggregated reports, so raw visit logs, segmentation, some funnels and custom reports do not work on that history. PostHog's managed migrations import up to one year of events per direct job, events are not deduplicated, and selective deletion is not possible after import. Confirm with the vendor which exports you already hold, such as BigQuery exports, and decide which reports must be kept in a warehouse or archive before the cutover.

What to confirm with vendors and your own team before you commit

Before you commit, settle the release status and licensing questions with the vendors in writing. The facts we hold cover Matomo's GPLv3 license and PostHog's split between MIT-licensed code and the ee directory, but they do not tell you which release line you will be on in twelve months or how long each line receives security fixes. Ask Matomo and PostHog which version is current, which versions are supported, and how upgrades between major versions are handled. Then list every premium feature your analytics team relies on, such as heatmaps, session recordings, SSO or audit logs, and ask whether each one is free under its license or sold separately. For PostHog, ask specifically which features sit in the ee directory and whether they need a PostHog license on a self-hosted instance.

Ask both vendors what support is available for a self-hosted deployment. PostHog's self-host documentation says self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on self-hosted instances, so any support must come from another contract. Matomo's free On-Premise edition is listed with forum support, and you should ask whether a paid support agreement exists and what response commitments it carries. Whatever you find, write it into your operating model: someone on your side or a contracted partner must own patching, backups and incident response, and that owner should be named before the cutover date.

Confirm your retention and export obligations with your data protection officer and legal team, not only with the tool vendor. Ask which retention period your regulator expects for the analytics data you collect, whether the answer differs for aggregated reports and raw event data, and who in the organization decides it. Then check your Analytics 360 contract for notice periods, termination terms and any clause on exporting data or deleting it after exit, and confirm whether your BigQuery export arrangements carry their own obligations. Ask your legal team to read these terms together with your consent and transfer documentation, because they determine how much history you can move and how quickly you must act.

How DeployOpen scopes and supports an analytics replacement

DeployOpen plans, implements, hardens, backs up and documents self-hosted analytics platforms inside your own cloud accounts, data centers or air-gapped networks. For Google Analytics 360 replacements, the work starts with a written scope that defines which data sources, sites, apps and reports move, and who owns each part of the operating model.

How we scope

Inventory every Analytics 360 property, data stream, BigQuery export and consumer report before choosing Matomo or PostHog.
Define in writing which reports, retention periods and exports the replacement must cover, and which will be retired.
Record hosting location, consent approach and data residency requirements so the scope reflects your regulatory position.

How we build

Size and deploy the chosen platform in your infrastructure, with separate application and database tiers where the workload requires it.
Configure the tracker, tag management and any historical import, and document which imported data is aggregated rather than raw.
Run security testing on the deployment and its tracking endpoints, then fix findings within the agreed scope.

How we hand over

Deliver runbooks for upgrades, backups, restores, storage growth and access control, written for your platform team.
Provide documentation of configuration, data flows and retention settings, plus evidence to support your compliance assessors.
Walk your team through operation and agree what remains in-house and what needs external support.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, scoped to your environment.
Ask any quote to separate one-time implementation from recurring infrastructure, upgrade and support effort.

Open-source alternative to Google Analytics 360