How to use this web analytics requirements checklist
A team that needs website measurement without sending visitor data to ad platforms usually has to choose between Matomo, Plausible and Umami, and the choice is hard to defend unless the business needs are written as tests. This checklist turns those needs into requirements that each option can pass, fail or score. Work through the sections in order, record the evidence for each option, and only then compare totals. The sections cover functional must-haves, hosting and data residency, identity and access, privacy and retention, integrations, and operations and support.
Score most items on a simple scale, such as meets, partly meets or does not meet, and note the evidence next to each score, such as a documented setting, a release note or a test you ran in a staging environment. Some items are pass or fail gates that no score can offset. Examples include a data location your legal or security team has already ruled out, or a missing capability your consent approach depends on. Mark gates first so that a strong feature score cannot hide a blocking gap. Edition boundaries matter here: Plausible's Community Edition and Umami's self-hosted build differ from their cloud products in specific features, and Matomo's premium plugins are licensed separately from its GPL core.
Confirm every edition, licence, version and requirement at the time of evaluation, not from this page. Release numbers, minimum PHP or database versions, server sizing and plugin terms change, and the vendor's current documentation, changelog and repository license file are the authoritative sources. Record the version you tested and the date you tested it, so that the comparison can be repeated before procurement or an assessor's review. Where a requirement depends on an external service, such as a CDN, a tag manager or a search console integration, confirm that dependency explicitly rather than assuming the self-hosted server is the only component that receives data.
Which functional must-haves separate the platforms
This table compares Matomo, Plausible Community Edition and Umami on the measurement features most teams need before choosing a platform. Read each row as a question to put to the vendor or to test in a pilot, since a yes in one column may come with a licence, edition or import limit that changes the answer.
| Capability | Why it matters and how to verify | Matomo | Plausible Community Edition | Umami |
|---|---|---|---|---|
| Pageviews and custom events | Core traffic counts and goal events drive every other report. Verify in a staging site by firing a custom event and confirming it appears in the reports within the expected time. | Yes | Yes | Yes |
| Campaign and referrer tracking | Shows which channels bring visitors. Verify UTM parameters and referrer sources with a test campaign link and check that they are attributed correctly. | Yes | Yes | Yes |
| Goals and conversions | Measures outcomes such as sign-ups or downloads. Verify each goal by completing it on a test account and confirming the count matches. | Yes | Yes | Yes |
| Ecommerce revenue tracking | Needed for order and revenue reporting. Plausible Community Edition does not offer ecommerce revenue goals, so confirm the revenue feature on Matomo or Umami against your store setup. | Yes | No | Confirm |
| Marketing funnels and user journeys | Shows drop-off across steps. Plausible Community Edition lacks marketing funnels and user journeys, so test the funnel you need on Matomo or Umami before committing. | Confirm | No | Confirm |
| Heatmaps and session recording | Explains behavior on pages. Matomo's Heatmap and Session Recording is a paid premium plugin sold per number of users, and adding it can remove consent exemptions, so budget and legal review belong in the checklist. | Paid plugin | Not offered | Confirm |
| Google Analytics historical import | Preserves trend history during migration. Matomo's importer carries only aggregated data, so Visitor Log, Segmentation and Funnels do not work for imported reports, while Plausible imports daily aggregates, supports up to 5 GA properties and cannot import ecommerce revenue. | Aggregated only | Daily aggregates, up to 5 properties | Confirm |
Where the analytics server must run and what it needs
Hosting model and data residency decide which platforms are even candidates, so settle them before comparing features. Start by writing down where the analytics server must run (your own data center, a private cloud account, or an EU-only region) and whether any visitor data may leave that boundary. Matomo publishes sizing for two shapes: 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 split app and database servers with 8 CPUs and 16 GB of RAM each for up to 10 million pageviews a month. Matomo 6.0.0 needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, so check those versions against your standard stack. Confirm the figures against the Matomo requirements FAQ before you size hardware.
Plausible's Community Edition requires Docker and Docker Compose, a CPU with SSE 4.2 or NEON support (required by ClickHouse), and at least 2 GB of RAM. Umami requires Node.js 18.18 or newer for a source install and supports PostgreSQL from version 12.14, and it also ships a Docker image and a Compose file with a bundled PostgreSQL database. Ask your platform team whether container runtimes and Compose are approved in your environment, and whether a managed PostgreSQL service is available. Confirm the current minimums in each project's documentation, because they change between releases.
For each option, confirm the region where any hosted or Cloud data sits. Matomo states that Matomo Cloud data is stored in Frankfurt, Germany, and Plausible describes its service as made and hosted in the EU, but a Cloud plan is a different data location from your self-hosted instance, and you should verify that claim in the contract. Then map every outbound connection the server needs: software updates, container image pulls, the tracking script if it is served from a third-party CDN, geolocation or bot-list downloads, and any Google connector. Blocked outbound traffic is a common reason an installation works in testing and fails in an air-gapped or locked-down network.
Security requirements to verify before go-live
Self-hosting moves the security work of the analytics server onto your team or implementation partner. The controls below apply to Matomo, Plausible and Umami alike, and each one needs a written answer before a site tag goes live. Confirm them against the edition and version you choose, not against a vendor's general claims.
Administrator authentication and single sign-on
Decide how administrators sign in before anything else is configured. Confirm whether the platform supports single sign-on with your identity provider in the edition you plan to run, and whether multi-factor authentication can be enforced for every admin account. Plausible's self-hosted page lists single sign-on among the features missing from Community Edition, so a Community Edition build will need a different approach, such as a reverse proxy in front of the login page. Test the sign-in path, password reset and account disablement when a person leaves.
Role-based access to sites and reports
List who needs to see which sites, reports and raw data, and map those needs to the platform's roles. Analytics platforms often grant broad access by default, so check whether a read-only analyst role can be limited to specific sites and whether raw visitor-level data can be hidden from roles that only need aggregates. Review role assignments on a set schedule and record each change. Ask the platform owner which permissions exist in the version you deploy, because role models differ between releases.
Audit logging of administrative actions
Auditors will ask who changed tracking settings, retention periods, user roles or exports, and when. Confirm which administrative actions the platform records natively and where those logs are stored. If the application does not keep a complete record, forward web server, database and container logs to a central store that administrators cannot edit. Test that a deliberate change, such as adding a user, appears in the log with a timestamp and an actor.
Encryption in transit and at rest
Require HTTPS with current TLS settings on the collection endpoint, the dashboard and any API, and confirm that the tracking script is served over the same protected channel. For data at rest, decide whether volume or disk encryption is applied to the database and backup storage, and who holds the keys. Check that database connections between the application and the database are encrypted where they cross a network boundary. Record the settings in your configuration baseline so drift can be detected.
Patch cadence and vulnerability disclosure
Agree a patch window and an owner for each analytics component, including the application, database and container images. Plausible's self-hosted page says Community Edition gets security fixes only when the operator applies a release, and the Community Edition repository notes a security release published on May 15, 2026 (v3.2.1), so a lagging install carries that exposure. Subscribe to the vendor's security announcements, and ask your partner how upgrades are tested before production.
Hardening of the database and web tier
Restrict the database to the application network, use dedicated credentials with least privilege, and close all ports except those needed for collection and administration. Matomo's requirements separate the app and database servers at larger scale, and Umami runs against PostgreSQL in its Docker Compose setup, so confirm which database versions and configuration files your edition expects. Run a configuration review against an agreed benchmark and retest after each upgrade.
Privacy, consent and retention requirements by regulator and setting
Cookieless tracking is the first split to settle, because it decides whether a consent banner is needed at all. Umami describes its platform as working without cookies, cross-site tracking or the automatic collection of personal data. Plausible describes its script as using no cookies, so that no cookie banner is required. Matomo can run with or without cookies depending on configuration, so the setting must be verified rather than assumed.
- Cookie settings: Confirm in the configuration and on a live page that no cookies or local storage identifiers are written by the tracker, including by any plugin or tag manager.
- Third-party embeds: Check that embedded video, maps or chat widgets on the same pages do not set their own tracking cookies, since they fall outside the analytics platform's behavior.
- Feature-driven changes: Note that adding features such as User ID, heatmaps or session recordings can change the legal position, even on a tracker that is otherwise cookieless.
- Documentation: Record the tracker's cookie behavior for each site, version and tag manager container, and re-test after each upgrade.
- Vendor statements: Treat vendor descriptions as claims to verify, and ask for the current technical documentation for the exact version you deploy.
Ask your counsel and data protection officer to confirm whether cookieless operation removes the consent requirement in each market you serve.
IP addresses are often personal data, so the platform's handling of them must be specified, configured and evidenced. Options include anonymizing IP addresses before storage, truncating them, or not storing them at all. Each option has different effects on geolocation accuracy, bot filtering and the ability to answer questions about specific visits. Decide the rule before go-live, because historical data may not be recoverable once stored.
- Collection point: Confirm whether the platform receives the full address and when it is masked, since logs on the web server or load balancer can hold raw IPs regardless of analytics settings.
- Anonymization setting: Document the exact configuration key or admin option that controls masking for the version in use.
- Geolocation impact: Agree with stakeholders how much location detail is acceptable and test the result against sample traffic.
- Server logs: Set retention for reverse proxy and web server access logs separately from analytics data.
- Bot filtering: Check how masking affects bot detection, since some self-hosted editions offer more advanced filtering than others.
Ask counsel to confirm whether your chosen masking method meets the anonymization standard your regulator expects.
Retention is the period for which raw and aggregated analytics data is kept, and it must match your published privacy notice and records policy. Self-hosting gives you control over this setting, but it also means no vendor enforces it for you. Hosted plans show how retention varies with tier, which is a useful reference point when you define your own policy.
- Raw versus aggregated data: Set separate periods for event-level data and for aggregated reports, and document which one each report uses.
- Scheduled deletion: Confirm that the platform or a scheduled job deletes data at the end of the period, and test the job on a non-production copy.
- Backups: Include backup retention in the policy, because deleted records may persist in backups until those backups expire.
- Exports: Limit who can export raw data and log each export, since exported files often outlive the platform's retention settings.
- Hosted reference points: Umami Cloud lists different retention periods by plan, and Plausible Community Edition users can export data to Plausible Cloud, which should be considered in any migration plan.
Ask counsel and your records manager to confirm the retention periods for each data category before configuring the platform.
Data subject requests cover access, correction, deletion and objection requests from visitors. In a self-hosted deployment, your team usually performs these tasks itself, so the process needs named owners, a documented procedure and tooling that can locate and remove a visitor's data. Cookieless tools may hold less identifiable data, but this does not remove the duty to respond when data can still be linked to a person.
- Request intake: Define how requests arrive, who logs them and the internal deadlines your policy sets.
- Identification: Confirm what identifiers the platform stores, such as hashed visitor IDs or User IDs, and whether they can be searched or deleted by a specific person.
- Deletion method: Test whether a deletion removes the record from aggregates, backups and exports, or only from the live interface.
- Access logging: Keep an audit trail of staff access to the platform's data and of each request handled.
- Vendor support: Ask whether the vendor's documentation covers request handling for the version you run, and whether community support can address it.
Ask your data protection officer to confirm the request procedure and the evidence you must keep for each response.
Some French and southern European authorities recognize certain analytics as exempt from consent when strict conditions are met. Matomo's ePrivacy FAQ explains that the French regulator, the CNIL, accepts some audience measurement trackers as exempt when they are limited to purposes such as performance measurement, collect only anonymous statistics and exclude marketing measurement. The same FAQ says that adding User ID, heatmaps or session recordings removes the exemption. It also names France, Italy, the Netherlands and Spain as authorities that exempt certain privacy-focused analytics, and suggests following the CNIL configuration for Italy, the Netherlands and Spain. Confirm these criteria against the regulator's own guidance and current law before relying on them.
- Permitted purpose: Limit the analytics to audience measurement and performance, with no advertising or cross-site profiling.
- Anonymous statistics only: Remove any identifier that links visits to a person, including User ID.
- Excluded features: Disable heatmaps, session recordings and similar tools on any site where the exemption is claimed.
- Plugin review: Check that no plugin, tag or connector adds a feature that breaks the conditions.
- Scope of exemption: Apply the exemption only to the markets and sites where the regulator's criteria are met, and document the configuration per site.
Ask counsel to confirm whether each market's regulator accepts the exemption for your exact configuration, because the position can change.
Which integrations to require and how to test them
Can a self-hosted analytics platform import Google Analytics history and Search Console data?
Yes for some platforms, but the depth of the import differs. Plausible Community Edition documents a Google integration configured with GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET that enables Search Console keyword data and GA4 historical import from the site's Imports and Exports settings. Its import brings in historical GA4 stats as daily aggregates up to the first native Plausible visitor, supports up to 5 GA properties per site, cannot import ecommerce revenue, and approximates unique visitors by summing daily uniques. Matomo's Google Analytics Importer is a free plugin for On-Premise, but it imports only aggregated report data, so the Visitor Log, Ecommerce Log, Custom Reports and Segmentation do not work for imported reports and some reports such as Funnels are not imported. Test with a copy of one real property, compare totals for a fixed date range, and confirm with the vendor which reports you lose before you retire the old property.
How should a consent management platform and tag manager be tested with analytics?
Test that the analytics script loads only when the rules you have chosen allow it, and that the consent state reaches the analytics configuration correctly. Check three things: the tag manager fires the analytics tag only after the agreed consent state, the consent banner or its absence matches the legal position you have documented, and any feature that adds personal data collection, such as User ID, heatmaps or session recording, is disabled or moved behind consent. Matomo's ePrivacy guidance notes that adding such features can remove the audience measurement exemption that some regulators grant in France, Italy, the Netherlands and Spain. Ask your legal or privacy team to confirm the applicable position, and record the test results as evidence.
How do I connect a self-hosted analytics dashboard to a corporate identity provider?
Confirm the single sign-on method each edition supports before you plan the work, because the answer changes by product and edition. Plausible's self-hosted page lists single sign-on among features missing from Community Edition compared with Plausible Cloud, so an SSO requirement may point toward a different edition or an approved workaround. For Matomo and Umami, confirm with the vendor whether SAML, OpenID Connect or LDAP support is built in or provided by a plugin, and whether it is free or paid. Test that disabling a user in the identity provider blocks dashboard access, that group membership maps to the correct site-level roles, and that break-glass local administrator access is documented and tested.
Which export paths should I test for moving analytics data into a warehouse or BI tool?
Test the export paths you actually need, not the ones in the brochure. Typical paths are a scheduled export of aggregated reports, a raw event export, a reporting API, and a direct database connection. Confirm for each platform whether the export is aggregated or event-level, how it handles late-arriving data, and whether the export format is documented. Test one month of data end to end: export it, load it into the warehouse, and reconcile totals against the dashboard. Ask the vendor or implementation partner to document the schema and any licence limits on reuse of exported data, since some editions restrict API or streaming access.
Does Plausible or Matomo offer a Looker Studio connector in a self-hosted setup?
Confirm this with each vendor before you commit, because the answer depends on edition. Plausible's self-hosted page lists the Looker Studio connector among features missing from Community Edition compared with Plausible Cloud, so a Looker Studio dashboard on Community Edition will need another route, such as an export into a warehouse. For Matomo and Umami, check the current documentation and plugin listings for a supported connector and whether it works with a self-hosted instance and a private network. Test that the connector can reach your server through your network controls, that the data refreshes on the schedule you need, and that the user who authorizes it has only the access the dashboard needs.
Which ecommerce plugins for Magento and WooCommerce should I test with analytics?
Test the ecommerce tracking path end to end, because platform plugins vary in what they capture. Confirm which plugin or tag your store platform needs, whether it sends order, revenue and product data to the analytics server, and whether it respects the consent state from your banner. Plausible's Community Edition does not include ecommerce revenue goals, so an order revenue requirement needs to be checked against Matomo or Umami's ecommerce support. Place a test order in a staging store, confirm the revenue and order count match the store back end, and check that no customer personal data such as names or addresses reaches the analytics server. Ask the plugin vendor for its licence terms and supported platform versions.
What should I test for API access, streaming and data retention limits?
Test whether the API covers the reports and write operations you need, and whether the self-hosted edition has the same access as the cloud service. Umami's pricing page states that Umami Cloud adds features the self-hosted version lacks, including email reports and a streaming API, so a streaming requirement may need to be confirmed as unavailable on self-hosted. Check the API authentication method, rate limits on your own server, and whether tokens can be scoped and revoked. Confirm retention settings in your own environment: Umami Cloud plans list retention periods, while self-hosted retention is set by your own backup and deletion procedures. Test that a deletion request removes data from the database and from backups within your documented window.
Can DeployOpen build and test these integrations for us?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For integrations, that can include connecting analytics to your identity provider, tag manager, consent platform, warehouse and ecommerce plugins, and running test cases against each. Most engagements are fixed-scope, so the integrations, test cases and acceptance criteria are agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. Ask any partner which integrations are in scope, who owns the test evidence, and what happens to the integrations when the platform is upgraded.
Operational requirements: upgrades, backups, capacity and support
This table compares what each self-hosted option asks of your team after launch: release status, upgrade effort, capacity, and where support comes from. Use it to confirm the facts with each vendor at evaluation time, since version status changes. The main takeaway is that the lowest license cost can carry the highest operating load.
| Requirement | What to confirm | Where it usually fails |
|---|---|---|
| Release cadence and support window | Current stable and beta versions, end of support dates and which release receives security fixes (Matomo 5.14.1 was the latest stable on October 4, 2026, with 6.0.0 in beta per Matomo's changelog) | Team runs an unsupported version because nobody tracks the release status |
| Upgrade procedure and test environment | Documented upgrade steps, a staging copy of the database, and rollback steps for each minor and major release | Upgrades applied directly in production with no tested rollback |
| Security patch handling | Whether security fixes arrive only when you apply a release; Plausible states Community Edition gets security fixes only when the operator applies the release | Patch windows slip because no one owns the release calendar |
| Backup and restore testing | Backup schedule for the database and any ClickHouse or PostgreSQL data, plus a documented restore test run on a schedule | Backups run but restores have never been tested |
| Monitoring and uptime | Health checks for the tracking endpoint, database and queue, and alerts when collection stops silently | Tracking breaks after a deploy and no alert fires for days |
| Capacity planning and archiving jobs | Sizing guidance for your monthly pageviews, and whether archiving or report processing runs on a schedule that must be monitored | Reports lag or fail as traffic grows past the initial server size |
| Support channels after go-live | Whether support is community-only, vendor-paid, or provided by an implementation partner under a written retainer | Questions go unanswered because no contract or named responder exists |
How to score options and build a shortlist
This sequence turns the requirements list into a defensible shortlist: must-have gates first, weighted scores agreed across teams, a proof of concept on real tag placement, written evidence on residency and licensing, and then a decision that any reviewer can trace.
Apply must-have gates before scoring
Start by removing any option that fails a gate your organization cannot waive, such as data stored outside an approved region, no support for your identity provider, or a license that conflicts with how you plan to use the software. Security, legal and the business owner should each confirm the gate list in writing before anyone scores a product. Gates are pass or fail, so an option that fails one is not rescued by strong scores elsewhere. The output is a short list of options that pass every gate, with the reason each failed option was dropped recorded alongside it.
Agree weights across security, legal and operations
For the requirements that remain, ask security, legal, operations and the analytics owner to set relative weights together, not one team at a time. Weights should reflect your risk position, for example how much consent handling, retention controls and access auditing matter compared with dashboards and report depth. Record the weights and the reason for each in one scoring sheet so later disputes can be settled against an agreed baseline. The check that closes this step is a signed-off weight table that every reviewer has seen before any product is scored.
Score each option with recorded evidence
Score each remaining option against each requirement on the same scale, and attach evidence to every score: a link to the vendor documentation, a test result, a configuration screenshot, or a note of a question asked and answered in writing. A score without evidence should be marked as unverified and not counted as a pass. Where an option depends on a paid plugin, an external service or an edition difference, score the edition you would actually run. The output is a scoring sheet in which every number can be traced to a source a reviewer can open.
Run a proof of concept with real tag placement
Install the shortlisted options on a staging copy of your site and place the tracking code the way production will use it, including tag manager rules, consent management platform triggers, single-page application route changes and any authenticated areas that must be excluded. Do not limit the test to page view counts. Check whether the tracker sets cookies before and after consent, what it sends when the visitor declines, whether personal data such as IP addresses are truncated or stored, and whether features you plan to switch on, such as user identifiers or session recording, change that behavior. Capture network traces and browser storage snapshots as evidence. The step is complete when each option has a documented consent test result and a page count comparison against a reference.
Verify residency and licence obligations in writing
Ask each remaining vendor, and your own infrastructure team, to confirm in writing where the data is stored and processed, which sub-processors or external services the software calls, and which licence obligations apply to your deployment, including source disclosure or network use terms where the license has them. For hosted editions, get the storage location and support access model stated. For self-hosted editions, confirm which components leave your network, such as update checks, geolocation databases, font or script loading and optional integrations. Store the answers with the scoring sheet. The check that closes this step is a file of written statements that legal has reviewed, with any gap logged as an open risk.
Decide and record the rationale
Combine the gate results, weighted scores, proof of concept findings and written statements into one decision record. Name the chosen option, the runner-up and the reason for each rejection, and list the conditions attached to the decision, such as an edition requirement, a configuration rule for consent, or an item the implementation partner must confirm in the scope. Ask the security and legal owners to sign the record. The output is a decision memo that an auditor, a procurement reviewer or a future team can follow from requirement to evidence without relying on memory of the discussion.
Questions buyers ask before comparing self-hosted analytics platforms
How much does self-hosted web analytics cost compared with a SaaS subscription?
The honest answer depends on which costs you count, so compare the same line items on both sides. A SaaS subscription is a recurring fee that scales with traffic or events. Self-hosting removes the subscription but adds server hosting, storage, backups, upgrades, monitoring and staff time, plus any implementation work. Published vendor prices are a starting point: Umami Cloud lists Pro at $20 per month for 1 million events, Plausible Cloud lists Starter at $9 per month for 10k monthly pageviews, and Matomo Cloud starts at 29 (excluding tax) per month. Matomo On-Premise Community is free to download, but that does not make operations free. Ask any partner for a written quote that separates one-time setup from recurring hosting and support, and state the traffic tier it assumes.
How long does a self-hosted analytics deployment take?
Timing depends on scope, not on the tool alone. A single-site install on a prepared server can be simple, while multi-site rollouts, identity integration, consent configuration and data migration add work. Traffic volume matters because Matomo's published sizing moves from one server for up to 1 million pageviews a month to separate app and database servers for up to 10 million. Data migration is another variable: Plausible's Google Analytics import stores historical GA4 data as daily aggregates, and Matomo's importer brings in only aggregated reports. Confirm the timeline in the written, fixed-scope agreement, and ask which milestones depend on your team's access and approvals.
What does our internal team need to provide for the deployment?
Your team provides the environment, access and decisions. Expect to supply hosting in an approved location, container or server access, DNS and TLS certificates, database resources, an identity provider for staff logins where required, and a named owner who can approve the tracking scope. Plausible's Community Edition requires Docker, Docker Compose and at least 2 GB of RAM, and Umami's source install requires Node.js 18.18 or newer with PostgreSQL 12.14 or newer. Ask the partner to list every prerequisite, who owns each one, and which items must be ready before the work starts.
Can our team run a self-hosted analytics platform without outside help?
Yes, many teams run these platforms in house, but the work continues after launch. Plausible states that Community Edition operators manage installation, upgrades, capacity, uptime, backups and security themselves, and that Community Edition is community supported only. Plausible also notes that security fixes arrive only when the operator applies the release, and a security release, v3.2.1, was published on May 15, 2026. Matomo's pricing lists forum support for its free edition. Decide who applies upgrades, who watches uptime and who answers when a release breaks tracking before you choose between in-house operation, a retainer or a partner.
What changes when a regulated organization runs web analytics?
Regulated organizations add evidence, access and data location requirements to the checklist. Hosting inside your own cloud account or data center keeps visitor data under your control, but you still need documented retention settings, access reviews for the analytics admin console, backup encryption and a record of configuration decisions. Consent is a legal question, so the analytics setup alone does not settle it. Matomo's ePrivacy guidance says a consent exemption can be lost when features such as User ID, heatmaps or session recordings are added. Ask counsel and your auditors which evidence they expect, and treat any partner as preparing that evidence, not certifying it.
What should we ask an implementation partner to include in a quote?
Ask for a written, fixed-scope quote that lists each deliverable and the exact platform and version to be installed. The quote should name the environment, the number of sites, the expected traffic tier, the integrations in scope such as Google Search Console or identity providers, and the data migration method. Ask how one-time implementation is separated from recurring support, upgrades and backups, and whether testing, documentation and handover are included. Ask which items the client must provide, how changes to scope are priced and approved, and what happens if a vendor release changes behavior during the project. Ask whether the partner will document compliance-relevant settings for your auditors.
Which self-hosted analytics platform licence terms should we check first?
Licence terms decide what you may modify, distribute and sell to others, so check them before you shortlist. Matomo's repository is under GPLv3, Plausible Community Edition is under AGPLv3 or any later version, and Umami is under MIT. Plausible's self-hosted edition also omits features found in Plausible Cloud, including single sign-on, the Sites API and the Looker Studio connector, so confirm each feature you need in the edition you plan to run. Ask your legal team whether any paid add-on, such as Matomo's Heatmap and Session Recording plugin under the InnoCraft EULA, changes your obligations.
When a requirements review is worth a partner's time
An outside review adds the most value when the obligations pull in different directions. A team that must satisfy consent rules in one country, data residency rules in another, and an internal policy that sets retention for everything can end up with requirements that cannot all be met by the same configuration. Matomo, Plausible and Umami handle consent and cookies differently, and Matomo's own ePrivacy guidance notes that features such as User ID, heatmaps or session recordings can remove a consent exemption that otherwise applies. A partner can help map each requirement in this checklist to a specific setting, such as IP anonymization, cookie use, retention periods and which features are switched on, and flag where two obligations conflict. Ask the partner to show that mapping in writing before any platform is chosen, and confirm with your legal and privacy team which regulators apply to each market you measure.
Multiple sites, departments or brands multiply the decisions. Each site needs its own tracking scope, role assignments, data location and retention rule, and the number of sites often changes after go-live. Confirm whether the platform you are evaluating supports the multi-site and access model you need in its edition, since Plausible's self-hosted Community Edition lists single sign-on and the Sites API among features missing from the cloud-only set, and Matomo's Google Analytics importer excludes several reports, such as the Visitor Log and Funnels, when migrating history. A reviewer with experience in multi-site rollouts can test these assumptions against your site inventory, which is more useful than a generic feature comparison.
How DeployOpen scopes, delivers and supports web analytics requirements checklist
DeployOpen turns a web analytics requirements checklist into a written scope for your own infrastructure, then plans, implements, hardens and documents the chosen platform there. Engagements are fixed-scope, so the functional, hosting, privacy and integration requirements are agreed before any installation begins.
How we scope
- We walk through your checklist to separate must-have functions from nice-to-have reports and integrations.
- We confirm the hosting target, data residency rules, and whether Matomo, Plausible or Umami fits your traffic volume.
- The written scope lists deliverables, responsibilities, timelines and the consent and retention settings to be configured.
How we build
- We install the selected platform in your cloud account, data center or private network, with the database and backups you specify.
- We configure identity integration, role-based access, IP handling, retention periods and any Google Analytics history import agreed in scope.
- We test tracking on representative pages and verify that excluded paths, such as account or patient areas, send no data.
How we hand over
- You receive installation records, configuration documentation and a record of each privacy and retention setting chosen.
- We document operating procedures for upgrades, backups and access reviews so your team can run the platform.
- Compliance evidence we prepare, such as configuration exports and access lists, goes to your auditors, who issue any assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades when a new release or security fix is published for the chosen platform.
- Changes to scope, such as adding a site or an integration, are agreed in writing before work starts.

