Web analytics RFP questions

The bidder should name one exact edition and product line in writing, such as Matomo On-Premise Community, Plausible Community Edition or the self-hosted Umami release, and explain why it fits your traffic, data and consent needs. Ask whether any paid plugins are included in the price. Matomo's Heatmap and Session Recording plugin is a paid premium plugin under the InnoCraft EULA rather than the GPL, and its licence cost is separate from the open-source core. Ask the bidder to list every plugin, its licence and whether it is in scope for both build and support.

Require a written list of missing features with the reason the edition was chosen anyway. For Plausible Community Edition, the vendor's self-hosted page lists marketing funnels, user journeys, ecommerce revenue goals, single sign-on, the Sites API, the Looker Studio connector and advanced bot filtering as absent from Community Edition. Ask the bidder to confirm each gap against your requirements, and to say which gaps they would close through configuration, integration or custom work, and which they would leave open. Do not accept a general statement that the edition covers everything you need.

Ask for the exact minimum versions for the release proposed and for the server layout you will run. Matomo's requirements FAQ says Matomo 6.0.0 needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, while Matomo 4.16 and 5 run on PHP 8 with MySQL 5.5 or later or MariaDB. Plausible's Community Edition repository requires Docker, Docker Compose, a CPU with SSE 4.2 or NEON for 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. Ask the bidder to check these against your current operating system support dates.

The bidder should state in writing that production go-live uses a stable release, and that beta or pre-release builds are only used in a separate test environment with a documented reason. Matomo's changelog lists Matomo 5.14.1 as the latest stable version and Matomo 6.0.0 as in beta, so a bidder proposing 6.0.0 for production needs to justify that choice in writing. Ask how the bidder tracks release channels, what test plan runs before each upgrade, and who approves moving a pre-release into production.

Ask who applies security releases, how quickly, and who carries the risk while a fix is pending. Plausible's self-hosted page says Community Edition is a long-term release published twice per year, is community supported only, and gets security fixes only when the operator applies the release, while its cloud product ships updates multiple times per week. Ask the bidder to show their patch process, their notification source for advisories and whether an upgrade is included in a retainer or priced separately.

Ask the bidder to list every tracking feature turned on at go-live, including User ID, heatmaps, session recordings and cross-domain tracking, and to explain how each affects consent. Matomo's ePrivacy FAQ states that French authority CNIL recognizes some trackers as exempt from consent only when they are limited to certain purposes and collect anonymous statistics, and that features such as User ID, heatmaps or session recordings remove that exemption. Ask for a written configuration that matches your legal team's decision, with a change control step for any later addition.

Ask for a fixed scope that lists the edition, the number of sites, the hosting environment, the integrations, the migration work, the documentation and the handover, with each item priced or marked as included. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask the bidder to separate one-time costs (installation, configuration, migration, testing) from recurring costs (hosting, upgrades, support retainers), and to name any licence or plugin fee that applies to the proposed edition.

Yes, but only as aggregated report data. The Matomo Google Analytics Importer is a free plugin for Matomo On-Premise under GPL v3 or later, and it imports reports from a Google Analytics property into a new Matomo site. It does not bring in raw visit and action data. As a result, the Visitor Log, Ecommerce Log, Custom Reports and Segmentation do not work for imported periods, and some reports such as Funnels are not imported at all. Ask the bidder to confirm this against the importer version you will install, and to show you a test import of one site before committing to a cut-over date.

The reports that depend on raw event data are the ones most likely to be lost or altered. For Matomo, the importer excludes raw visit and action data, so visitor-level views and custom segments cannot be applied to imported history, and Funnels are not imported. For Plausible, the Google Analytics import brings in historical GA4 stats as daily aggregates up to the first native Plausible visitor, and it cannot import ecommerce revenue. Your RFP should require a written list, per report, that states one of three outcomes: migrated in full, migrated as aggregates, or not migrated. Ask the bidder to label every report on the Google Analytics or current tool inventory with one of those outcomes.

Expect these two metrics to change meaning after migration. Plausible's import documentation states that it cannot import ecommerce revenue and that it approximates unique visitors by summing daily uniques, so a visitor who returns on several days can be counted more than once over a longer range. Matomo's importer does not carry raw ecommerce logs across, so revenue history should be exported and held as a separate archive if finance or audit teams need it. Ask the bidder to state how each metric is calculated before and after the cut-over, to provide a reconciliation note for the overlap period, and to confirm where the revenue archive will be stored and who can access it.

The answer depends on the source platform, the export quota available to your account, and whether the importer supports the properties you use. Plausible's import supports up to 5 Google Analytics properties per site. Ask the bidder to specify, in writing, the start date of each migrated range, the end date where native collection takes over, and any gaps caused by sampling, filters or a changed property ID. Request a date-by-date table for each site and each source property, signed off before work starts.

Run the old and new analytics side by side for a defined overlap period, and compare page-level totals for the same days on both platforms. Differences are normal, because bot filtering, consent-based blocking and tag placement vary between tools. Ask the bidder to propose the overlap length in the written scope, the metrics used for comparison, the acceptable variance agreed in advance, and who signs off the cut-over. Also ask how the tracking script is switched on each site and what happens to the old tag, so that no page loads both trackers after the change.

Confirm the exact importer or migration tool version, its licence, and the platform versions it supports. Matomo's current stable release is 5.14.1, published on October 4, 2026, and Matomo 6.0.0 has been in beta since September 9, 2026, so a migration plan should name the Matomo version it targets. Ask for the bidder's test log showing a sample import, the errors seen, and the fixes applied. Require written confirmation of the importer's known limitations as published by the vendor, and make the bidder responsible for re-testing whenever the source or target version changes during the project.

Decide before the project starts who owns the export files, where they are stored, how long they are kept and how they are deleted. Exports from Google Analytics or another tool may contain personal data, such as IP-derived identifiers or user IDs, so they should sit inside the same access controls and retention rules as the new platform. Ask the bidder to list every export file, its storage location, its retention period, and the deletion step, with dates agreed in writing. Also confirm whether the source account will be closed, read-only or left running after cut-over.

Your team can perform the export, the import and the cut-over without a partner if it has engineers who can run the platform, operate the importer and check the reconciliation results. A partner adds value when the migration spans several sites, when the importer needs configuration changes, or when the overlap period needs independent checks. Ask a partner to price the migration as a separate fixed-scope item with its own deliverables, including the report inventory, the test import, the reconciliation note and the cut-over runbook. Ask your internal team to estimate its own time for each step, because staff time is often the largest hidden cost.

The bidder should provide a written hardening baseline for every component in the stack: the application, the database, the web server, the container runtime if used, and the operating system. Ask for the configuration files or settings exported from a real build, not a generic checklist. For Matomo, that covers the PHP and database settings and the web server rules that block direct access to configuration and log paths. For Plausible, ask how the Docker Compose stack isolates ClickHouse and PostgreSQL from the public network. For Umami, ask how the bundled PostgreSQL service is exposed and how secrets are supplied. Each baseline should name the setting, the default, the value chosen and the reason for the change, so your engineers can test it.

The bidder should state a patch process with named sources, a review window and a rollback path. Ask which release feed they monitor for each platform, how quickly they assess security fixes, and who approves production changes. This matters most for Plausible Community Edition, where the vendor's own documentation says security fixes reach you only when the operator applies the release. Plausible published Community Edition v3.2.1 as a security release on May 15, 2026, which is a useful test: ask the bidder to show how they would have found, tested and deployed it. Matomo's changelog and Umami's GitHub releases page are the equivalent sources for those platforms. Ask whether patching is included in the fixed scope or sits in a separate retainer.

Ask the bidder to confirm, in writing, whether the chosen edition supports single sign-on for administrators and report viewers, and to describe what happens when it does not. Plausible's self-hosted page lists single sign-on among features missing from Community Edition compared with Plausible Cloud, so an edition choice can remove this control. Where SSO is absent, ask how the bidder enforces named accounts, strong passwords, multi-factor authentication at the reverse proxy or identity layer, and timely removal of leavers. Request the role model, the list of accounts with administrative rights, and the procedure for reviewing them. Confirm whether the admin interface is reachable only from a management network.

The bidder should show which events are logged, where they are stored, how long they are kept, and who can read them. At minimum, administrative logins, user and permission changes, site configuration changes, data export and deletion requests, and failed authentication should be recorded. Ask whether logs are sent to your central log platform and whether the platform itself can alter them. Logs of web server and database access should be separated from application logs. Confirm that the bidder has tested a sample log export and that retention matches your policy. Note that some analytics applications log less than their operators expect, so ask the bidder to demonstrate each event rather than cite a feature list.

Ask for a description of TLS termination, certificate management, and the protocol and cipher settings on the public endpoint and on any internal connection between the application and the database. For data at rest, ask whether the bidder encrypts the database volumes, backup storage and offsite copies, and where the keys are held. Confirm whether the tracking script is served from your domain, since that affects blocking and integrity. Ask how the bidder handles encryption keys during restore testing. The answer should name the storage layer, such as disk-level encryption from your cloud or data center provider, and say which party controls the key. If the platform stores IP-derived data, ask how that field is treated before it reaches the database.

Ask for the most recent test report for the deployed configuration, not for the upstream project. The report should state the scope, the tools and methods used, the date, the findings, the severity and the remediation status. DeployOpen runs security testing of applications, APIs and infrastructure, so a bidder can be asked for this output; ask whether the test covers the production-like environment and the reverse proxy as well as the application. Ask what happens to findings that are accepted as risk and who signs them off. Request re-testing after every major release or configuration change. Some clients also want a retest after patching, so ask whether this is in the fixed scope or a retainer.

DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration records, hardening baselines, patch logs, access reviews and test reports. It does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies. When you write the RFP, ask each bidder to separate what they deliver from what your assessor must produce, and to name the evidence package by item. Ask which documents are available to review before award and which are delivered after go-live. Confirm that evidence will be stored in a location you control and kept current after the handover.

The cost of producing evidence depends on how many systems are in scope, how mature your existing controls are, and whether the bidder must build documents from scratch or update your templates. Evidence work done once during build is usually lower in total than reconstructing it for an assessor later, but the exact effort depends on the environment. Ask the bidder to list each evidence item in the written scope, with its owner and due date, so the quote can be compared line by line. Ask whether recurring items such as access reviews, patch records and test retests are inside the fixed scope or priced under a retainer. The answer should not depend on figures from another client.

The bidder should state, clause by clause, which party performs each recurring task: upgrades, security patches, backups, restore tests, monitoring and incident response. Ownership is the first thing to pin down because it changes the price and the risk. With Plausible Community Edition, the operator manages installation, upgrades, capacity, uptime, backups and security, so a bidder that does not take those tasks on leaves your team holding them. Ask for a responsibility matrix that names the party for each task, the tool used for patching and the evidence of each completed backup or restore test.

It depends on whether your team can absorb operating work that the vendor would otherwise do. Plausible describes Community Edition support as community only, with security fixes arriving only when the operator applies a release, while its cloud product ships updates several times per week. If your team cannot apply releases promptly, a retainer that covers patch application and upgrade testing is the usual option to price. Ask the bidder to quote the retainer separately from implementation, and to state whether it covers upgrades between the twice-yearly long-term releases.

Ask for named severity levels, with a response time and a restoration target for each, written into the contract rather than given in a sales call. Each level should define what counts as a critical outage, a data loss event or a security incident, who is on call, and the channel used for escalation. Also ask for the hours covered and how holidays and time zones are handled. The bidder should commit to numbers in the contract; if it cannot, the contract should at least state how response is measured and reported.

The bidder should explain who monitors traffic against the platform's limits and who acts when they are reached. For Matomo, the published sizing guidance separates a single server for up to 1 million pageviews a month from separate app and database servers for up to 10 million, so growth can move the architecture, not just the hardware. Ask who performs capacity reviews, how often, what triggers a change request and whether scaling work is included in the retainer or quoted separately. Also ask who maintains archiving jobs and database growth.

The bidder should name the release policy of each platform in your shortlist and state how it will keep you on a supported line. For example, Matomo's current stable line and Plausible's long-term release schedule set different upgrade cycles. Ask the bidder for its plan when a version reaches end of support, including the notice it gives you, the test environment it uses, the rollback steps and the cost of a major upgrade. Confirm that the contract requires a written plan before any end-of-support date.

Ask the bidder to describe its incident response process in steps: detection, triage, containment, notification of your security contact, recovery and a written post-incident report. Confirm the timeline for applying critical security patches and whether the bidder tests them in a staging copy first. Ask how the bidder tells you about vulnerabilities in the components it deploys, and what data it can access during an incident. Request a copy of its incident response runbook and ask who holds the access keys during an event.

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. Support is typically offered as a retainer on top of the fixed-scope implementation. Ask the bidder to confirm where it works, what access it needs, how it connects to your monitoring and ticketing tools and whether the retainer covers all of the tasks in the responsibility matrix. Ask for the quote as a separate line so you can compare it with an internal team.