Why self-hosted ecommerce analytics is a different build from a marketing site
A store operator who self-hosts web analytics needs to know one thing before choosing a tool: can the analytics server record orders and revenue in a way that reconciles with the commerce back end? A marketing site only needs pageviews and sources. An online store needs order counts, revenue, cart and checkout steps, and campaign attribution that finance and marketing can both trust. On the short platform answer, Matomo offers ecommerce tracking in its self-hosted edition, so it is the option to test first for this use case. Plausible is different. Its ecommerce revenue goals are listed among the features missing from Community Edition compared with Plausible Cloud, so a team that self-hosts Plausible should plan for no revenue goals and either accept that gap or send revenue reporting elsewhere.
Shoppers' cart and checkout behavior is sensitive, and the tracking design has to respect that. Decide before launch which pages and events are collected, and keep account, payment and personal data fields out of the tags and event payloads. Confirm with your privacy lead how Matomo's ecommerce tracking is configured in your environment and whether any order identifiers you send could be linked to a named customer. Campaign attribution also needs a deliberate plan. The goal is to measure which channels drive orders without passing visitor data to ad-funded trackers, so decide early which campaign parameters and referrer rules your marketing team will use.
Platform specifics matter as much as the analytics product. Magento Open Source and WooCommerce do not feed orders into an analytics server on their own, so each needs a platform-specific plugin or integration that sends order and product events to the analytics server. Your team or implementation partner should confirm, for the exact platform version in use, which plugin is supported, how it maps order IDs, refunds and currencies, and what happens to historical orders. Ask for that mapping in writing and test it against a sample of real orders before the first revenue report is trusted.
What an ecommerce analytics build must satisfy in a regulated or privacy-sensitive store
This table sets out the requirements a self-hosted ecommerce analytics build has to meet, the source behind each one, and what it means for the build. Read each row as a design constraint to settle before choosing Matomo, Plausible or a plugin-based setup. The main takeaway is that revenue tracking, checkout exclusion and consent status are decided together, not bolted on after launch.
| Requirement | Source of the constraint | What it means for the build |
|---|---|---|
| Order and revenue accuracy | Matomo ecommerce tracking and Plausible's note that Community Edition lacks ecommerce revenue goals | Matomo can record orders and revenue on the server. Plausible Community Edition cannot record revenue goals, so plan a different measurement path or a reconciliation with the order system. |
| Checkout exclusion from tracking | Consent rules and the principle of excluding account and payment pages from third-party or non-essential collection | Define which checkout, payment and account URLs send no visitor identifiers or personal data. Confirm this with your privacy team and test it in a staging store. |
| Consent exemption limits | Matomo's ePrivacy FAQ on CNIL exemptions: User ID, heatmaps and session recordings remove the exemption | If the store operates in France or follows CNIL guidance, keep the tracker to exempt purposes. Enabling User ID or session replay can turn a consent-free setup into one that needs a banner. |
| Data location | Plausible Community Edition and Matomo are self-hosted, so location depends on your server and any CDN or plugin used | Host the analytics server in an approved jurisdiction and confirm that payment widgets, CDNs and marketing tags do not send visitor data elsewhere. |
| Retention | Consent and privacy obligations apply to stored order and visitor data, and your retention policy sets the limit | Set separate retention periods for raw visit data, aggregated reports and order records, and document how each is purged. |
| Campaign attribution continuity | Google Analytics import limits: only aggregated reports import, and Plausible cannot import ecommerce revenue | Historical campaign data can move over as aggregates, but funnels, visitor logs and revenue history will not. Record the cut-over date and keep the old data available for comparison. |
| Platform support lifecycle | Adobe's lifecycle policy gives each Magento 2.4.x release three years of standard support, and Matomo 6.0.0 needs PHP 8.1 or newer | Align the analytics server, the store platform and the PHP runtime to supported versions. Tracking code that breaks after a store upgrade silently drops orders. |
Which analytics platform fits which store
The analytics tool and the store platform have to be chosen together, because the store decides where order data lives and the analytics tool decides whether revenue can be measured at all. The cards below pair each analytics option with the store or integration point it most often sits beside, and list what to confirm before committing.
Matomo for on-premise ecommerce tracking
Matomo Community Edition is GPLv3 licensed and runs on your own PHP and MySQL or MariaDB stack, which makes it the option most likely to support full ecommerce reporting on a self-hosted store. Confirm that the ecommerce tracking you need is configured in your Matomo edition and that your store integration sends orders to it. Under CNIL-style exemptions, adding User ID, heatmaps or session recording removes the consent exemption, so keep those features off if you rely on it. Confirm the exemption with counsel before enabling any extra feature.
Plausible Community Edition for traffic reporting
Plausible Community Edition is AGPLv3 licensed and runs on Docker and Docker Compose with at least 2 GB of RAM. Its Community Edition omits ecommerce revenue goals, so it can report visits, sources and campaigns but not order value or revenue per channel. Use it for top-of-funnel measurement alongside a store-side order system. Confirm which revenue metrics you need before selecting it, and confirm which features the current release excludes.
Umami as a lighter option
Umami is a lightweight option that teams often choose for simple page and campaign tracking on a small store. It is not covered by the supplied research for ecommerce revenue, order or cart reporting, so treat it as a traffic tool until you verify otherwise. Confirm its license, its supported event model and whether it can attach order totals before you rely on it for conversion decisions. Compare its hosting footprint and update cadence with your operations team.
Magento Open Source for enterprise stores
Magento Open Source is OSL-3.0 licensed, and 2.4.9 is the latest stable release in the supplied sources. Its server stack includes OpenSearch, Redis or Valkey, RabbitMQ and, for self-managed installs, Varnish as the full-page cache, so analytics scripts and cache rules must be planned together. Check that Content Security Policy rules allow your analytics host, since restrict mode is the default on payment pages from 2.4.7. Confirm the supported PHP, MySQL and nginx combination for your release before installing the analytics module.
WooCommerce on WordPress
WooCommerce is GPL version 2 or later and its latest release in the supplied sources is 11.2.1. Analytics for WooCommerce usually runs as a plugin or tag on the WordPress site, so order events depend on the plugin version and the checkout template. Confirm which order fields the analytics plugin sends, whether refunds are reflected, and how the plugin behaves after WooCommerce updates. Test the full checkout path before each store upgrade.
Headless stores with Saleor, Medusa or Sylius
Saleor (BSD-3-Clause), Medusa (MIT, except Enterprise Edition materials) and Sylius (MIT) expose commerce through APIs, so order and cart events have to be sent from the backend or the storefront rather than read from a page template. This adds an integration point that must be designed and tested, including how events are deduplicated and how revenue is passed to the analytics server. Confirm the webhook or event API each platform offers and who owns the integration code after go-live.
How the analytics server connects to a self-hosted store
Magento Open Source is a self-managed application with its own web tier, cache, search and message queue, so the analytics server is one more service to place beside it. The usual integration point is the tracking tag in the storefront theme, with order and item data sent when checkout completes. Because Magento already runs several supporting services, the analytics server usually belongs on its own host once traffic grows.
- Integration point: The tracking code loads through the storefront theme, and ecommerce data is sent from the order success page. Confirm whether your Magento version needs a Matomo extension or a custom module for this.
- Same host or separate: Adobe's system requirements for 2.4.9 list PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3 and nginx 1.30. Running Matomo on these hosts competes for CPU and memory, so plan a separate analytics host.
- Caching: Self-managed installations use Varnish as the full-page cache, while cloud-hosted Adobe Commerce uses Fastly. Confirm that the order confirmation page is never cached and that cached pages still fire the events you expect.
- Sizing: Matomo's requirements guidance sizes a single server at 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month. Separate app and database servers with 8 CPUs and 16 GB of RAM each are its guidance for up to 10 million.
Check the exact Magento tag and PHP version in your environment, and confirm that the analytics server's runtime does not conflict with Magento's.
WooCommerce is a plugin that runs inside WordPress, so the store, the content site and the database usually share one application stack. The integration point is typically the WordPress theme or a tracking plugin, plus WooCommerce's order events on the server side. The main design choice is whether the analytics server runs on the same host as the store or on its own infrastructure.
- Integration point: WooCommerce's order completion hook can trigger ecommerce tracking, either in the browser on the thank-you page or on the server. Confirm which method your analytics platform supports for your WooCommerce version, because browser-only tracking misses orders where the customer leaves before the thank-you page loads.
- Shared stack: WooCommerce 11.2.1 and WordPress share PHP and the database, so a busy analytics database on the same host can slow checkout. Keep the analytics server separate once volume grows.
- Patch cadence: WordPress.org states that only the most recent release in each series is actively maintained, and WooCommerce ships on its own schedule. Analytics and store updates should be planned together so that plugin conflicts are found in staging.
- Hosting limits: Some managed WordPress hosts restrict outbound connections or database access, which can block a self-managed analytics server from receiving server-side events. Confirm these limits before choosing the architecture.
- Sizing: The same Matomo guidance applies. A single server suits smaller traffic, while separate app and database servers are the documented step up.
Confirm your WooCommerce and WordPress versions, and test order events on a staging copy before enabling them in production.
Headless commerce separates the storefront from the commerce API, so tracking can live in the storefront, in the backend, or in both. Saleor is licensed under BSD-3-Clause and Medusa is MIT licensed except for materials covered by its Enterprise Edition license. In either case the analytics server is a separate service that receives events from the storefront or from backend webhooks.
- Integration point: Events usually come from the storefront application, which knows the cart and checkout state. Backend events, such as payment confirmation, can be sent from the commerce API when a browser event is unreliable.
- Service separation: The commerce API, storefront, database, search and analytics typically run as separate services. Keep the analytics database off the commerce database so that reporting load does not affect order processing.
- Edge and CDN: The storefront is often served through a CDN. Confirm that tracking requests are not cached, and check which regions the CDN and analytics traffic pass through.
- Licensing: Confirm which Saleor or Medusa components you use fall under the open source license and which fall under the Enterprise Edition license, since that changes what you can deploy and support yourself.
- Sizing: Use the same Matomo sizing guidance for the analytics server, based on pageviews rather than on the number of API calls.
Confirm which events the storefront emits and which the backend emits before you decide where order revenue is recorded.
How a store moves from tag-based tracking to self-hosted conversion data
This sequence moves order, revenue and campaign data from third-party tags to an analytics server the store controls, with each phase closing on a check that proves the numbers match the commerce back end before the old tags are switched off.
Inventory events, goals and revenue fields
The team lists every event the store tracks today, including page views, add to cart, checkout steps, order completion, refunds, and campaign parameters, and maps each one to the equivalent on the commerce platform. Marketing, merchandising and finance review the list together, because each owner relies on different numbers. The output is a signed event inventory that names the data source for each metric, such as the order table in Magento Open Source or WooCommerce, and states which metrics must be reproduced exactly. Confirm early whether your chosen edition supports ecommerce revenue goals, since Plausible Community Edition does not include them.
Design consent and checkout exclusions
Legal and privacy owners decide which pages and data points stay out of collection, such as account, payment and personal data fields, and whether the analytics setup qualifies for consent exemption in each market. The engineering lead documents how the tracker will skip checkout personal fields and how user identifiers are handled. The output is a written collection policy and a list of excluded URLs and parameters, approved before any code change. Remember that features such as User ID or session recording can change the consent position, so record that decision explicitly.
Install the analytics server and edition
The platform team installs the chosen edition, Matomo On-Premise or Plausible Community Edition, on infrastructure that meets the vendor's stated requirements, with the database, web server and backups configured. For Plausible Community Edition, this means Docker, Docker Compose and at least 2 GB of RAM on a CPU that supports the instructions ClickHouse needs. The output is a running instance with HTTPS, admin accounts behind single sign-on where available, and a tested restore of a backup. Confirm the operator responsibilities for updates and security patches before go-live.
Connect the store through plugin or tag
The developer connects the store to the analytics server using the platform's plugin or a server-side integration rather than a browser tag where possible, then adds the event definitions from the inventory. Adobe Commerce and Magento Open Source sites need the content security policy updated to allow the analytics endpoint, and cache layers such as Varnish need checking so tracked events are not served from stale pages. The output is a staging store that emits each mapped event with the expected properties, verified in the analytics debugger.
Reconcile test orders against the back end
The QA team places test orders covering full price, discounts, shipping, taxes, refunds and cancelled carts, then compares each conversion and revenue value in the analytics server with the order records in the commerce back end. Differences are traced to currency rounding, tax treatment, or events that fire before payment completes. The output is a reconciliation sheet showing that every test order matches, with each exception either fixed or accepted in writing by finance.
Run in parallel and verify attribution
The old tags and the new analytics server run side by side on production traffic for a period the business agrees in advance. Analysts compare daily orders, revenue and campaign-attributed conversions from both sources, and check UTM capture on paid, email and affiliate links. Where historical data is imported, such as from Google Analytics, the team confirms which reports the importer can carry over, because Matomo's importer brings in aggregated reports only and Plausible imports GA4 daily aggregates without ecommerce revenue. The output is a signed variance report with the reasons for each gap.
Cut over and set retention
The team removes the old revenue tags, switches reporting dashboards to the self-hosted source, and sets retention periods and IP handling as defined in the collection policy. Access rights are reviewed so only named roles can export order-level data. The output is a cutover record with the date, the approved configuration, the retention settings, and the rollback steps, filed with the compliance owner. Schedule a follow-up reconciliation after the first full billing cycle to confirm nothing drifted.
Keeping history when moving off Google Analytics
Decide before cutover how much Google Analytics history you need in the new system, because the two self-hosted options import very different data. In Matomo, the Google Analytics Importer, a free plugin for Matomo On-Premise under GPLv3 or later, brings in aggregated report data only, not raw visits and actions. Matomo's FAQ on import limitations states that the Visitor Log, Ecommerce Log, Custom Reports and Segmentation do not work for imported reports, and that some reports, such as Funnels, are not imported at all. If your revenue review depends on order-level drill-down or segments built on past purchases, plan to keep the old property readable for that purpose rather than expect Matomo to reproduce it.
In Plausible Community Edition, the Google integration covers GA4 historical import as daily aggregates, up to the first native Plausible visitor, for up to 5 GA properties per site. Two limits matter for ecommerce. The import cannot bring in ecommerce revenue, so past revenue history will be missing from revenue goals, and unique visitors are approximated by summing daily uniques, which overstates uniques across days. Confirm with your analyst whether period-over-period unique visitor comparisons will be read as exact. Also confirm whether the revenue goals you need exist in the Community Edition at all, since the self-hosted page lists ecommerce revenue goals as a Cloud-only feature.
Before cutover, record the decisions in writing: which reports and date ranges must be retained, who owns reconciliation of revenue totals between the old and new systems, and whether historical data is kept in a separate read-only site for finance. Run a reconciliation on a sample period for orders and revenue, and document every known difference so auditors and finance do not find it later. Check the current import settings and limits with each vendor's documentation at the time of the project, because import behavior changes between releases.
What auditors and finance teams ask for from ecommerce analytics
This table maps each evidence item an auditor or finance reviewer typically requests to the platform component or configuration that produces it. Read it as a checklist to set up before the first assessment, not after. These artifacts support assessments; they do not themselves constitute a certification or audit opinion.
| Evidence item | Produced by | What reviewers check |
|---|---|---|
| Data flow diagram | Architecture document covering the tracking script, the analytics server, the database, backups and any CDN or tag manager | Every hop where order, revenue or customer-linked data travels, and whether any leg leaves the approved jurisdiction |
| Consent configuration record | Tracking code settings, consent manager integration and the tag firing rules for purchase events | Whether purchase and revenue events fire only under the consent state the policy describes, and when the setting last changed |
| Retention settings | Analytics platform data retention configuration for raw visits, action logs and ecommerce logs, plus backup retention | That raw order-level records are kept only as long as the documented policy allows, and that deletion actually runs |
| Access control list for the analytics server | Admin and user role assignments, SSO or directory group mapping, and server shell and database access lists | Named owners for each role, least privilege for finance exports, and removal of leavers within the review cycle |
| Revenue reconciliation sample | Export of orders from the commerce platform compared with ecommerce revenue reports in the analytics platform, for a dated sample | Whether totals, currencies, refunds and tax treatment match, and where the known gaps between the two systems are explained |
| Change and upgrade records | Version inventory, change tickets, patch logs for the analytics application, PHP and database, and the commerce platform release in use | That the analytics platform runs a supported version and that tracking changes were tested and approved before release |
Common questions on self-hosted ecommerce analytics
Are Matomo's ecommerce features enough for a self-hosted online store?
For many stores, yes, but confirm the specific reports you need against the edition and version you plan to run. Matomo's On-Premise Community edition is licensed under GPLv3 and is free to download, with unlimited users and hits, so ecommerce tracking is not gated behind a paid tier in the way some competitors gate revenue reporting. Before you commit, list the metrics you rely on today, such as order revenue by campaign, cart abandonment steps and product-level performance, then test each one on a staging site with sample orders. Also check whether your reporting depends on plugins that are sold separately, such as the paid Heatmap and Session Recording plugin, which is licensed under the InnoCraft EULA rather than the GPL.
Can Plausible track ecommerce revenue on a self-hosted install?
Not on the Community Edition. Plausible's self-hosted page lists ecommerce revenue goals among the features missing from Community Edition compared with Plausible Cloud, so revenue attribution needs either the Cloud plan or a different platform. Community Edition is licensed under AGPLv3 and is useful for page-level and campaign traffic, but if your decision depends on order value by source, Matomo is the better fit to evaluate first. Plausible's Google Analytics import also cannot bring over ecommerce revenue, so a move from GA4 will not carry revenue history either. Ask any implementation partner to confirm the feature list for the exact release you intend to deploy.
What does the internal team need to run ecommerce analytics in-house?
Plan for a team that can operate a web application, a database and a tag deployment process. Matomo's requirements call for PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer for version 6.0.0, behind a web server such as Apache or Nginx. Someone must own upgrades, backups, cron-based archiving, and the tag manager or data layer that sends order events from your storefront. For Magento or WooCommerce stores, the commerce platform and analytics server will have separate release cycles, so one owner should track both. If no one on the team has run these components before, ask a partner to document the runbook and hand over the operation in writing.
What are the real cost drivers for self-hosted ecommerce analytics?
The software license is not the main cost. Matomo's On-Premise Community edition is free, but you pay for hosting, staff time and implementation. Matomo's sizing guidance gives 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. For comparison, Matomo Cloud plans start at 29 (excluding tax) per month for tiers from 50,000 to 10 million hits a month, according to Matomo's pricing page. Ask for a quote that separates one-time setup, tag and event work, and recurring hosting, upgrades and support.
How long does it take to deploy ecommerce analytics on your own server?
The duration depends on the number of storefronts, the complexity of the order and checkout events, and how much historical data you need to bring over. No supplied source gives a standard timeline, so treat any number you hear as a claim to verify. The work usually splits into four parts: provisioning the servers, installing and hardening the analytics platform, mapping and testing order, cart and campaign events on staging, and cutover with a parallel run. If you plan to import history from Google Analytics, note that Matomo's importer brings in aggregated report data only, so Visitor Log, Ecommerce Log and Funnels do not carry over. Ask for a written milestone plan tied to a fixed scope.
Can our team set up ecommerce conversion tracking alone?
A capable engineering team can install the platform alone, but the riskiest part is usually event correctness, not installation. Order revenue, refunds, currency, tax handling and checkout steps must match your commerce system, and errors show up as wrong revenue in reports that executives trust. Magento Open Source 2.4.9 lists PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3 and Redis or Valkey 9 among its requirements, so the commerce stack alone demands careful maintenance. If your team has no one with that experience, a partner can handle implementation and testing under a fixed scope while your staff takes ownership of operations. Ask who validates the revenue numbers against your order system before go-live.
Which WooCommerce or Magento plugins connect analytics to the store?
Confirm plugin availability and licensing for each version before selecting a platform, because this topic's sources do not establish which analytics connectors are maintained for which store versions. WooCommerce is licensed under GPL version 2 or later and its current release is 11.2.1, so check the analytics connector's compatibility with that release. Magento Open Source is licensed under OSL-3.0 with AFL-3.0 included, and 2.4.9 is the latest stable tag. Some connectors are free and others are paid, so review each plugin's license terms. Ask the partner to list every plugin, its license, its last update and the events it sends.
Do we need consent for ecommerce tracking under European rules?
It depends on the purposes you configure and the national rules that apply to your visitors, so confirm this with your legal or privacy team before launch. Matomo's ePrivacy guidance says some regulators, including France's CNIL, exempt certain audience measurement from consent when it is limited to performance measurement, collects only anonymous statistics and excludes marketing measurement. Adding features such as User ID, heatmaps or session recordings removes that exemption, so ecommerce setups that link orders to individual customers need a closer review. Ask for a written data flow showing which order fields leave the store and where they are stored.
Questions to ask an implementation partner before signing
Start with reconciliation, because it decides whether the analytics can be trusted. Ask the partner how order totals, refunds and currency conversion in the analytics will be checked against the store's own order records, which system is the source of truth for revenue, and what tolerance is accepted before a discrepancy is investigated. Ask who runs the reconciliation after go-live, how often, and what evidence is kept. Also ask how the tracking handles orders placed through the store's API or a marketplace, since those paths are easy to miss when only the storefront is instrumented.
Next, ask how checkout and payment pages will be handled. Confirm which pages carry the ecommerce tracking calls, whether any payment provider frames or card fields can receive a script, and which fields are excluded from collection so that no personal or payment data reaches the analytics server. Ask for the consent configuration per target country, including which tags load before and after consent, who maintains the list of countries, and how a change in a national regulator's guidance would be applied. Ask for the store platform version the work targets, the support window for that version, and how the partner will keep the tracking plugin working through store upgrades and patches.
Finally, ask what the fixed scope and written deliverables include. A usable answer names the store platform and version, the analytics platform and edition, the plugins or custom code to be delivered, the test cases used to verify orders and campaign attribution, the data retention settings, and the handover documents. Ask what is excluded, such as ongoing plugin maintenance, new funnels or dashboards, and how changes to scope are priced and approved in writing. Confirm whether maintenance and upgrade testing are covered by a separate retainer, and what the partner will do if a platform release breaks tracking.
How DeployOpen scopes and supports ecommerce analytics builds
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source analytics inside your own cloud accounts, data centers or air-gapped networks. For ecommerce tracking, we start from the order, revenue and campaign questions your team must answer, then fix the platform and tracking design to match them in a written scope.
How we scope
- We confirm which store platform runs the checkout, such as Magento Open Source, WooCommerce or another storefront, and where order data is written.
- We list the events to track, including orders, revenue, cart abandonment and campaign parameters, and which of them the chosen analytics edition can record.
- We agree the written scope, deliverables and timeline before work starts, with the consent and privacy decisions recorded as inputs.
How we build
- We install and configure the analytics server, the database and the store connector in your environment, keeping order data inside your infrastructure.
- We implement and test the ecommerce tracking code on checkout and confirmation pages, comparing recorded revenue against order records from the store.
- We run security checks on the analytics server and the store integration, and document the access controls and configuration settings we applied.
How we hand over
- We deliver runbooks covering installation, upgrades, backups, retention settings and how to add or change ecommerce goals.
- We document the tracked events, data flows and known limits, such as features missing from a given edition or data that cannot be imported.
- We train your team on daily checks and on reviewing conversion and attribution reports, and provide evidence for your compliance reviews.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so updates to the store and analytics platform are planned and tested.
- We track platform release changes and tell you when a store or analytics upgrade affects tracking, so checkout events keep recording correctly.
- We agree support terms, response expectations and the scope of each retainer in writing, with a quote that follows from the written scope.
