Self-Hosted Web Analytics and Privacy: A Practical Evaluation Checklist

Self-hosting is a deployment choice, not a privacy verdict

Running analytics on infrastructure you control changes where the application runs. It does not, by itself, answer what the analytics code collects, whether the browser contacts other services, who can access reports, how long records remain or what happens to copies in backups and exports. Treat these as questions to investigate about your own setup, not conclusions that follow from the hosting model.

Start with the application, version and configuration you plan to use. Review the relevant official documentation, then compare it with your site’s tracking code and observed behavior. If documentation does not answer a question, record it as unknown and seek clarification rather than assuming an answer.

Plausible describes its product as open source and available as managed cloud or a self-hosted community edition in its [repository](https://github.com/plausible/analytics). Its [tool-selection article](https://plausible.io/privacy-friendly-web-analytics) names consent, hosting location, business model, open-source code and data ownership as comparison considerations. These references support those limited points; they do not establish the technical behavior of every analytics product or deployment.

• Keep hosting model and data practices as separate evaluation questions.
• Record the application, version, configuration and documentation you reviewed.
• Treat labels such as “privacy-friendly,” “self-hosted” and “open source” as prompts for further review, not evidence of specific behavior.

Map the data flow you need to verify

Make a simple diagram of the path you expect analytics data to take: from the browser, through any requests and server-side processing, into storage and reports, and onward to any exports, integrations or backups. For each step, note what information may be involved, which system receives it, who may access it and which documentation or test could answer your question.

This is an evaluation framework, not a claim that every application has each component or handles data in the same way. Use the documentation for your particular application and enabled features. Mark gaps as unresolved rather than filling them with assumptions.

• Browser: What code runs on the page, and what information does it read or send?
• Requests: Which destinations does your configuration contact, and what information is sent?
• Processing and storage: What does the documentation say happens to incoming events and which fields are stored?
• Reports and copies: What information appears in reports, exports, integrations, logs or backups?
• Deletion: What action removes data from each destination, and how can you check its scope?

Review collected fields and browser behavior

Use the application’s official documentation to make an inventory of the fields and events relevant to your planned setup. Compare that inventory with the tracking code and configuration on your site. Items to check can include page views, identifiers, IP addresses, referrers, campaign parameters and custom events; this list is a set of questions, not a statement that a particular tool collects them.

Review custom event names and properties as well as standard tracking. Check the code and configuration that create events, including any components you have enabled, and note whether the values could contain information you do not intend to send.

For browser behavior, consult documentation for the version and configuration you use. Where possible, inspect storage and network activity in a test browser. Record what you observed and the scenarios you tested; an observation is not proof of behavior in every configuration or situation.

• List the fields and events described in the documentation for your chosen setup.
• Compare the list with the code and configuration actually deployed.
• Check whether URL paths, query parameters, referrers or event properties could contain sensitive or identifying values.
• Look up documented behavior for cookies, other browser storage and fingerprinting; do not assume a setting is enabled or disabled.
• Use browser network tools on representative pages and actions, and record the destinations you observe.

Check integrations, access and data lifetime

Review the application documentation and your configuration for integrations and other dependencies. For each destination you find, establish why it is contacted, what information may be sent and who operates it. A server on your infrastructure does not, by itself, answer whether the wider setup contacts other services.

Before launch, decide who needs access to reports and administration settings. Check the access controls documented for your application and test the roles you intend to use. Set a retention rule that fits your needs, then verify what the application documents about enforcing it and deleting data.

Consider exports, integrations and backups when assessing deletion. Do not assume that removing data from a report removes every copy; check the documented scope and any separate procedures that apply to your setup.

• Identify the external destinations present in your configuration and document their purpose.
• Check which people or roles can view reports, manage users and change tracking settings.
• Document your retention rule and how you intend to apply it.
• Verify deletion behavior and identify any separate steps for exports, integrations or backups.

Assess notices and consent for your circumstances

Whether a notice or consent is required depends on the circumstances, including the data and techniques involved, your audience and the jurisdictions that apply. The available product-selection evidence names consent as a comparison consideration, but it does not establish what legal requirements apply to a particular organization or setup.

Consult applicable primary legal guidance and, where appropriate, a qualified professional. Record the basis for your assessment, the analytics behavior it covers and any assumptions. Revisit it if you change collection, browser behavior, integrations, audience or jurisdictions.

• Identify the jurisdictions relevant to your organization and visitors.
• Compare your actual configuration with applicable primary legal guidance.
• Make sure notices reflect the practices you have verified.
• Reassess when a material change makes earlier assumptions uncertain.

Run a pre-launch check

Where possible, test a staging site or controlled configuration before enabling analytics for production visitors. Keep a concise record of the documentation reviewed, the requests and fields checked, the access tests performed and the outcome of any deletion test.

A test only records the behavior you observed in the scenarios you exercised. Pair it with current documentation for your application and configuration, and repeat the review when you make meaningful changes.

• Compare observed browser requests with the destinations described in your inventory.
• Check stored fields using the application’s documented method.
• Test the access roles you plan to use.
• Verify the documented deletion scope and note any separate handling for exports or backups.
• Assign an owner to unresolved questions before relying on the setup.

Account for backups in your operating plan

Backups may form part of the data lifecycle, so establish how your own retention and deletion requirements apply to backup copies. Airbip provides configurable daily, weekly and monthly backups for its managed application deployments. If you use Airbip or another backup system, confirm the relevant operational details and decide how your policies apply to those copies.

bullets

• Identify which backup arrangements apply to your deployment.
• Document how you will handle backup copies under your retention and deletion procedures.