Why self-hosted web analytics is a sales question for SaaS teams
When the marketing site and signup funnel are measured in an ad-funded tool, enterprise security reviews now ask which third parties receive visitor data, and the answer decides whether a deal moves forward. For a marketing site with no need for ad-platform data flows, Umami or Plausible fit the job, and product analytics is usually a separate system that handles in-app behavior, events and cohorts. Treat the two as different scopes in the vendor questionnaire so the marketing site answer stays short and verifiable.
Enterprise trust questionnaires typically ask for a list of subprocessors and every script loaded on pages that handle customer data. Confirm with your security and legal teams whether the marketing site falls inside your SOC 2 system description, since a SOC 2 examination uses the AICPA 2017 Trust Services Criteria and the security common criteria CC1 to CC9 apply to every SOC 2. If the marketing site is out of scope, say so explicitly and show the boundary. If it is in scope, the analytics server becomes a system whose access, change and backup controls an auditor may sample, so plan for that before a customer asks.
EU customers add a second layer. Ask whether your analytics host, backups and support access keep visitor data in the EU, and whether any tag manager or CDN sends data elsewhere. Plausible's Community Edition is AGPLv3 and runs on your own Docker host, so the hosting location is your decision, but you must still patch it. Its operating model means someone on your team owns upgrades and security fixes, which buyers will want to hear described plainly.
Which requirements shape a SaaS analytics build
This table maps the requirements most SaaS buyers raise against the build decisions they change, from SOC 2 scope to processor terms and switching rights. Read each row as a question to answer before choosing Umami, Plausible or Matomo, and check the operating constraints in the last rows against your own hosting and staffing.
| Requirement | What it asks of the analytics build | Evidence to prepare |
|---|---|---|
| SOC 2 security common criteria (CC1 to CC9) | Every SOC 2 examination applies the security common criteria, so the analytics server needs documented access control, change management, monitoring and incident handling inside the audited system scope. | System description, access review records, change tickets and patch logs for the analytics host, with clear boundaries on what is in scope. |
| SOC 2 scope choice | Decide whether the analytics stack is inside the SOC 2 system boundary. If it holds customer or prospect data, assessors will expect it there or a documented carve-out with a reason. | Written scope decision, data flow diagram showing which systems receive pageview data, and vendor documentation for any hosted component. |
| GDPR Article 28(3) processor terms | If you host analytics for customers or run it for a group entity, the processor contract must limit processing to documented instructions and require Article 32 security measures. | Signed data processing agreement, instruction register, sub-processor list and a record of who can change tracking configuration. |
| Data Act switching rights | Data processing services must let customers switch to another provider or on-premises infrastructure within a two-month notice period, so exports of analytics data must work from day one. | Tested export and re-import procedure, documented data formats, and a clear list of settings, goals and dashboards that do not transfer. |
| NIS2 treatment of cloud and managed providers | If your SaaS product or managed service falls under NIS2 as a cloud or managed service provider, the Implementing Regulation (EU) 2024/2690 technical requirements can reach your internal tooling too. | Mapping of your NIS2 status with counsel, control evidence for the analytics host, and incident reporting paths that include it. |
| Plausible Community Edition security fixes | Community Edition gets security fixes only when the operator applies a release, and it ships twice per year, so patch timing is a operating obligation, not a vendor duty. | Named owner for upgrades, a patch window agreed with security, and a record of the Community Edition release version in production. |
| Matomo Cloud hosting in Frankfurt | Matomo Cloud stores data in Frankfurt, Germany, which can answer a residency requirement without running servers, but it moves the operator controls to the vendor's contract and terms. | Vendor data location statement, reviewed contract terms, and a decision record comparing it with self-hosting on your own cloud account. |
Which analytics platform fits a SaaS marketing site
A SaaS marketing site and signup funnel usually need a lightweight, cookieless view of traffic and conversions without sending visitor data to ad platforms. The cards below compare the options on license, operating burden, reporting depth and the gaps that matter once campaign attribution enters the picture.
Umami for a lean marketing site
Umami is the lightweight option to shortlist when the goal is page views, referrers and basic conversion events on a marketing site and signup pages. Confirm its current license, supported hosting stack, event and funnel features, and update cadence against its current documentation before you commit, because the supplied facts do not cover Umami. Ask who will patch the server and how the database is backed up, since that work falls to your team.
Plausible Community Edition trade-offs
Plausible Community Edition is licensed under AGPLv3, which matters if you modify the code and offer it to users over a network. It needs Docker, Docker Compose and at least 2 GB of RAM, and it lacks marketing funnels, user journeys and ecommerce revenue goals that Plausible Cloud offers. Security fixes arrive only when your team applies each release, so assign an owner for release monitoring.
Plausible signup funnel limits
Plausible Community Edition does not provide marketing funnels or user journeys, so a signup funnel built from separate page goals will show drop-off only as individual page counts. Teams that need step-by-step conversion analysis across the marketing site, trial start and activation should either accept that gap or plan a separate product analytics tool. Check the funnel requirement with the signup flow owner before choosing this option.
Matomo for campaign and commerce reporting
Matomo Community is licensed under GPLv3 and is the better fit when campaign attribution, goal tracking and ecommerce-style reporting matter more than simplicity. Matomo publishes sizing guidance: 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. Plan for a heavier stack than Umami or Plausible.
Google Analytics history and its limits
The Matomo Google Analytics Importer is free for On-Premise installs under GPLv3 or later, but it imports only aggregated report data. Visitor Log, Ecommerce Log, Custom Reports, Segmentation and some reports such as Funnels do not carry over. Plausible's GA4 import brings in daily aggregates up to the first native visit, cannot import ecommerce revenue and supports up to 5 properties per site. Ask for a written list of what history you will lose before you switch.
When product analytics should be a separate tool
Marketing-site analytics and product analytics answer different questions, so most SaaS teams need two systems. The website analytics tool measures pages, traffic sources, campaign performance and how many visitors reach the signup page and complete it. In-app event tracking, user journeys and session replay need a different data model, with events tied to accounts and workspaces, and they bring different consent and privacy obligations. Before you extend one tool to cover both, list every feature you want and check each one against the consent position you intend to take for the marketing site.
If you run Matomo, be aware that its Heatmap and Session Recording plugin is a paid premium plugin sold per number of users under the InnoCraft EULA rather than the GPL, with a 30-day free trial. Matomo's ePrivacy guidance also states that features such as User ID, heatmaps or session recordings remove the CNIL-style consent exemption that some regulators grant for privacy-focused audience measurement. Confirm with your privacy counsel whether any User ID or authenticated-session tracking on the marketing site would move it outside that exemption, and keep the configuration for the public site separate from anything that runs behind login.
For the second system, review the separate hub on self-hosted product analytics and session replay, which covers event tracking, funnels and replays kept in your own infrastructure. Decide early which team owns each tool, where account identifiers are stored, and how a deletion request from a user is applied in both places. Documenting those decisions now is easier than reconciling two datasets during a security review or an enterprise customer's questionnaire.
How a SaaS team rolls out self-hosted analytics
The sequence moves from a scoped list of pages and funnel events to a documented, parallel-run analytics setup that a security reviewer can inspect without relying on the team's memory.
Scope the marketing site and signup pages
The product or growth lead and the engineering owner list every marketing page, pricing page, signup and onboarding step that the analytics must cover, and mark which pages sit behind login. Pages that belong to the authenticated product are excluded from the website tracker and assigned to a separate product analytics decision. The output is a written page inventory with an owner for each domain and a short list of events the signup funnel needs, such as visit, signup start, signup complete and trial activation. The step is done when the list is signed off by the people who will read the reports.
Choose the platform and edition
The team compares Umami and Plausible Community Edition, and Matomo if it needs a broader feature set, against the page inventory and the features it cannot give up. Plausible Community Edition lacks marketing funnels, ecommerce revenue goals and single sign-on, so teams that depend on those features should confirm them against the current edition documentation before deciding. The decision record names the license, the release cadence, who applies security updates and who answers for them. It is done when the choice is written down with its trade-offs and approved by the engineering and security owners.
Deploy in the team's cloud account
The engineering team or its implementation partner deploys the chosen tool in the company's own cloud account, using containers for Plausible or Umami and the Matomo server stack for Matomo. The deployment covers the application, the database, TLS, backups, secrets handling and a named region for data storage. Plausible Community Edition requires Docker, Docker Compose and at least 2 GB of RAM, so the host size should be confirmed before provisioning. The step is complete when the instance answers health checks, backups restore in a test, and the access list is limited to named staff.
Configure tracking and signup funnel goals
Engineers add the tracking script to the marketing site and define goals or funnel steps for each signup event from the inventory. They confirm that the script does not load on authenticated product pages and that no personal identifiers, such as email addresses in URLs, are passed as properties. Each goal is tested by completing a signup in a staging environment and checking that the event appears once. The output is a configuration record listing each goal, its trigger and the page where it fires.
Set up campaign tag conventions
Marketing and engineering agree on a naming standard for UTM parameters, covering source, medium, campaign, content and term, with lowercase values and a shared list of approved sources. The standard is written into the campaign brief template and enforced in link builders so that paid, partner and email traffic arrive with consistent labels. The team also decides how campaign data is reviewed, who owns the tag list and how new channels are added. It is done when a test campaign link produces the expected source and campaign rows in the dashboard.
Run a parallel period against the old tool
The new tracker runs next to the existing analytics tool for a set period agreed by the team, and the two sets of numbers are compared for pageviews, visitors, signup starts and completions. Differences are explained by known causes, such as ad blockers, bot filtering, consent behavior or the cookieless counting model, and recorded in a reconciliation note. The team should confirm the comparison window with the analytics owner before starting, since no period is prescribed here. The step closes when the differences are understood and accepted by the business owner.
Cut over and retire the old tracking
The team removes the old tracking script from the site and any tag manager container, updates dashboards and recurring reports to point at the new tool, and archives historical exports in the agreed location. If historical data is migrated, the import limits of the chosen tool apply, and the team should check with the vendor what is brought across, such as aggregated rather than raw data. The output is a cutover checklist signed by the owner, plus a dated record of when each old tag was removed.
Document the setup for security reviews
The team writes a short system description covering the hosting location, data flows, what is collected and excluded, retention settings, access roles, backup and update procedures, and the named owner for each. This document is the evidence a customer security questionnaire or an auditor will ask for when reviewing a SaaS vendor's analytics. Its completion is confirmed when a team member who did not build the system can answer a sample questionnaire from the document alone.
What enterprise customers ask about trackers
Which third parties receive visitor data from our analytics?
With a self-hosted Umami or Plausible Community Edition install, the analytics server is the only recipient of visitor data, so no ad platform or analytics vendor receives page events from your site. The answer still depends on what else loads on the page. Tag managers, chat widgets, fonts, embedded video and CDN-delivered scripts can each send requests to third parties, and a security reviewer will check those too. Ask your engineers for a request log of the marketing site and document every outbound domain. If you use Plausible Cloud instead of self-hosting, Plausible becomes a processor, so the answer changes. Confirm the full list with your own environment before sending it to a customer.
Do we need a cookie consent banner for self-hosted analytics?
It depends on the tool configuration and on the jurisdictions your visitors are in. Plausible documents that it uses no cookies, so its own documentation states no cookie banner is required for its default setup. Umami is also designed to run without cookies in its standard configuration. Matomo can be configured in a consent-exempt way in some countries, but enabling features such as User ID, heatmaps or session recording can remove that exemption. Your legal or privacy team should decide the position for each market and record it in your data protection documentation. Confirm the configuration against the rules that apply to you, not a vendor summary.
Where is the analytics data hosted and who controls the server?
With self-hosting, you choose the location. The data sits in the cloud account, data center or private network you designate, so you can place it in the same region as your other customer data and keep it there. The control question is what the vendor or implementation partner can reach. Ask for the hosting region in writing, the list of backup locations, and whether any support or monitoring tool sends logs or metrics outside that region. If you run the platform in an EU region, document that choice and the transfer position for any non-EU support access. Confirm these details in the architecture document before the review.
Who can access the analytics server and its dashboards?
Access should be limited to named roles, granted through your identity provider where the platform supports it, and reviewed on a schedule. Plausible Community Edition documents single sign-on as a feature missing from the self-hosted edition, so confirm how you will manage admin accounts instead. Matomo and Umami also need a documented process for creating, changing and removing users. Control the server itself with administrative access over a managed path, separate production and test instances, keep logs of administrative actions, and restrict database access to the application. Ask your engineers to show the access list and the last review date.
How are upgrades and security patches applied to the platform?
You apply them, which is the main operating difference from SaaS. Plausible states that Community Edition is a long-term release published twice per year, is community supported only, and receives security fixes only when the operator applies the release, while Plausible Cloud ships updates multiple times per week. For example, the plausible/analytics project published security release v3.2.1 on May 15, 2026, after v3.2.0 on January 26, 2026, so a patch process has to be able to act within days. Write a patch schedule, test upgrades in staging, and keep a rollback plan. Confirm which release line you run and who is on call for security notices.
Does a SOC 2 report cover our self-hosted analytics tool?
A SOC 2 report is issued for a service organization, not for an open-source tool. Your own SOC 2 examination can include the analytics platform inside your system boundary, using the AICPA 2017 Trust Services Criteria, and the security common criteria CC1 to CC9 apply to every SOC 2. Auditors will look for evidence of access reviews, change management, patching and backups for that system. Self-hosting means the controls are yours to design and operate. If your auditor asks for a vendor report, ask the vendor for its own report, and for self-hosted open source, expect to produce control evidence yourself. DeployOpen prepares systems and evidence for compliance assessments but does not issue reports. Confirm scope with your auditor.
How do we export or delete visitor data on request?
Start by documenting where data lives, how long it is kept, and how each deletion request is handled. Both Umami and Plausible store aggregated or event-level records in their own database, so a deletion process needs to cover that database, its backups, and any exported files. Plausible Community Edition users can export and import data to and from Plausible Cloud, which helps with migration but does not replace a deletion procedure. Matomo offers its own data retention and deletion settings, so confirm which features your version supports. Test the process once against a non-production copy and keep the record. Ask your implementation partner to write it into the runbook.
Integration points and deployment pattern for SaaS sites
A SaaS marketing site and signup funnel with self-hosted analytics touches five components, each owned by a different team. The cards below cover the decisions that connect them, from the tag on the page to the backups that keep history usable.
Tag manager or site template
The tracking script should load from the site template or a single tag manager container, not hand-pasted into individual pages. Signup and pricing pages often come from a different framework or a separate marketing tool, so confirm which templates render the script and that single-page route changes send pageviews. Keep the tag out of authenticated application pages unless product analytics is explicitly in scope. Check that every signup step fires from one source of truth.
Reverse proxy and custom tracking domain
Serving the analytics script and event endpoint from a first-party subdomain, behind a reverse proxy you control, reduces blocking by browser filters and keeps requests inside your own domain. The proxy also sets TLS, rate limits and access logs for the analytics host. Confirm who owns the DNS record, who renews the certificate and whether the proxy strips client IP addresses before they reach the application.
Analytics application and database
Plausible Community Edition runs on Docker and Docker Compose with a ClickHouse store and needs a CPU with SSE 4.2 or NEON support and at least 2 GB of RAM. Matomo runs on PHP with MySQL or MariaDB behind a web server. Deploy both in your own cloud account or data center so the database, backups and logs stay under your control, and ask the implementation partner to document the version pinned for each component.
Backups and export path
Community Edition operators own backups, upgrades and capacity. Test a restore of the analytics database into a clean environment, not only a backup job that reports success. Plausible documents export and import between Community Edition and Plausible Cloud, which is useful as an exit path if you later change hosting. Ask for the restore time objective and retention in writing, and confirm where backup copies sit.
Google Search Console and GA4 import
Plausible's Google integration uses GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET to bring in Search Console keyword data and historical GA4 data from the site's Imports and Exports settings. The GA4 import stores daily aggregates up to the first native visitor, supports up to 5 GA properties per site and cannot import ecommerce revenue. Store the OAuth client secret in your secrets manager, and confirm the Google account that owns the credential.
Evidence enterprise buyers and auditors request
This table lists the evidence items enterprise buyers and their auditors usually ask for when a SaaS company runs its own analytics, and which component produces each item. Read it as a checklist to agree with your analytics platform owner before a security questionnaire or SOC 2 fieldwork arrives. DeployOpen prepares this evidence inside your environment, but independent auditors and certification bodies issue any report.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| System description in SOC 2 scope | Boundary of the analytics service, its infrastructure, data flows and the people who operate it | Your architecture documentation, the analytics server and database hosts, and the CDN or tag delivery path |
| Access review records | Who holds admin, read and API access to dashboards and the server, and when access was reviewed | Identity provider logs, Matomo or Plausible user lists, and SSH or container platform access records |
| Change and patch logs | Which analytics release was applied, when, and who approved it, showing security fixes were not left pending | Version control and deployment pipeline, plus the platform's release notes (for example, Plausible's published security releases) |
| Data processing agreement terms | Processor obligations under GDPR Article 28(3), including documented instructions and security measures under Article 32 | Your contract with the hosting provider and any support vendor, and your own internal processing records |
| Data inventory of collected fields | Each page, event and property the tracker sends, with any personal data classified and justified | Tracking script configuration, custom event definitions and the tag manager container export |
| Retention settings | How long raw visit data and aggregated reports are kept, and how deletion is carried out | Platform data retention configuration, database purge jobs and backup retention policy |
| Export and switching procedures | How you would move data out, to another provider or on-premises, within the timeline your contracts state | Platform export or import tooling, runbooks maintained by your team, and the export tests you have run |
Questions to ask an implementation partner
Start with the fixed scope, because it decides what you are actually buying. Ask the partner to list every deliverable in writing: the installation target (Plausible Community Edition on Docker and Docker Compose, or Matomo On-Premise), the tracking script and custom domain setup, the signup funnel goals, the import of historical data, the hardening baseline, the backup and restore test, and the handover documentation. Ask which items are excluded, such as a product analytics tool, a data warehouse feed or a consent management platform. Ask who signs off each deliverable and what happens when a requirement changes after kickoff. Then ask the partner to justify the edition in writing. Plausible Community Edition, under AGPLv3, lacks marketing funnels, user journeys, ecommerce revenue goals, single sign-on and the Sites API compared with Plausible Cloud, so a SaaS team that needs SSO or funnel reporting should know that before the build starts.
Next, establish who applies security releases after go-live. Plausible's own documentation says Community Edition gets security fixes only when the operator applies the release, and that it is community supported only. Ask the partner to name the person or team that watches the release feed, the window in which a security release is applied, the staging test used before production, and the rollback plan if a ClickHouse or Postgres change breaks reporting. For the tracking domain and proxy, ask how the reverse proxy is configured, whether the analytics host is separated from the marketing site, which TLS settings and security headers apply, how rate limiting and bot traffic are handled, and whether the proxy logs are kept, redacted or excluded from the analytics server. Ask for the admin access model, including SSO where available, multi-factor authentication for administrators, and the logging of changes to site settings.
Finally, ask for the evidence package and the retainer scope. Request a written test plan for the signup funnel, showing the events that define each goal, the test accounts used, the expected counts, and a dated record that the goals fired in a staging environment and in production. Ask how Google Analytics history is handled: Plausible imports historical GA4 data as daily aggregates, supports up to 5 GA properties per site, cannot import ecommerce revenue and approximates unique visitors by summing daily uniques. Ask the partner to document these limits in a reconciliation note so the figures are not compared as if they were identical. The evidence package should include the configuration baseline, access list, change log, backup test results and the data flow diagram. For the retainer, ask which upgrades, security patches, capacity reviews and support hours are covered, how release notes are assessed, and whether the partner will export data to Plausible Cloud or another target if you decide to switch.
What does self-hosted analytics for a SaaS team cost and require?
What drives the cost of self-hosted analytics for a SaaS team?
Cost comes from four places: the infrastructure you run, the one-time implementation scope, an optional support retainer, and the internal staff time your team spends on access, reviews and upgrades. Infrastructure is billed by your cloud provider and grows with traffic and retention. Implementation depends on how many sites, funnels, campaign parameters and integrations are in scope. Platform software itself is a separate question: Matomo On-Premise Community is listed as free forever on its pricing page, and Plausible Community Edition is open source under AGPLv3. Ask any partner for a quote that separates one-time work from recurring work, lists the infrastructure assumptions, and states what is excluded, such as product analytics or ongoing testing.
How long does a self-hosted analytics rollout take?
The duration depends on scope rather than on the tool itself. A single marketing site with a defined set of goals, campaign tags and a signup funnel is usually a shorter piece of work than a multi-domain setup with historical imports, cross-domain tracking and a dashboard for the growth team. Timelines should be written into the fixed-scope agreement before work starts, along with the milestones that depend on your inputs. Ask any partner to show how the schedule moves if access or definitions arrive late, since that is the most common source of delay.
What does our team need to provide before implementation starts?
Four inputs decide whether the work moves smoothly:
- Cloud access to the account or cluster where the analytics server will run, with rights to create the network, storage and DNS records.
- DNS control for the subdomain that will serve the script and the dashboard, so the certificate and tracking endpoint can be issued.
- A named owner on your side who can approve configuration, access rules and retention settings.
- Written signup funnel definitions: the pages, events and conversion steps that count as a trial start, activation and paid conversion, with the campaign parameter naming convention your marketing team uses.
If you use Google Analytics today, also share the properties you want to import so the historical data question can be settled early.
Can a SaaS team run self-hosted analytics without a partner?
Yes, a capable engineering team can install and operate Matomo or Plausible Community Edition alone. Plausible's self-hosted page states that Community Edition operators manage installation, upgrades, capacity, uptime, backups and security themselves, and that Community Edition gets security fixes only when the operator applies the release. The questions to answer honestly are whether someone will own patching on a fixed schedule, whether backups are restored and tested, and whether the team has time to review access and retention each quarter. A partner can take on a defined share of that work under a written scope, a retainer, or both. Decide the split before go-live rather than during the first incident.
When is Plausible Cloud the right comparison point?
Plausible Cloud is the comparison point when a team wants the lowest operating load and accepts a subscription. Plausible's homepage lists Starter plans for 10k monthly pageviews at $9 per month, with Growth at $14 and Business at $19, plus custom Enterprise pricing and a 30-day free trial. Compare that subscription with the infrastructure, patching and staff time of a self-hosted instance at your expected traffic. Remember that Community Edition lacks features that Cloud has, including marketing funnels, ecommerce revenue goals, single sign-on and the Sites API, so a feature gap can matter more than the price. Check the current Plausible pricing page before you decide, because published prices change.
Which Plausible features are missing from the self-hosted edition?
Plausible'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 Cloud-only in Community Edition. For a SaaS team, the first two matter most for the signup funnel, and single sign-on matters for access control. If you need any of them, either accept the gap, build a reporting layer in your own data stack, or choose Matomo, whose On-Premise Community edition is listed with unlimited users and hits. Confirm the current feature list with the vendor before writing requirements, since editions change.
How much staff time does ongoing operation take?
Ongoing time is recurring and easy to underestimate. Expect regular work on upgrades, security releases, capacity checks, backup restore tests, user access reviews and dashboard changes when the marketing or product team adds campaigns. Plausible Community Edition is a long-term release published twice per year, and its security fixes arrive only when you apply them, so a patch calendar is a minimum. For Matomo, plan for archiving jobs and database maintenance as traffic grows. Ask a partner to describe the recurring tasks in writing, the owner for each, and whether those tasks sit inside a retainer or stay with your team.
What should a quote for self-hosted analytics include?
A useful quote lists the platform and edition, the number of sites and domains, the signup funnel and campaign tracking scope, any historical import, the hosting assumptions, access and identity integration, documentation and handover, and the support terms after go-live. It should state what is excluded, including product analytics, session replay, consent banner design and legal review. Ask whether the price is fixed for the written scope, what triggers a change request, and how data and configuration can be exported if you move later. Ask for the retainer terms separately from the implementation fee so that recurring and one-time costs are easy to compare.
How DeployOpen scopes and supports SaaS analytics
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a SaaS team deciding between Umami and Plausible for the marketing site and signup funnel, that means the analytics server, its database, its reverse proxy and its backups sit in an environment your team controls, and DeployOpen works inside that boundary rather than hosting it on our side.
Most engagements are fixed-scope. Before any work starts, the parties agree in writing which platform and edition are covered, which domains and funnel steps are tracked, which campaign parameters and goals are configured, who owns the DNS, TLS and cloud accounts, and what counts as done. A quote follows from that written scope, so the number of sites, the number of integrations (for example, a Google Search Console or GA4 import on Plausible Community Edition) and the hardening requirements your security team sets are the items to pin down before you ask for pricing. Ask for the deliverables list, the acceptance test and any changes that would reopen the quote.
Ongoing upgrades and support run under a separate retainer, which matters because Plausible's Community Edition ships security fixes only when the operator applies a release. Ask whether the retainer covers applying the long-term releases and security patches, monitoring uptime and capacity, testing restores of backups, and maintaining runbooks. DeployOpen prepares systems, configuration records and evidence that your auditors can review, such as access reviews, change logs and backup test records, but it does not issue audit reports, attestations or certifications. Those come from an independent auditor you engage, so confirm early which evidence your SOC 2 or enterprise questionnaire process will need.
